前几天做梦，突然梦到了很久之前看到的一个吐槽产品经理的小故事，或许是现在被产品“虐”习惯了，感觉看问题会有不同的角度，于是，凭着记忆去搜了这个故事重新看了一遍，果然有一些以前没有想到的结论。
案例：
今天上班，突然接到产品经理过来提了一个需求，说要在知乎的首页正中间放一个“帮助”按钮，他画了一个原型图大概是这样：
设计师（以下简称UE）第一反应是：这…好像不太好吧？
产品经理（以下简称PM）：为什么不好？用户如果有问题，他就可以点这个按钮寻求帮助，这很需要。
UE：但是首页最核心的任务是提供流信息，为用户提供内容。而且这个页面没什么学习成本，用户很容易就能理解，不需要帮助按钮吧？
PM：那是一部分用户觉得容易理解，那如果用户真的有问题、不会用，总要有一个入口让用户点吧？
UE：这个帮助功能有这么重要吗？放在首页这么正中心的位置，挡住了后面正常内容，用户又不需要的话不是干扰主流程和大部分没有问题的用户了吗？
PM：那加个取消的按钮吧，用户如果不需要他可以选择关闭，需要再去点。
于是，PM 快速画了这样一张图：
UE：不管怎么说，帮助都只是一个辅助功能，肯定不能放在最首页的位置，这最多是一个紧急情况下的选项，肯定不是用户的诉求。
PM：你怎么知道不是用户的诉求呢，我作为用户就挺需要的，我问了身边几个朋友也都说需要。
UE：不是你说需要就需要，你们两三个人能代表用户吗？
PM：那你一个人不需要，也不能代表用户啊！
UE：……
PM：那这样，快速做一个版本上线做 A/B Test 吧。看看有多少人点击帮助、多少人点击取消，再看看对首页的点击率有没有影响，这样总可以吧？
UE：这种需求不用测也……
PM：总得给个实验的机会吧！说好的用数据说话呢！
于是，大家吭哧吭哧制作了一版 A/B Test，上线一周后，数据反馈搜集完成。统计结果是这样的：
PM：数据出来啦！帮助的点击率不是最低啊，而且比取消按钮点击率高，看来用户果然还是很需要的。而且，整个页面以前的“更多”按钮竟然只有2%的点击率，要下也肯定下它，不应该下帮助功能。果然，还是要靠数据说话的。接下来，让我们再多花点精力把帮助功能做好吧！
案例描述结束
当然其实其中不乏夸张的成分存在，大家只当个故事听听就行，只要是在互联网公司工作的人都能感觉出来，需求有问题，之后许多人会开始故事中的设计师一样，纠结在用户有没有这需求，需求的优先级高不高这些问题上。可以说问题确实就出在这上面，但是设计师所提及的想法过于表面，没有深挖，我们不妨来看看这个需求的本质是什么。
一
公司里的男哥（感谢李尚男男哥给了我很多的想法）曾经告诉过我，当你拿到一个产品经理的需求的时候，应该要做的是，完全摒弃一切产品所提供给你的解决方案，然后去和产品经理了解两个问题：
产生这样需求的背景是什么？
用户是在何种情景之下进行的该操作？
由此，我们与产品讨论的方向就不应再局限于是不是放在首页这样的问题上，而是去挖掘背景和原因：
是不是最近产品出现了重大bug又或者说最近新增了什么业务流程比较复杂的功能，让用户无法独立的完成操作？
又或者是不是“帮助”功能的点击量突然猛增？那么去向帮助页面点击率最高的预设问题是什么？普遍反馈的问题又是什么？
通过这样的方式去寻找需求的共同点，会比否认他在首页放帮助的效率更高，如果是因为业务流程复杂，可以通过第一次点击时出现新手引导来解决，如果是因为bug或者用户大量反馈产品存在的问题，那么本质就应该去解决问题，而不是提供反馈的入口。
结论：无论产品丢给你多么精致的方案，请忽略不计，一切待得自己重新了解和评估过后再说。
二
要相信数据，但不要过分相信眼前的数据！
案例中，经过A/BTest后，产品给出的数据可以看出，在首页中帮助的点击率并不是最低，同时，帮助的点击率还略高于关闭帮助的点击率，就证明这个需求还是有许多人需要的。如果是没有经验的设计师面对的这样的数据可能一下子就懵逼了，无法反驳。
但是，但是，但是，敲黑板划重点。
测试周期太短，在首页那么显眼的位置出现新功能，有较高的点击率是正常的想象，可以预见，把测试周期拉长至1-2个月的时候，这个按钮的点击率会降低很多；
帮助的点击率还略高于关闭帮助的点击率并不能说明什么，可以认为有部分人是因为好奇而点击进入，通过返回来结束，并不是通过关闭按钮，所以这个数据比较这并不能说明什么；
数据是无法单维度分析的，我们仅看到点击率，而更应该关注的转换率和留存率呢？只有3个数据都得到了好的反馈才能证明这个需求是真需求，功能是成功的。
三
不要试图用否认需求的方式来否认方案。
“我作为用户就有诉求，你没有诉求也不能代表大家都没有诉求”
我想，互联网人应该都听过别人拿这句话怼你。这句话其实是无解的，任何需求都可以被认为是有诉求的，这无法反驳。因此否认需求就变的没有意义了，用辩论的技巧来说叫做—-证有不证无。
（关于这个证有不证无可以看看奇葩说或者蔡康永的说话之道都有描述到，这里就不赘述了）
因此我们要假设需求成立，而去了解需求的背景，目的等等，再通过优先级、权重等因素来得到更好的解决方案，而不是直接否认它。
四
损招
这是在这个故事下面看到的比较有趣的评论，虽然是损招，但是感觉好用！！！
我们要尝试更多的向上沟通或者多点沟通，而不是点对点沟通。遇到这个问题的时候可以拉很多人来讨论，拉领导来讨论，拉牵扯到相关的产品经理来讨论，由大家一起发表看法。比如案例中如果设计师拉来负责首页的产品经理说”他要抢你流量”，你看他们不得先PK一遍？而你只需要从他们的PK中去获取更多等讯息，为之后雄起做好准备！
（损招成不成功不敢保证哈，但是值得一试！）
最后，希望每一个设计师都能抛开产品给的方案，更多的关注需求本身。
共勉
