首先在确保用研对象是目标用户之后，用户所提出的所有合理需求(不包括用户提出我就是喜欢这个颜色这种)都是有活生生的使用场景支持的，肯定是用户在使用过程中确实遇到了这样的问题。很多时候用户不会告诉你我遇到了什么问题，他们不会想展示他们蠢的一面，他们只会告诉你他们想要的解决方式，然而这个解决方式并不一定是合适的或者是具有片面性的。所以在分析需求的过程中我觉得有以下几个比较重要的点。
1.思考有多少人有这个需求。很多时候需求是具有片面性的，一些用户提出这个需求只是出于个人习惯或者特殊场景，因为能参与用研的一般都是高玩，他们的一些需求可能并非是普通人具有的。曾经在一款社交产品中遇过加入“运动记录”这个功能的需求，用户在运动世界中希望有一个可以直接记录运动数据然后直接发送到动态或者分享给朋友的功能。当时提出这个需求的是深圳跑步社团的一位运动达人，出于对身份不同的考虑我们对这个需求也会有一些疑虑，用户到底是不是需要这样一种功能。
在对这个需求的深入了解后发现跑步区76%是普通运动爱好者，他们并不会希望把一些不太漂亮的数据分享给别人或者炫耀，会做这种事情的一般都是一些在跑步方面的高玩可以达到一些不错的数据，所以他们乐于去分享这些数据并感到自豪。结合了市面上一些运动产品的调研后我们发现，更多的用户倾向于把运动消耗的卡路里量作为一种完成目标的方式作为分享，以此激励自己等。所以在这个需求上面做成一个卡路里数的消耗并通过一些运营的手段鼓励用户去做这一件事情，在这个过程中可以通过高玩的需求中发现大众需求，使需求更加具有普遍性。
2.确定一个需求的价值，看人们现在满足它愿意付出的成本有多大，我个人非常认同这个观点。人实现任何操作都是有成本的，时间体力精力心情等等。如果一件事情在现有解决方法下需要人们消耗很大的成本才能搞定，那说明这背后隐藏着巨大的需求。以前做的一款社交产品时我负责企业版这么一个板块，在对接企业负责人时接到这样一个需求，他们希望能够在企业版加入视屏直播的功能方便大型企业会议，大型公开课的举行。首先我们把他们的需求转化在移动端有一种能够方便，快速共享视频直播的功能。
后来我提出了一个方案，在评审会的时候发现了一些技术上的难点以及带来给用户的不便性，首先是同步性和流量的问题，接下来是考虑到卡顿等视频经常遇到的问题等。用户肯定不会付出那么大的成本去做一件体验那么差的事情，这样做下去跟我们的初衷肯定是相违背的，再经过一轮的分析之后我们把需求转化为在移动端有一种能够满足实时共享的方式。接下来就是后续的分析需要有什么样的元素组成这样的一个条件，最后是采用了PPT+语音相结合的方式，有点类似现在红点做的事情。在这个过程中我们把“视频直播”转换成了“PPT+语音”的方式，评估开发周期直接从两个月变成了两周半。
3.这个需求是用户什么样的痛点，说白了这个实现这个需求到底能解决用户什么样的问题。曾经在参与一款针对学生市场的团体旅游产品的时候，有一次通过用研时得到一个需求：学生班长们希望能够在出行路线的选择上增加投票的功能，加快路线的决定。这个需求咋一眼看上去确实是非常有必要，在用户出行的时候线路的选择确实是比较纠结的地方，投票确实可以比较有效的解决这个问题。
但是在项目深入进行的同时我会去想 线路的选择在出行过程中确实是个比较难选择的问题，但是团体出游实际上线路的选择并不多，而且在出行天数确定的情况下基本上在没有线路之前就会脑子里面有概念到底是要去深圳海边还是出市外，缩小的范围之后像深圳海边其实就那么几个地方，决定用户会选择出行地点的我认为更大程度上是目的地的项目有什么是更吸引他们的。可能一部分人想去东涌是冲着野炊去的，一部分人冲着较场尾是冲着民宿去的，所以线路的选择完全可以通过群聊的方式去解决，对项目的投票可能才是比较有价值的点。出于对投票功能工作量的评估和具体技术的实现，我决定简化这个功能 做成一个“我想去”的板块 每个人可以通过点赞的方式体现更想去的项目。在这个需求的过程中我把“对线路选择进行投票”转移成了“对想去项目点赞”这就是一个从用户需求找出真实需求再结合项目实际转化成适合自己产品的需求这样一个方式。
辨别用户真伪最主要的还是去分析需求，以上三个是在分析需求的过程中比较值得注意的点。其实这是非常有意思的问题，这也是一个产品经理最重要的价值的体现之一。上文所说的都是在用研获得需求之后对需求的一些处理分析，不包括创造需求或者初期确定需求的一些方面。
著作权归作者所有。
作者：justinlam
来源：zhuanlan.zhihu
本文标签: 用户, 用研, 需求
