【天天问每周精选】第51期：关于需求的那些事，我们可不是只唠

　　作为产品经理最头疼的一部分就是需求了。需求说大可大，说小可小，除了真伪，还有一些东西让我们困惑。所以本期天天问整理了天天问小伙伴对需求的疑问以及精选回答，希望可以帮助各位产品大大应对需求的问题，enjoy
　　问题清单：
　　都说在产品设计中要“少就是多”，可具体怎么做？
　　每个人都可能在你的方案上插两嘴，导致最后自己都迷糊这个需求是不是自己提的了。大家是怎么处理这种事的？
　　如何面对小需求变大需求的问题？
　　需求评审时哪些话不该说？
　　我是分割线
　　问题1
　　都说在产品设计中要“少就是多”，可具体怎么做？瓜小皮
　　描述如下
　　做的时候总是想说的更多，对用户解释的更清楚。然后页面内容就被添加的各种多！
　　怕用户不知道这个东西在这里，怕用户要用的时候不能做方便的找到，然后功能这里放一个，那里也放一个，各种放！
　　我还要给用户更多，嗯？这个用户提了这个需求？好的我加上！！越来越多！！
　　然后被说，要做减法，而不是做加法。可是真的不知道应该怎么去减。减了吧，总是反馈，这个不知道，那个不显眼！每天都被问，这个功能在哪里，用户不知道！那个功能不显眼，用户每次都来问！
　　麻烦说说看，应该怎么做才好呢！
　　精选回复追梦人
　　说说自己对这句话的理解：在产品设计中要“少就是多”。
　　为什么要讲究只做非要不可的功能？
　　C端产品有个特点：用户是根据习惯来使用我们的产品，基本是0操作培训。这时就带来一个问题：我们的产品定位是解决什么用户的什么需求？
　　用户在打开我们产品时，内心就已经锚定了这个产品能用来做什么？
　　那么在进去的页面，我们就最好让用户看到他们希望看到的内容，以一个电商APP为例：
　　如果我们是做生鲜电商的，那么大部分用户常买品类可能是水果、蔬菜、肉禽蛋、海鲜等。那么应该先展示出这些品类，让用户一下子就找到自己想要的东西。
　　考虑用户的最短操作路径：查商品选商品加入购物车完成付款查询订单状态。那么在用户的每一步操作都根据用户的心智模型，展示下一步要操作的按钮。
　　做好了第2点，再来考虑用户的一些其他操作下，系统又要如何处理？比如：用户可能尚未注册、登录，那么在加入购物车进行下单时要友好地提示登录，登录完成后直接进入订单结算界面等。
　　下面说说问题中3个点如何处理？
　　第1点，总是想去做解释，可以看看《用户体验要素》，产品可以考虑参考大部分用户常用的其他产品，适应用户的操作习惯，这样就没有太多解释的必要。
　　第2点，怕用户不知道功能放那，多个地方放同个功能，参照我上面的第2点，应该可以有效解决。
　　第3点，不同用户提出越来越多需求，这里就有个取舍问题一个需求做与不做的标准是什么？对于关键路径外的需求，评估后如何认为有价值要做，那么这个功能可以在上线的前一阶段，在主页上有个提醒，通过一段时间的观察，来看这个新增需求是否有真实的用户需求，通过类似方式系统最终沉淀的功能都是实用的。
　　精选回复鲸鱼我是陈靖宇
　　用户不需要思考吗？这是我怀疑的地方。
　　容易得到的东西，不容易获得的快感，在生活中也是如此。比如：教了孩子好久，孩子终于学会喊妈妈了，第一声会让你无比感动，如果孩子天生就会喊妈妈，那么这个刺激就会降低很多。
　　就像是微信，他的很多操作都是比较高级和复杂的，一般人并不会发现这个功能。比如：长按小相机可以发纯文字朋友圈，发消息长按可以撤回、收藏消息等等。这些功能没有做的很容易触达，但是还是做成了很高的认知度和传播度。
　　这过程中包括：咦，为什么你的微信公众号可以回复链接我的不行，我去百度找找教程，为什么你可以发纯文字朋友圈，我问问你是怎么弄的。甚至有揭秘《你不知道的微信20个操作技巧》的文章都能10W加。
　　所以我觉得不需要考虑太多，基本上按照用户普遍认知的交互逻辑走，满足基本功能，一些进阶操作，可以加入后续用户间的影响学习。
　　精选回复破宇狮子鱼G
　　建议看看简约设计这本书，核心思想是为主流用户提供产品，里面有一个很经典的例子，早先的电视遥控上经常几十上百个按键，每个按键都有单独的功能，操作只有一步。但是对主流用户来说，常用的只是开关机，快慢进，其余的按钮只增加了理解成本。而现在的遥控器通常只有6个按键，更多的操作通过隐藏、删除、不同操作端的方式解决。
　　大部分产品，是为了满足用户群体绝大多数人的需求。只要多数人提了，就应该引起重视。少数人提的，一般不是大家都要用到的。每个需求是自己去分辨，还要根据当前条件，排序，哪些优先。要学会挡需求，说服大家为什么做，为什么不做。
　　首页设置两个通道可以切换，一个专业人士；一个入门人士。默认为受众多的。
　　精选回复无奈的我0000
　　首先你要知道，你所关注的用户是主流用户吗？是经常来你们平台的还是只是偶尔来一两次的。
　　听用户需求并不一定要全盘照做，而是要揣摩用户所说的话后面真正的东西，如果用户说一个你做一个，那么你永远都做不完他们所想要的需求。
　　如果用户看不懂的功能，那么功能基本上是不合理的，如果一个功能出来，需要用户费脑子去理解，那么就应该想想如何让用户一目了然的去使用这个功能，而不是添加更多的东西来辅助。
　　针对第二个问题，可能你可以事先埋点，先看看用户实际行为，找出他们用得不爽的地方，然后针对这些地方设计出合理的功能，而不是你说的怕这个怕那个。
　　用户提的需求需要汇总，然后再观察他们所有人的需求背后是否有共性，最终设计出一个大致符合他们所期望功能出来，说得不好的地方欢迎大家继续回答！！！
　　精选回复P
　　现在互联网中常说的lessismore是来自于现代主义建筑大师密斯凡德罗的，出自现代建筑设计。
　　Less意味着明确的目标；Less意味着去除不必要的东西；Less意味着专注，把有限的精力集中在最重要的事情上；Less意味着节制的态度。
　　Less，不是单调，而是简洁
　　More，不是繁复，而是丰富
　　“LessisMore”，意味着高效，这和现代社会的精神是一致的。
　　少即是多在互联产品设计中更显得重要，因为每个人接受的信息太多了，处理这些信息就需要效率，如果做到少即是多，都是根据具体情况具体分析的，不能一概而论，也不能根据个例去影响整体。
　　很多人常会说用户是小白，这里可能看不懂那里可能看不懂，并举例1。2。3。4。5。而互联网发展的这几年，已经有越来越多的用户适应了使用互联网，12345只是反馈的个例，那么自然不能为这12345去改80的用户了。
　　（1）比如：曾经设计的一个产品中有一个榜单功能，这个产品的用户群体集中在青年和中年，产品就想试在页面中用大篇幅像用户解释这个榜单是怎么来的，因此具有xxx公信力，能更吸引用户。但是实际中，用户至关心排名前几名是否好坏。
　　在大部分用户的心理模型中，你怎么定的排名和我没时间去研究，我要看的是排前几名的是不是我正好需要的。因此大篇幅的关于榜单介绍的内容就是冗余的，对用户达成目标是有干扰的，就要去掉。
　　（2）任何产品都是存在学习和认知成本的，降低这些成本有很多方式，不是简单地放在用户眼前就行了，给用户的选择越多效率越低，一个页面让用户做一件事，一些相对低频的操作放到二级收起来，用户想找的时候能够相应地去找到，也没什么。
　　还有的功能，虽然不明显，但用户操作一次后，能够知道，那就ok，实在担心就在用户第一次进入的时候给个气泡提示也行。
　　一些功能，用户第一次操作存在学习成本，但后续操作是方便的，是没什么问题的。
　　（3）克制，克制，克制，用户的需求和产品的目标不一致，加吗？不加！用户的需求只是代表了他个人的想法，加吗？不加！用户的需求会破坏其他80人的体验，加吗？不加！不是目标用户提出的需求，加吗？不加！
　　复杂也是有个守恒定律的，一个产品包含的功能实在太多，面对的人群太广，不管怎么删除组织隐藏转移这个产品还是会显得复杂，可以考虑针对各项路径，在任务路径中增强主任务和其他任务的对比（就像城市中的马路，主干道总是又宽又大的，司机一看就知道），满足大部分人在大部分场景下操作是方便的，这样就好。
　　另外在产品设计的美学上，后现代建筑设计也提出了lessisbore，纯粹地为了追求简洁而做减法也是不可取的。
　　精选回复夜雨
　　我很少回答问题，因为很多提问我觉得缺乏必要的场景、数据支持，不能就具体情况作出符合实际的解决方案。例如：题目的问题，没有明确是什么类型的产品，是C端还是B端？在哪些页面场景？具体用户反馈的数据是什么样的？反馈比例如何？
　　由于没有实际场景、数据支撑，如果一味强调用户是傻子，照搬“少就是多“的设计理念，可能是错的。
　　为什么这样说？
　　如果是复杂的后台产品，本身就是要效率最大化，如果把一些关键的操作隐藏、关键的说明文案隐藏，这样去追求界面的简洁性，有什么意义？
　　所以，要落实到具体场景分析，用户反馈的核心点在哪里？有没有对反馈的用户做过调研？后台数据反馈比例是多少，再来回到“少就是多”的问题。
　　问题详情：https：wen。woshipm。comquestiondetailgdjfar。html
　　问题2
　　每个人都可能会在你的方案上插两嘴，最后导致自己都迷糊这个需求是不是自己提的了，大家是怎么处理这种事的？康熙是老大
　　描述如下
　　一个需求会经过好几次改版才定下一个终稿。但是这个过程是很零散的一个过程，也许老板吃着泡面，突然一拍大腿，嗨，这里加个柱子。亦或是总监喝着汤，突然脚一跺，嗨，这里加个坑。再或者，你的UI告诉你，这里不能这么设计。
　　每一个人都在打乱着你本来的思路，记得清的，是正儿八经开会确定的改稿方向，时常混淆的，是冷不丁的一条QQ消息。
　　我现在的方法就是不管是谁，我都记在小本本上，然后晚上做个总结，把方案相关文档整理一下，每日更新。
　　但是这样有个坏处，就是记得太清晰。比如：今天这个某人提了一个改进意见，你吭哧吭哧记录下来了，并且又总结又更新文档，记得可清楚了，但是过了两天，换了个逻辑，好了，你又记录下来，然后晚上总结，更新文档，记得可清楚了。
　　时隔半月，别人问你这个功能的逻辑，卧槽，脑子里两个逻辑在打架。赶紧翻文档看看，看完之后明了了。但是，心里空空的，感觉这样下去不是办法。对自己的产品把控居然要靠需求文档提醒，难道自己的产品不应该是身上的肉，咋长的，自己心里最清楚吗？还要看文档？！
　　所以，我想问问大家对这样个问题的解决方案，希望能得到一些启发。
　　精选回复
　　那你做好需求记录表呀，把所有需求都罗列下来，谁提的，提的时候是什么时候，为何会提这种需求，需要解决什么问题，需求属于哪种类别，需求评估（重要程度、紧急程度、商业价值、开发成本、难易度、开发周期等），需求对接人负责人事谁，后期的跟踪记录，你都做好了就不会产生这问题
　　精选回复破宇焰陌
　　（1）首先自己要清楚为什么提这个需求，老板的要求？竞品的参考？自己的灵感？
　　确定了为什么提，就要围绕这个理由去想要不要改，如果违反了开始的目的，就不要听。
　　举个例子：老板说让你加个收藏功能，你要弄明白的是老板为啥加这个功能，什么目的，什么要求，想要什么结果？这时候不管是UI跟你说这个需求影响页面布局，还是研发跟你说这个需求影响框架稳定，都去围绕最开始问题去考虑听不听，改不改，怎么改
　　（2）我做了一个一个Excel，谁，什么时间，提出了什么问题，问题被提出的次数，每一次是怎么解决的。
　　我觉得有用，你可以试试。
　　问题详情：https：wen。woshipm。comquestiondetailoc92ge。html
　　问题3
　　如何面对小需求变大需求的问题？
　　描述如下
　　（1）有一个需求，我接手前情况是这样的：
　　客服A在接待顾客X时，输入顾客X的手机号绑定信息，那么以后顾客X的下单绩效只会算进客服A，并且只有客服A能查看顾客X的订单信息；然而，客服A不是24小时在线，有时需要转接给客服B处理，但客服B在处理问题时，看不到顾客X的订单信息，处理起来非常麻烦。
　　（2）因此，客服向产品提了需求：要求客服A转接给客服B时，让客服B能看到顾客X的订单信息。（这个需求通过了产品内审）
　　（3）这个需求看起来很容易理解吧，于是我便输出解决方案：
　　客服A转接给客服B时，允许客服B看到顾客X的订单信息；
　　考虑到看到订单信息和绩效统计这两点可能有联系，便强调只是允许看到订单信息，不能把绩效算进客服B。
　　（4）我把这个方案提给产品总监
　　产品总监看了看，摇了摇头说：“得改”
　　“为何”
　　“没有考虑客服B的绩效问题”
　　“这个系统之前设计就是这样的，不会算入B的绩效，而且需求不是关于客服B的绩效问题”
　　“不，你得考虑各种情况”
　　“但客服B的绩效问题一直都是，而且跟客服沟通过，没客服觉得有这个有问题，都运作了这么久没人提这个问题，我们产品不好意淫吧，万一弄出其他问题怎么办”
　　“不，不要只听客服说的”
　　我再强调说“需求不是这个，只是客服B的订单显示问题”
　　总监说“还是得改，不合理”，然后转身去开会了。
　　（5）此刻我的心想：我的天啊，我真的想不通我的解决方案有什么问题，竟然被驳回了。需求明确摆在那，我觉得自己的方案能解决该需求的啊，怎么突然给我扯到了其他需求，这不是要我延期完成任务吗！
　　求各位大神告诉我，问题出在哪里？是做事方式还是解决方案？应该怎么办？
　　精选回复追梦人
　　初看这个问题，我从一般公司的层级角度给你提供一个思考方向：
　　我之前在甲方做软件规划分析时，产品接到某个用户的需求时，一般要初步判断下，这个需求是属于普通的操作优化还是对公司业务、KPI等有影响？
　　如果属于后者，那这个需求就不是一般的业务单位的一个基层可以决定怎么样是合适的。从公司组织结构来看，客服中心如有经理、总监，那么客服人员提出的这个需求应该通过其经理、总监同意（你们可以做个需求申请表及审核流程来解决这类问题，如果中小公司，就可以直接内部讨论下）。
　　建议需求人填写：目前遇到的问题是什么？希望实现的效果是什么？
　　经过客服的大佬们同意后，再流向产品，产品来回复解决方案，产品的解决方案再流向产品大佬审核，审核通过后在流程客服大佬审核，最终才进入开发阶段。（上述流程主要是中大型企业，如果中小企业就直接找个会议室沟通清楚）
　　我来看，你的问题可能是把一个涉及公司KPI考核的问题，简单地当成了一个客服人员的操作优化，所以你们总监不认同。
　　精选回复阿吕追求卓越
　　（1）我问一个问题啊，B处理A转接的订单的时候，如果瞎几把处理，弄砸了，这个时候你扣谁的绩效？
　　（2）在职场领导永远都是对的。即便领导的决策是错的，你也需要先执行了再说。针对你这个问题了，你就把如果只是解决订单显示的问题需要的工作量和解决绩效问题需要的工作量一一做详细的分析后让领导决策。
　　而且涉及到绩效的问题就牵扯到很深的业务了，各种情况都要考虑到，比如：现在的考核体系是否支持一个订单相关的绩效同属两个客服人员，若是属于需要按什么规则拆分，若是不属于那B的绩效如何算。而且绩效考核问题牵涉到很深的业务层面，那就得部门或是CEO来决策了。
　　总之一句话你详细分析各种情况需要的资源，包括业务部门签字确认，人员调配等等。
　　精选回复
　　感谢大家意见，我这里也说下后续。
　　需求重新更改，输出商家和公司内部都认为更好的绩效方案设计，通过产品内审。（耗时4天）
　　技术评估，发觉改动很大，出问题风险高，向老板汇报。（耗时1。5天）
　　老板综合多方意见，决定不做。（耗时0。5天）
　　这个大需求，后来不做，共耗时6天（假如要开发，还不含实际开发量）。
　　后来回归采用原来的小方案，共耗时2天就能让技术完成开发。开发完成后，各部门和商家皆大欢喜。
　　那就是说，一开始各部门和商家都觉得能产生价值的明确需求其实可以先做，然后再考虑大家都不在意的不明确需求（哪怕真的是有价值）。毕竟产品有迭代性，没有产品是完美的。
　　问题详情：https：wen。woshipm。comquestiondetailoc92ge。html
　　问题4
　　需求评审时哪些话不该说？张十安
　　精选回复张十安
　　（1）这个功能，我看XX产品做了，挺有意思，既然别人做了，就有存在的理由。
　　因为别人做了，我们就可以做，这句话有很大逻辑漏洞，根本站不住脚，别人做了不代表他们觉得有价值，或者用户觉得有价值。这种话如果说出来，很容易让人质疑你的能力。
　　（2）这个功能XX说了好几次了，优先级肯定很高，需要快点做。
　　别人说了好几次的需求，不代表现在要马上做，要确认当时提需求时，是否和特定场景相关，很可能当时很紧急的需求，到现在并不紧急了，这个得具体问题具体分析。
　　（3）虽然这个功能是为这个活动做的，但以后我们也可以用在其他地方。
　　具体讲解时，需要考虑全面了再说，也就是要明确“其他地方”都有哪些，是否一定要用这个功能实现，投入产出比如何？其他方案是否也能满足需求，如果长期考虑用途不大，只是为了一次性活动，那就要根据开发成本考虑最简实现方案。
　　（4）这个功能做了，可以拿来售卖啊
　　一个功能是否值得做，需要先考虑其在特定场景下的用户价值，然后再提商业价值。有些功能的商业属性是很弱的，单纯拿出来作为理由站不住脚，还是要结合场景来说。
　　精选回复sssDKevin。H。S文二水梦想家
　　我觉得，我认为，可能是，或许吧。
　　做好自己分内的事，不评价产品工作外的事情，比如：不评论技术框架的好坏和设计元素上的优劣，这些都是由开发团队和设计团队该考虑的事情。
　　这个功能很简单啊，两天够了吧说了肯定能被研发砍死。
　　这个功能，我看XX产品做了，挺有意思，既然别人做了，就有存在的理由。
　　问题详情：https：wen。woshipm。comquestiondetail2et698。html
　　总结
　　你在“需求”中有什么疑问和见解吗？欢迎来天天问和小伙伴们一起分享讨论哦
　　相关阅读
　　【天天问每周精选】第50期：大开眼界：活动运营的新鲜玩法
　　【天天问每周精选】第49期：传统行业如何合理利用互联网思维
　　【天天问每周精选】第48期：各位产品大大，来脑洞大开玩点子吧
　　【天天问每周精选】第47期：秋招季到了，来看点有意思的面试题吧
　　【天天问每周精选】第46期：QQ和微信之间不得不说的那些事