设计师遇到一个不合理的需求时，试试这4个方法

如果产品经理想把“帮助”按钮放到首页，设计师该如何反驳？以这个荒诞的需求为例，猎豹的资深交互设计师总结了四个方法，帮你拒掉那些不合理的需求。

在**知乎的时候，看到一篇特别有意思的虚构故事，其中的案例让人哭笑不得。大概是说一个产品经理不顾产品信息结构的优先级，希望把一个”帮助入口” 做在首页中间。而且产品经理说服设计师时候以逻辑漏洞的方式进攻，提出诸如 “我作为用户就有诉求，你没有诉求也不能代表大家都没有诉求” 之类的理由。 因为争论无果最后PM提出要 AB test，上线之后那个帮助入口点击率竟然还挺高的，让设计师非常的郁闷。

虽然这个故事的虚构的，而且故意夸张了需求的问题，但是实际工作中这样的沟通情况可不少见，我之前就经常遇到 “难以拒绝的需求”，他们之间往往都**有一些共性：

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

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

1、接到需求的时候，不要讨论设计解决方案，而应该讨论需求本身

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

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

很显然这里的需求就是『提供一个帮助入口』，并且希望可以『尽量帮助有问题的用户』。

2、要追问需求背后的目标和背景

在这场沟通案例中设计师一直都在说没必要做的这么强，但是他没有向 PM 了解为什么要做的这么强，忽略了挖掘需求背后的背景和原因：

1. 比如是产品最近有出现重大问题需要紧急修复并且告知用户吗？如果这样的话可以直接针对这个问题给用户弹出问题卡**，并且告知事故现象和解决方案，而不是模糊的帮助入口；
2. 如果是产品业务流程比较复杂，用户的完成度低所以需要帮助？那帮助的入口是否可以直接引入到场景中，比如在输入密码错误的时候弹出找回密码方式，在首次进行某项操作的时候进行新手引导？

需求的背景和目标是一个完整的整体，只有全面了解了之后设计师才可能给出ABCD等不同的解决方案，并且在这些解决方案中分析出优劣找出最优解。

3、设计效果不能只看单一的某个维度

案例中 PM 把方案上线测试，但是拿回来的数据设计师就看傻眼了，那个帮助入口的点击率挺高看起来需求很旺盛啊。但是设计师也能看出漏洞，放那么明显点击率能不高吗，可是被产品经理当证据的时候也不知如何反驳，需求和设计方案的效果真的只看点击率吗？

拿猎豹清理大师来说一天有十几亿流量，但是却也有十几个大大小小的子功能，如果我是老大我应该把入口给谁呢？衡量指标有三个维度：谁的功能量级大，谁的功能质量好，谁的功能对产品整体带来的收益高。所以虽然这个帮助入口点击率高，可能用户进去了之后转化率和留存**很低（没需求的用户好奇点进去就走了），另外也许功能上线后用户的负面反馈**增多，其他功能的流量也**受到此影响，而这个功能的根本目标（帮助用户解决问题 – 看问题的修复率）并不**改善很多。

所以，设计师衡量效果不能只看点击率这么一个指标，转化率、留存和用户反馈等都很重要。

4、设计师要更主动的去获取信息

案例里的设计师还有一个很大的毛病就是完全被PM牵着鼻子走，通过有限的信息去判断需求和方案的好坏，其实设计师可以自己主动做到对信息的全面掌握：

1. 比如我们经常鼓励设计师去参加产品经理的周**、需求评审**、需求讨论**，多观察老大们对产品战略的宣讲，尽量做到设计师本身就可以掂量哪些是重要的哪些是不重要的。
2. 设计师可以尽量去开通数据管理后台学**自己查数据，或者直接进反馈平台、AppStore、微博、贴吧去看用户反馈。如果实在不行大公司套路深，可以让产品和运营把相关的周报抄送给你。
3. 设计师要经常学**向上沟通而不是点对点沟通，遇到这个问题的时候可以拉很多人来讨论，拉领导来讨论，拉牵扯到相关的产品经理来讨论，由大家一起发表看法。比如案例中如果设计师拉来负责首页的产品经理说”他要抢你流量”，你看他们不得先PK一遍？或者如果这个产品经理的需求真的不靠谱的话，适当的和老大提一提那个产品经理很可能就被喷。不必要怕沟通，作为设计师愿意去认真对待一个需求一定是**收到刮目相看的。

最后，我看到唐硕的王阅微同学的评论也简单精炼，经过授权给大家分享一下：

必须直接指出，故事中的设计师的立场和沟通方向是错误的。

在这个故事里，事实是：

1. 产品经理提出了一个不完善的方案；
2. 产品经理提出了一个有需求的模糊的场景；
3. 产品经理提出了不适当的追踪反馈的方式。

设计师的问题有几点：

1. 没有开放地去理解『产品需求』背后的『用户需求』，进行评估很分析（例如用户角色、可能涉及的场景及任务）；
2. 想通过『否决需求』来『否决方案』；
3. 没有在理解和分析的基础上『提出解决方案』（产品经理在尝试）；
4. 没有提供研究反馈的思路，任由产品经理以不合理的方式进行评估；
5. 没有能从用户任务的角度分析获得的数据，提出合理假设与进一步分析需求。

在这个故事里，最大的问题不是不够专业的能力或方案，而是设计师将自己放在了一个被动的，期望合作伙伴提升的立场。

作者：可风

本文由 @可风 授权发布于人人都是产品经理，未经作者许可，禁止转载。