这几类需求有毒，设计师们请绕行(1)

这是第17次的白日梦 预计阅读时长5分钟

这周本来要更第二篇关于微软混合现实系统的文章，不过天气太热胃口不好，再加上各种懒癌拖延癌复发，所以换个大家喜闻乐见的话题充充数，吐槽下我们设计师亲爱的上游工友——产品经理。

互联网是个很奇妙的流水线，工作量在这条流水线上被逐级放大，一个需求可能几句话就能描述，但可能需要数十个页面的设计工作，等到了开发和测试那里，可能就是一个月的加班加点。在这样的情况下，很容易造成“一步走错，满盘皆输”的局面。

那么按理说对流水线的源头应该要做严格把控，但事实情况却是，程序gg的代码有测试同学严格把控质量，设计同学的方案要被各种角色挑战，唯独需求的评审好似就宽容许多，刨去许多产品们认为不用评审的“小需求”，在评审“大需求”时，大家更多关注的是这个需求对应的工作量、实现难度和排期，而对需求本身质量的考量倒放在了其次。

这里并没有吐槽的意思，毕竟一个需求还停留在文字描述阶段就要对它的效果进行评价本身就是强人所难，我想在这点上产品经理宝宝们也是心里苦呀。但作为产品的直接下游——交互，本着对自己下游工友们负责的态度，同时也让自己的工作能较为顺利的开展，还是需要具备对需求质量识别的能力，要不被产品坑了还要自己背锅，这日子就没法过了ㄟ( ▔, ▔ )ㄏ

好了，下面我就来聊聊那些“有毒的需求”和相应的解毒方法（不保证都有效哦）。

与竞品功能对齐

类比毒药：安非他命

毒性：★☆☆☆☆

特点：短时挺有效果，但容易上瘾

与竞品功能对齐是很常见的一种产品策略，尤其是对后入某领域的app，在差异点上创新的同时，也要保证大部分基础功能与竞品拉平，这时候比较省事的方法就是一个字——“抄”。听上去有点下作，不过这样既可以避免踩前人趟过的雷，又可以让从竞品那挖来的用户在体验上保持“熟悉度”，即经济又不会犯错。远的不提，比如去年支付宝像素级借鉴微信就是个典型的例子。

但这药能治病，却容易上瘾。想想看，每天上班只用盯着各种竞品又出了啥新功能，做个简单的梳理就能出PRD了，产品工作不要太美滋滋。尤其是当占有优质资源时，这种策略很容易在短期内获得奇效。

不过再抄QQ你也做不出微信，长期来看这种策略只能让产品失去质变的机会，同时培养一批懒惰的产品经理。当然，有追求的设计师们应该最讨厌这种需求了，毕竟设计师最恨痛抄袭了。

所以当一个产品经理让你设计一个跟xxx一样的功能同时又说不出背后合理的逻辑推演时，你就要警惕了，他可能是一个“安非他命”成瘾者。

解毒方法：

首先要做的是不理会产品的需求并向产品扔出一堆问题。比如：竞品当初为啥做这个功能？这个功能给什么样的用户解决了什么样的需求？这个功能给竞品带来的收益是啥？我们为什么要做这个功能？它能给我们带来什么样的收益？它跟我们的产品规划节奏是否一致？我们不做又会带来什么损失？...

如果产品都答上来了（或者厚着脸皮胡诌一通然后还是要做），那接下来可以继续问：我们是不是能找到另一个更好的解决方案？或者竞品的这个功能有没有改进的地方？我们能不能配合这个功能再做一些其他的辅助功能？...

如果该产品经理上道的话，这样问下来很可能碰撞出一个更好的想法，或者即使还是“照抄”了竞品，也会对这个功能的前因后果有更深刻的理解，这就把毒药又变成了药。

不过，如果产品不想跟你废话并亮出大招：这次时间紧，研发在等米下锅，我们不快点追上竞品就绞杀我们了等等。那我只能说：这次就从了他吧，毕竟下次他也不能厚着脸皮再放大招，是吧。

用户反馈的xx功能

毒性：★☆☆☆☆

类比毒药：三无保健品

特点：吃不死人，治不好病，很花钱

相信每个较为成熟的c端产品都会有用户反馈渠道来搜集一线用户的各种吐槽，这也是一个可供产品经理们寻找“灵感”的巨大需求池。总会有用户很认真的提各种产品建议，有些甚至一看就是有专业背景的用户提的。这时候产品经理就犯难了，我们在平时大谈用户体验，满足用户需求，现在用户跑你面前说我要xxx，你不给行么？

还真行。首先，个别用户的需求是否能代表大多数用户都有这个需求？其次，用户描述的真的就是他们想要的么？还记得福特汽车那个“用户想要跑的更快的马”的梗吧。最后，即使用户讲的很有道理也是大多数用户需要的功能，那你还要看看这个功能是否适合现在做呀。所以说，用户反馈中的需求就像三无保健品，基本上不会给产品带来危害，但收益也不会很明显。而且会耗费团队的很多精力，可能会因为分散精力去做这些无关紧要的需求而错失了窗口期的机会，就像那些相信保健品而不去就医最终小病变大病的老年同志。

解毒方法：

就像对待三无保健品一样，做到：

1不吃：用户反馈当做bug库看待，里面的产品建议看看就行。

