昨晚刷知乎的时候看到一篇特别有意思的虚构故事，其中的案例让人哭笑不得。大概是说一个产品经理不顾产品信息结构的优先级，希望把一个”帮助入口” 做在首页中间。

而且产品经理说服设计师时候以逻辑漏洞的方式进攻，提出诸如 “我作为用户就有诉求，你没有诉求也不能代表大家都没有诉求” 之类的理由。

因为争论无果最后PM提出要 ABtest，上线之后那个帮助入口点击率竟然还挺高的，让设计师非常的郁闷。
4招教你化解工作中的不合理需求
强烈建议大家也看一看：《 一个难以拒绝的设计需求 By 王镇雷 》
虽然这个故事的虚构的，而且故意夸张了需求的问题，但是实际工作中这样的沟通情况可不少见，我之前就经常遇到 “难以拒绝的需求”，他们之间往往都会有一些共性：

1）设计师可以明显的感觉到需求有问题；
2）产品经理无法给出客观的需求支撑，但是给出很多”难以拒绝的” 主观理由；
3）争论无果后PM会要求做出来试试，但是上线后数据看起来是有利于那个需求的；

所以当遇到这个问题这么办呢？我分享一下我自己思考的解法：

1，接到需求的时候，不要讨论设计解决方案，而应该讨论需求本身
案例中设计师的最大问题就是一直在和PM纠结一个设计解决方案，而不是需求本身。设计解决方案是设计师需要考虑的专业问题，和PM争论有个毛用，所以之前产品经理无论拿来多么精密的原型和文档的时候我都会忽视掉解决方案的那部分，从他的言语中定位出问题：

1）这个需求根本是达成什么目的？
2）这个需求需要的优先程度是怎样的？
3）这个需求需要的衡量标准是什么？

很显然这里的需求就是『提供一个帮助入口』，并且希望可以『尽量帮助有问题的用户』。
4招教你化解工作中的不合理需求
2，要追问需求背后的目标和背景
在这场沟通案例中设计师一直都在说没必要做的这么强，但是他没有向 PM 了解为什么要做的这么强，忽略了挖掘需求背后的背景和原因：

1）比如是产品最近有出现重大问题需要紧急修复并且告知用户吗？如果这样的话可以直接针对这个问题给用户弹出问题卡片，并且告知事故现象和解决方案，而不是模糊的帮助入口；

2）如果是产品业务流程比较复杂，用户的完成度低所以需要帮助？那帮助的入口是否可以直接引入到场景中，比如在输入密码错误的时候弹出找回密码方式，在首次进行某项操作的时候进行新手引导？
需求的背景和目标是一个完整的整体，只有全面了解了之后设计师才可能给出ABCD等不同的解决方案，并且在这些解决方案中分析出优劣找出最优解。