产品问答 | 如何深入挖掘用户需求?

用户需求是产品设计中一个重要因素,想深入

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

产品问答 | 如何深入挖掘用户需求?

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

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

问:在挖掘用户需求时,如何深刻的挖到用户的需求?

答:用户需求,字面意思就是用户的需求。

用户的需求,有这么几个特点:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

个人倾向需求

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

还是用邮箱产品的例子:

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

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

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

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

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

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

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

浅层希望需求

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

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

问他这些问题,可能会有帮助:

你使用马车是用来做什么?

你对速度的要求,是基于什么样的考虑?

你在载重量、时间持久、使用成本有什么要求么?

在上面这些因素里面,速度真的是你最优先的要求么?

上面这些因素里,有哪些对你造成过困扰?

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

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

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

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

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

可以提出这些问题:

您每次输入不良反应,大概会输入多少项内容?

输入的内容量有多少,哪些是您觉得比较犯错或容易出错的?

假设现在我们已经在这个页面增加了按钮,您现在按住它,模拟一下您现在要说的内容。

现在您讲完了,页面提示您已经增加了一段录音,您是否需要回放一下?您是否可能需要删掉这条,在重新录音?

您是否想知道医生有没有听完您的录音,您希望医生听完以后给您什么反馈么?

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

角度片面的需求

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

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

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

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

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

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

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

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

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

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

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

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

所以我们可以确定:

科室并非不能接受患者的取消,而是患者误操作或其他原因取消,导致手术安排混乱;

科室可以接受患者向医生提出取消申请,医生来确认的业务路径。

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

也许你会问:

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

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

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

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

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

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

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

作者:十八子杀,微信公众号:产品狗的思考(Productdoggy)。10年产品人,射手座,爱自由,喜摄影,好读书,涉猎广泛,望与同路人勉励前行。

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

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

相关推荐

评论 抢沙发

取 消
暂无评论...