2要吃就吃正规厂家生产的：真要做某个需求请务必重新做全套评估，不要一被问到原因就说“很多用户反馈他们需要这些功能”吧啦吧啦的...那只能说明这个产品经理思想上又偷懒了。

3不要寄希望于保健品可以治病：既不要寄希望用户能告诉你他们需要什么，要分析挖掘啊喂。

当然作为设计师，当产品又拿了一堆他“精挑细选”的用户反馈来证明自己要做的某（扯淡）需求的合理性时，你也需要想好如何应对：

1 首先你要确认这个需求是不是很“扯淡”（请翻阅各大产品论坛中有关如何判定需求真伪的文章）

2 如果确实“扯淡”而产品又拉用户反馈怼你，那最好的办法就是拿用反怼回去。比如：你说有用户反馈想要xxx功能，这种反馈数量有多少呢？这些数量的反馈能代表大多数用户的意愿么？据我所知反馈xxx的也有许多，为什么不做那个需求？（如果产品解释了理由，你就可以用他的理由回击了）

3 当然，真的怼不回去也不仿顺着产品的思路把他引导到用户体验上：既然这么多用户反馈这个功能，那我们就好好梳理下到底是哪些用户在什么情况下会有这种需求...这样就顺理成章的引到了用研上，借这个机会好好了解下你的用户，这就把毒药转化成了解药。

“打磨体验”为核心的需求

毒性：★★☆☆☆

类比毒药：马兜铃酸

特点：曾经大家都以为是治病的药，结果证明有毒

看到这个估计很多设计师要开骂了：我们天天说体验至上，用户第一。轮到产品经理跟我们说要开始打磨体验了，你告诉我说要警惕，要怼回去，这就有没道理了。

不过想想看，但凡一个处于上升期的产品，有大把业务和功能需求放在那里要产品经理处理呢，而一些体验上的瑕疵多半会被当成“瑕不掩瑜”的缺陷放到P2或更低优先级来处理，结果有一天产品突然告诉你，我们这个版本没什么大的新功能，主要打磨xx体验，（不是我被害妄想）这多半是自己想不出需求然后甩锅给设计师了。这种情况多出现在产品快速迭代了一段时间后，用户增长出现了疲软，原先计划的用户来源已经被挖掘的差不多了，而新的增长方向还没有头绪，为了不让团队“闲”下来而凑出的“需求”。这样即可以让平时当惯了“乙方”的设计师主导需求翻身做次“甲方”（让设计师们要爽到流泪了，有木有），也可以将产品指标同时甩给设计师，效果好了算是大家合作愉快，要是效果不好也可以推锅给设计，说是体验上还需要继续打磨等等，但毒性最大的是：整个团队开开心心热火朝天地打磨体验细节时，竞品可能已经更新了技术、开辟了新的商业模式，这就像终于把砍刀磨锋利了，结果敌人拿了把枪。

解毒方法：

毕竟“体验”是我们设计师手里为数不多的几味“药”之一，所以问题的关键还是在用法上。

首先，要明确体验的地位和作用。除去游戏等以体验为核心价值的产品不谈，一般的产品上，“体验”本身是没有用户价值的，他只是沟通“用户目标”和“产品目标”的一座桥梁。桥造的好，就能让更多的用户快速通行，既快速达到用户目标和产品目标，达到效率最大化；反之，会让用户很难通过，从而降低效率。但如果你根本不想过桥，那桥修的再宽再好，也不会有人走。说回产品，就是体验只能提升效率，但天花板还是用户的需求决定的。如果想只靠优秀的体验而不是稀缺的功能来吸引用户，无疑是妄想（游戏除外）。

其次，要知道当前是不是打磨“体验”的时机。讲真这个应该是产品经理来做的事。但我们也要心里有数，万一碰到猪队友了呢。凭经验，一般在产品遇到发展瓶颈时，产品病急乱投医会出现到处找增长点的情况，就很可能寄希望于处理历史遗留的“体验”问题。所以设计师也要对自己负责的产品的增长趋势有所了解，经常看产品核心数据是个好习惯。通过核心指标的曲线趋势，主要增量的来源，还有留存这些都可以粗略判断出当前产品发展情况。再结合近几个版本的功能点分布，就能大致了解到产品经理到底是有计划的在组织需求还是拿“打磨体验”来充数的。

最后，针对每个具体的有关“体验提升”的需求，设计师都要对“提升效果”做到心里有数。不要光顾着“自己high”而把效果目标忘了。事前明确目标有两点好处：一是可以帮助我们自己理清思路，将体验目标拆分转化为设计目标进而转化成具体方案；二是可以事让团队对“优化体验”能带来的收益有一个合理的预估，也防止前期产生过高的预期。

当然，更高阶的做法是，将平时快速迭代时来不及处理的体验优化点记下来形成一个“体验提升需求池”，把这些点再按照功能模块进行分类存档。如果遇上产品经理提出“打磨体验”的需求，此时就可以翻出这些“陈年旧帐”来场“对方不接你的需求，并向你抛出了成堆的新需求”的好戏了。

挣着卖白菜的钱，操着卖白粉的心，这话就是在说设计师呀。这次先介绍了三味慢性毒药，如果这篇文章发出去我没被打死的话，下一篇我会再介绍三款烈性毒药，好了，我去买人身意外险了。。。