用户需求是产品设计中一个重要因素，想深入地挖掘用户需求，就要从用户需求特点抓起。由于每个用户的个人特性都不相同，所以对于产品的需求体现也不尽相同。本文作者针对三种不同的用户需求——强烈个人倾向用户需求、浅层需求以及片面需求，来探讨：如何更好、更深入地挖掘用户需求？

团队中的产品经理最近提了几个问题，趁此机会做一下分享。

这是产品问答的第二篇，探讨对用户需求的深入挖掘。

问：在挖掘用户需求时，如何深刻的挖到用户的需求？

答：用户需求，字面意思就是用户的需求。

用户的需求，有这么几个特点：

强烈个人倾向用户提出的需求，可能是在使用产品遇到问题所产生的。

而每个用户的使用习惯、认知等不同，会导致他遇到的问题，对于其他人并不是问题。

曾经有个客户提出：他希望每次进入到邮箱，都可以直接编写新邮件，而不是非要去点击“新邮件”这个按钮。

这就是个人倾向比较明显的需求，并不是所有邮箱用户，都认为编写新邮件是最重要的需求。

浅层希望用户提出需求不会进行深入思考，而是当下的浅层希望。

比如，产品经理耳熟能详的故事 ——“更快的马车和发明汽车”：商人浅层希望为“希望马车可以跑的更快”，而其深层需求是“更快的速度”。那么，汽车所能提供的，比马车更快更持久的速度，才是对其真实需求的最佳满足。

现成功能很多时候用户提出的，是直接了当的功能。

在做互联网医疗项目时，曾一位患者，对我们的【不良反应反馈功能】（癌症患者在手术后的治疗过程中，每进行一个疗程都要反馈自己身体的不适，包括：头晕、恶心、呕吐、疼痛等等。这些信息会辅助医生来决策：当前方案是否合适？是否要进行调整？），提出这么一个需求：“我每次都要一项项输入这些信息，我想你们能在这个页面地下放个按钮，我按住以后就像微信聊天一样说话，医生到时候直接听就可以了”。

这就是一个直接体现为具体功能的需求。

单个或片面的角度用户提出的需求，可能是客观情况中的单个角度。

还是在那个互联网医疗项目中，我们服务的一家医院科室，提出一个需求：“我们这次要增加一个功能，患者预约了手术，我们的医生审核确认之后，患者就不能再取消预约。”

这个需求一定是这个科室从自身业务或利益角度考量决定的，但并不是所有科室都会这么考虑。实际也证明我们服务的其他科室，很多都允许患者在要求时间之前提交取消申请。

仅考虑自身利益忽视他人利益，可能对其他人造成困扰。

同样还是前一个例子：科室提出不允许患者取消，并没有考虑到患者可能出现的情况。如果患者确实无法进行手术，而功能上却不支持这样的操作，最终伤害的是利益相关的双方。

实际情况是：用户提出的需求，同时包含如上多个特点。对用户需求的特点进行识别，再针对性处理，是最高效的方法。

接下来，针对如上特点，逐一分析如何深入挖掘。

个人倾向需求

个人倾向的需求这类需求，要拓展到更大的需求框架中进行对比和思考。

还是用邮箱产品的例子：

我们判断这个用户提出这样的需求，是因为他使用邮箱时，更频繁的是发送新邮件。假设有一群这样的用户，我们定义其为“邮件发起者”。

那么，我们就可以通过问卷调研来搜集：现有用户中（或者所有邮箱使用者中）“邮件发起者”的比例有多少？他们对于这种直接发送邮件功能的需求程度，以及他们是否还有其他更好的想法？

同时，我们还可以根据邮箱的主要功能，再假设几个用户群出来，如：“邮件审阅者”、“邮件转发者”、“邮件回复者”等。

那他们是否也有类似的需求，将某个常用功能排序到操作的第一步。我们的这些推测可以通过问卷调研一次性搜集。

假设通过分析，验证了如上猜测，那我们就可以总结：

邮箱用户可以根据使用邮箱的主要目的，分为：“邮件发起者”、“邮件审阅者”、“邮件转发者”、“邮件回复者”等几种类型。

每种类型的用户都有将其主要使用步骤前置的需求。那么，我们就可以考虑如何去满足这类需求，比如：开发一个选择用户类型的功能，方便每个类型的用户直接将主要功能前置，而如果用户没有需求，则仍保持传统邮箱功能序列。

浅层希望需求

浅层希望的需求停留在浅层希望的需求，可以通过复原场景的方式来获得更深层信息。这方面的产品文章有很多，大家感兴趣就能找到，我还是从最经典的“更快的马车和发明汽车”来简单阐述。

