案例分析:用户的真伪需求该如何辨别?
对于大部分用户而言,因为其认知局限,所反馈的产品设计需求更多的是偏于主观的。所以,产品设计师不能一味地只想着服从用户的建议,而是应该评估需求的可行性、合理性,理清用户的伪需求和真需求,从专业的角度根据可行需求进行产品设计。
用户需求是产品核心,分析需求则是产品经理的工作基础之一。
日常生活中,我们会从四面八方获取到客户的需求和建议。除了评估需求的合理性、可行性、立方案,我们更重要的是对需求背后的因素和客户的心理进行分析和研究。
有时候,客户提需求是很简单粗暴的,上来就跟你说“我想要这样你给我加功能吧”,而其实多数时候这只是个伪需求。如果仅仅为了满足当下的伪需求对产品不断打补丁,很快就会遇到瓶颈。
什么是伪需求和真需求?
为了更好的让大家认识伪需求和真需求,这里插入两个最经典的故事。
案例一:更快的马与福特汽车
100多年前,福特公司的创始人福特先生与客户的对话:
福特:“你想要什么样的更好的交通工具?”
客户:“我要一匹更快的马。”
福特:“为什么需要更快的马?”
客户:“这样我可以早点达到目的地。”
福特:“所以你要最终的目的是?”
客户:“用更短的时间、更快的速度达到目的地。”
最后福特没有选择去跑马场配种,而是制造了福特汽车。
案例二:用户与音箱
有家公司在设计音箱外观颜色的时候请来了一批用户做调研,询问大家的意见:
用户A:“红色,够酷炫。”
用户B:“黄色,够醒目。”
……
答案五花八门,调研结束后,工作人员让用户挑选一个音箱做为纪念品带走,结果大多数人都挑选了黑色的音箱。
小结
福特汽车的例子说明:用户的直接需求往往是浅层的——那个年代只有马车,用户只知道马可以带来效率,更快的马可以提高效率,只能认识到自己所接触范围内的解决方法。作为产品经理,必须跳出思维的怪圈,产品不是要解决用户“需求”,而是要帮助用户达到目的。
音箱的例子则说明:用户其实常常会“说一套做一套”,“嘴上说是这样身体却很诚实”。用户的的直接需求是带有主观色彩、个人情绪和时限性的,比如:有人今天心情好说喜欢橙色,有人今天心情差说喜欢灰色。如果产品经理不从这些主观意识中抽离出来,你的产品就要掉进万复不劫的深渊了。
真实需求是客户要通过我们的产品达到什么样的目的或效果。
接下来,我会用两个工作中遇到的真实的例子给大家说明一下:
(背景:房产类B端产品,我们公司有专门的产品建议收集系统,所有人都可以在上面提需求,分析需求时可以通过内部系统或者其他办法,找到提交人,并进行一对一沟通。)
两个经典实例分析
案例一
用户需求:电脑端盘源列表上的公共盘源需要添加明显标签显示。
产品现状:
(背景简介:盘源按归属权可分为私有盘和公共盘,按是否交易分为有效盘、资料盘等。)
为了方便房产经纪人更加快速的在门店现场查询盘源,我们系统主要按照是否可交易分tab显示,第一个tab默认显示有效盘。这导致了页面同时显示了私有盘和公共盘,但有一个tab是专门显示公共盘的。
思考点:
添加明显标记证明这些数据在这个页面是有特殊意义的,用户希望第一眼就能辨识出来。但对于经纪人来说,更加重要的是私有盘,因为会涉及到个人业绩结算,什么场景下会特别关注公共盘源呢?在已存在一个公共盘源tab的前提下,想要快速查询公共盘源,直接切换tab不是更快吗?
沟通后:
系统上有个私有盘变为公共盘的规则,我们俗称“跳公盘”。
“跳公盘”的规则大概是:经纪人超过设定的时间没有跟进客户的话,自己的私有盘会跳公,变为公有盘。由于目前盘源跳公时只有系统的消息提醒,在日常工作中,经纪人又很少看系统的提醒消息,导致自己的盘源如果跳公了都不知道。所以,希望在盘源列表页上对公盘添加明显标识,以方便查询自己的盘源是否跳公。
解决方案:
移动端添加消息提醒。
当知道真实需求是方便经纪人知道自己的盘源是否跳公时,我们决定从移动端去优化。经纪人经常需要外出带客户看房,所以很少会留意到系统的消息,手机是他们日常工作中使用最多的工具。我们在小程序版的系统中,添加盘源跳公的微信消息推送功能,这样经纪人就可以快速的收到消息。
案例二:
用户需求:
电脑端系统的报销单据详情页可以全屏显示。
产品现状:
报销单据默认小窗口显示,窗口可最大化,底部有【打印】和【取消】两个按钮。
思考点:
全屏显示一般是为了让用户沉浸在场景中,更加专注的阅读,避免其他元素的干扰,例如:我们会全屏观看视频,全屏演示PPT。那么,在什么样的场景下客户会需要“如此专注的阅读报销单据”呢?
沟通后:
原来是有些报销单据审核的流程很长,节点很多,目前系统的流程节点是横向显示,窗口太小无法显示所有节点,必须右拉滚动条才能查看后面的节点内容。这样在财务人员查看报销单据的时候带来极大的不便。
另外,财务人员在查看报销单据之后,会直接打印出单据,用于纸质归档。
解决方案:
重新调整布局,优化打印流程。
由于报销审批的流程节点太长,我们重新调整了节点的布局方式。将各个散落的节点利用分类将显示的内容缩短,比如:审批节点中有门店审批和上级公司审批,其中门店审批中又有部门审批和店长审批。
此时,将原本分开时显示的两个审批显示,组合成在一起显示。这样清晰的审批组织结构使得审批者更容易阅读。
其次,我们优化了打印流程。原本点击“打印”按钮后,就直接直接打印了,现在我们在中间添加了打印预览页,即点击“打印”按钮,跳转到打印预览页,在预览页点击“确定”按钮再调用打印机。
综上可见,用户的直接需求有时候并不能达到他们最想要的目的,相反可能会导致南辕北辙的效果。作为产品经理的我们要用专业的角度去引导用户走在正确的道路上。
自从之前的文章《结构化思考》被吐槽没有实例之后,绞尽脑汁的想要写一篇有实例的文章出来。希望以上的内容可以给大家一些需求分析工作中启发,同时欢迎继续吐槽。
本文由 @Chloe 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash,基于CC0协议
第一个例子,其实就是类似于企业的外勤销售用的crm系统,对应销售员名下和公海的概念,很容易理解的,各位。
感谢分享~~~
因为有步骤,看懂了原理。
只是不了解这类产品,没完全看懂细节 ➡
哈哈,懂原理就一通百通啦~
写的很实在,楼主是在链家。贝壳这种公司工作嘛
都是房产类公司,但他们是做C端,我们是做B端的 ➡
哈哈,第一个例子,被那几个盘搞晕了,第二个还好。
哈哈哈,是的,好容易混淆