时间: 2021-07-30 09:28:04 人气: 10 评论: 0
用户需求是产品设计中一个重要因素，想深入地挖掘用户需求，就要从用户需求特点抓起。由于每个用户的个人特性都不相同，所以对于产品的需求体现也不尽相同。本文作者针对三种不同的用户需求——强烈个人倾向用户需求、浅层需求以及**面需求，来探讨：如何更好、更深入地挖掘用户需求？
团队中的产品经理最近提了几个问题，趁此机**做一下分享。
这是产品问答的第二篇，探讨对用户需求的深入挖掘。
问：在挖掘用户需求时，如何深刻的挖到用户的需求？
答：用户需求，字面意思就是用户的需求。
用户的需求，有这么几个特点：
强烈个人倾向用户提出的需求，可能是在使用产品遇到问题所产生的。
而每个用户的使用习惯、认知等不同，**导致他遇到的问题，对于其他人并不是问题。
曾经有个客户提出：他希望每次进入到邮箱，都可以直接编写新邮件，而不是非要去点击“新邮件”这个按钮。
这就是个人倾向比较明显的需求，并不是所有邮箱用户，都认为编写新邮件是最重要的需求。
浅层希望用户提出需求不**进行深入思考，而是当下的浅层希望。
比如，产品经理耳熟能详的故事 ——“更快的马车和发明汽车”：商人浅层希望为“希望马车可以跑的更快”，而其深层需求是“更快的速度”。那么，汽车所能提供的，比马车更快更持久的速度，才是对其真实需求的最佳满足。
现成功能很多时候用户提出的，是直接了当的功能。
在做互联网医疗项目时，曾一位患者，对我们的【不良反应反馈功能】（癌症患者在手术后的治疗过程中，每进行一个疗程都要反馈自己身体的不适，包括：头晕、恶心、呕吐、疼痛等等。这些信息**辅助医生来决策：当前方案是否合适？是否要进行调整？），提出这么一个需求：“我每次都要一项项输入这些信息，我想你们能在这个页面地下放个按钮，我按住以后就像微信聊天一样说话，医生到时候直接听就可以了”。
这就是一个直接体现为具体功能的需求。
单个或**面的角度用户提出的需求，可能是客观情况中的单个角度。
还是在那个互联网医疗项目中，我们服务的一家医院科室，提出一个需求：“我们这次要增加一个功能，患者预约了手术，我们的医生审核确认之后，患者就不能再取消预约。”
这个需求一定是这个科室从自身业务或利益角度考量决定的，但并不是所有科室都**这么考虑。实际也证明我们服务的其他科室，很多都允许患者在要求时间之前提交取消申请。
仅考虑自身利益忽视他人利益，可能对其他人造成困扰。
同样还是前一个例子：科室提出不允许患者取消，并没有考虑到患者可能出现的情况。如果患者确实无法进行手术，而功能上却不支持这样的操作，最终伤害的是利益相关的双方。
实际情况是：用户提出的需求，同时包含如上多个特点。对用户需求的特点进行识别，再针对性处理，是最高效的方法。
接下来，针对如上特点，逐一分析如何深入挖掘。
个人倾向的需求这类需求，要拓展到更大的需求框架中进行对比和思考。
还是用邮箱产品的例子：
我们判断这个用户提出这样的需求，是因为他使用邮箱时，更频繁的是发送新邮件。假设有一群这样的用户，我们定义其为“邮件发起者”。
那么，我们就可以通过问卷调研来搜集：现有用户中（或者所有邮箱使用者中）“邮件发起者”的比例有多少？他们对于这种直接发送邮件功能的需求程度，以及他们是否还有其他更好的想法？
同时，我们还可以根据邮箱的主要功能，再假设几个用户群出来，如：“邮件审阅者”、“邮件转发者”、“邮件回复者”等。
那他们是否也有类似的需求，将某个常用功能排序到操作的第一步。我们的这些推测可以通过问卷调研一次性搜集。
假设通过分析，验证了如上猜测，那我们就可以总结：
邮箱用户可以根据使用邮箱的主要目的，分为：“邮件发起者”、“邮件审阅者”、“邮件转发者”、“邮件回复者”等几种类型。
每种类型的用户都有将其主要使用步骤前置的需求。那么，我们就可以考虑如何去满足这类需求，比如：开发一个选择用户类型的功能，方便每个类型的用户直接将主要功能前置，而如果用户没有需求，则仍保持传统邮箱功能序列。
浅层希望的需求停留在浅层希望的需求，可以通过复原场景的方式来获得更深层信息。这方面的产品文章有很多，大家感兴趣就能找到，我还是从最经典的“更快的马车和发明汽车”来简单阐述。
商人提出需要更快的马车，我们应该去和他聊聊，通过沟通复原他提出需求的场景。
问他这些问题，可能**有帮助：
这些问题得到的答案，往往可以引申出新的问题，直到你觉得你已经深度复原了需求提出的场景。相信那时候，你对真正的需求也有了完整的认知。
提问方法，可以参照“5W1H分析法”。
体现为功能的需求提出是已经成为功能的需求，可以围绕功能的每一步进行访谈。
同样用举过的例子来说明：
患者的需求描述是：“我每次都要一项项输入这些信息，我想你们能在这个页面底下放个按钮，我按住以后就像微信聊天一样说话，医生到时候直接听就可以了”。
可以提出这些问题：
通过一系列的问题，就可以建立一个完整的围绕功能的需求逻辑。
角度**面的需求角度**面，表示提出来的需求，可能只是完整业务流程的其中一条路径。
这时，应该先去梳理出完整的业务流程图，建立对需求可能性的完整认识。
A医院的科室提出：要关闭患者对已成功手术预约的取消功能。
我们应该先从A医院开始，询问他们提出这个需求时，所基于的实际业务情况。这里需要运用业务调研访谈的方法，也需要培养自己的对于业务的理解和梳理能力。（如要展开说**是一篇长文，我以后有机**再详细阐述。）
最好的结果就是：可以把A医院围绕这个功能的业务情况，梳理成业务流程图。
你可能**发现：原来提出的需求并不能覆盖他们实际的业务，那就需要在满足需求时，整体考虑业务情况。
因为是一款Saas产品，仅对个别医院业务覆盖，是不能作为标准功能去迭代的。要以个别医院的业务流程图为基础，广泛调研访谈更多的客户科室。最终把更大范围的业务情况整合成一个更加全面完整的业务流程，才能在迭代中即满足某些业务特例，又不对其他正常业务造成影响。
仅考虑自身利益的需求这类需求，体现了不同用户群之间的利益博弈。
对待博弈最好的办法，就是：寻找双方利益的临界点或最优解。从双方或多方的角度各自出发，寻找最终可被大家一致接受的方案。
通过深入沟通，我们了解到科室提出该需求的考虑为：“经常有患者因为误操作或者各种的原因，取消手术预约。科室已经为准备手术付出了很多成本，甚至已经取消的患者**出现在住院部要求继续进行手术。导致医院床位、人员、手术室的资源浪费。”
继续问科室：“如果真的患者有必要的情况无法手术，你们要如何处理？”
科室回复：“需要患者联系医生，医生确认后就**取消手术”。
所以我们可以确定：
后来我们设计的功能是：患者线下联系医生后，医生**在系统内将患者的手术取消掉。
也许你**问：
为什么不设计成，患者申请医生审核呢？
——设计成患者申请，患者依旧**产生误操作，医生要继续为误操作投入时间成本。
为什么一定要医生在系统中取消呢？
——因为后续手术的预约一定是建立在没有进行中手术的前提上，不限制**造成更多问题。
当我们对用户的需求理解比较完整，就可以进行下一步工作，将用户需求转化为产品需求。
完成对用户需求的全面了解和深入挖掘，并不代表一定要去规划成果产品功能并开发。我们要用产品战略对产品规划的指导方法，来筛选出最终要去实现的需求。
而所有最终抉择后留下来的待开发需求，也正因为我们的深入挖掘，能够对最终形成的产品需求，作出更全面的指引。
作者：十八子杀，微信公众号：产品狗的思考（ID：PM-Doggy）。10年产品人，射手座，爱自由，喜摄影，好读书，涉猎广泛，望与同路人勉励前行。
本文由@十八子杀 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自@Unsplash, 基于CC0协议