商人提出需要更快的马车，我们应该去和他聊聊，通过沟通复原他提出需求的场景。

问他这些问题，可能会有帮助：

1. 你使用马车是用来做什么？
2. 你对速度的要求，是基于什么样的考虑？
3. 你在载重量、时间持久、使用成本有什么要求么？
4. 在上面这些因素里面，速度真的是你最优先的要求么？
5. 上面这些因素里，有哪些对你造成过困扰？
6. …

这些问题得到的答案，往往可以引申出新的问题，直到你觉得你已经深度复原了需求提出的场景。相信那时候，你对真正的需求也有了完整的认知。

提问方法，可以参照“5W1H分析法”。

体现为功能的需求提出是已经成为功能的需求，可以围绕功能的每一步进行访谈。

同样用举过的例子来说明：

患者的需求描述是：“我每次都要一项项输入这些信息，我想你们能在这个页面底下放个按钮，我按住以后就像微信聊天一样说话，医生到时候直接听就可以了”。

可以提出这些问题：

1. 您每次输入不良反应，大概会输入多少项内容？
2. 输入的内容量有多少，哪些是您觉得比较犯错或容易出错的？
3. 假设现在我们已经在这个页面增加了按钮，您现在按住它，模拟一下您现在要说的内容。
4. 现在您讲完了，页面提示您已经增加了一段录音，您是否需要回放一下？您是否可能需要删掉这条，在重新录音？
5. 您是否想知道医生有没有听完您的录音，您希望医生听完以后给您什么反馈么？

通过一系列的问题，就可以建立一个完整的围绕功能的需求逻辑。

角度片面的需求

角度片面的需求角度片面，表示提出来的需求，可能只是完整业务流程的其中一条路径。

这时，应该先去梳理出完整的业务流程图，建立对需求可能性的完整认识。

A医院的科室提出：要关闭患者对已成功手术预约的取消功能。

我们应该先从A医院开始，询问他们提出这个需求时，所基于的实际业务情况。这里需要运用业务调研访谈的方法，也需要培养自己的对于业务的理解和梳理能力。（如要展开说会是一篇长文，我以后有机会再详细阐述。）

最好的结果就是：可以把A医院围绕这个功能的业务情况，梳理成业务流程图。

你可能会发现：原来提出的需求并不能覆盖他们实际的业务，那就需要在满足需求时，整体考虑业务情况。

因为是一款Saas产品，仅对个别医院业务覆盖，是不能作为标准功能去迭代的。要以个别医院的业务流程图为基础，广泛调研访谈更多的客户科室。最终把更大范围的业务情况整合成一个更加全面完整的业务流程，才能在迭代中即满足某些业务特例，又不对其他正常业务造成影响。

仅考虑自身利益的需求这类需求，体现了不同用户群之间的利益博弈。

对待博弈最好的办法，就是：寻找双方利益的临界点或最优解。从双方或多方的角度各自出发，寻找最终可被大家一致接受的方案。

通过深入沟通，我们了解到科室提出该需求的考虑为：“经常有患者因为误操作或者各种的原因，取消手术预约。科室已经为准备手术付出了很多成本，甚至已经取消的患者会出现在住院部要求继续进行手术。导致医院床位、人员、手术室的资源浪费。”

继续问科室：“如果真的患者有必要的情况无法手术，你们要如何处理？”

科室回复：“需要患者联系医生，医生确认后就会取消手术”。

所以我们可以确定：

1. 科室并非不能接受患者的取消，而是患者误操作或其他原因取消，导致手术安排混乱；
2. 科室可以接受患者向医生提出取消申请，医生来确认的业务路径。

后来我们设计的功能是：患者线下联系医生后，医生会在系统内将患者的手术取消掉。

也许你会问：

为什么不设计成，患者申请医生审核呢？

——设计成患者申请，患者依旧会产生误操作，医生要继续为误操作投入时间成本。

为什么一定要医生在系统中取消呢？

——因为后续手术的预约一定是建立在没有进行中手术的前提上，不限制会造成更多问题。

当我们对用户的需求理解比较完整，就可以进行下一步工作，将用户需求转化为产品需求。

完成对用户需求的全面了解和深入挖掘，并不代表一定要去规划成果产品功能并开发。我们要用产品战略对产品规划的指导方法，来筛选出最终要去实现的需求。

而所有最终抉择后留下来的待开发需求，也正因为我们的深入挖掘，能够对最终形成的产品需求，作出更全面的指引。

作者：十八子杀，微信公众号：产品狗的思考（ID：PM-Doggy）。10年产品人，射手座，爱自由，喜摄影，好读书，涉猎广泛，望与同路人勉励前行。

本文由@十八子杀 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自@Unsplash, 基于CC0协议