“需求分析”的过程到底是什么？如何将搜集到的用户需求转化为产品需求、再映射到产品功能中去呢？

苏杰先生在《人人都是产品经理》中提到了“Y理论”，将需求分析的过程形象化为“Y”，如图1所示。

图1 需求分析的“Y理论”

暂不考虑从“2-产品需求”追溯到“4-马斯洛需求”的过程，那么“需求分析”的过程实际上就是经历图中的“1用户需求–> 2产品需求—>3产品功能”。 1–>2，通过问“Why”，逐步归纳；2–>3，通过问“How”，逐步演绎。

本文基于某企业级IM产品，从消息提示相关的需求场景出发，根据“Y理论”进行归纳和演绎，提出了产品功能方案。

一、场景与用户需求

场景一：

用户在手机客户端收到一条消息，阅读后暂时没空处理该消息，并且确定在未来的某个时间有空，TA担心有空时会忘记处理这条消息。

场景二：

用户在手机客户端收到一条消息，阅读后发现该消息的处理需要借助于电脑，而目前用户并不在电脑前，TA担心回到电脑前时会忘记处理这条消息。

场景三：

用户在手机客户端收到一条消息，阅读后暂时没空处理该消息，但不确定什么时候有空，TA担心有空时会忘记处理这条消息。

二、产品需求

在场景一中：

• 为什么用户担心有空时会忘记处理这条消息？（why）
• 因为TA有空时可能想不起来处理该消息。

因此，用户实际上是希望在TA有空时（确定在未来的某个时间有空），我们的IM产品能帮助TA想起某条重要而不紧急的消息，使TA不忘记处理，这就是产品需求。

在场景二中：

• 为什么用户担心回到电脑前时会忘记处理这条消息？（why）
• 因为TA回到电脑前时可能想不起来处理该消息。

因此，用户实际上是希望在TA回到电脑前时，我们的IM产品能帮助TA想起某条重要而不紧急的消息，使TA不忘记处理，这就是产品需求。

在场景三中：

• 为什么用户担心有空时会忘记处理这条消息？（why）
• 因为TA有空时可能想不起来处理该消息。

因此，用户实际上是希望在TA有空时（什么时候有空并不确定），我们的IM产品能帮助TA想起某条重要而不紧急的消息，使TA不忘记处理，这就是产品需求。

三、产品功能

针对场景一的产品方案：

• 如何帮助用户在有空时想起来处理这条消息？（how）
• 在用户有空时，也就是未来某个确定的时间，提醒用户。

如何在未来某个确定的时间提醒用户？（how）

产品方案一：在用户长按消息弹出的操作列表中提供“消息定时提醒”的功能

在“消息定时提醒”中，可以提供“稍后提醒”“明天提醒”“选择时间提醒”的选项，满足用户对于提醒时间的不同需求。

当用户设定的时间到了的时候，可以通过push或系统闹钟的方式提醒用户。如果是push方式，那么用户点击push进入会话窗口后，应能直达设置提醒的具体消息。

产品方案二：将消息与产品已有的日程功能打通，在用户长按消息弹出的操作列表中提供“转日程”的选项

用户选择“转日程”后，自动进入“新建日程”页面，同时该消息自动作为日程内容填入，用户本人被自动添加为日程的参与人。用户只需将计划处理该消息的时间设置为日程的开始时间，再点击“提交”即可发起日程。

借助于日程的提醒机制，用户能在计划处理该消息的时间点收到提醒并处理消息。

方案对比：

方案一通过开发新功能满足了用户需求，而方案二是利用已有的日程功能满足了用户需求。两种方案都能满足用户的需求，但方案二的实现成本更低。

针对场景二的产品方案：

如何帮助用户在回到电脑前时想起来处理这条消息？（how）

在用户回到电脑前时，提醒用户。

如何在用户回到电脑前时提醒用户？（how）

产品方案一：在用户长按消息弹出的操作列表中提供“PC端再次提醒”的功能

用户选中“PC端再次提醒”后，再回到PC端时，包含已标记“PC端再次提醒”消息的会话窗口为未读状态。并且，当用户点击并打开该会话窗口后，会话自动回滚到标记“PC端再次提醒”的具体消息附近，且该消息被高亮显示，从而达到提醒用户并定位具体消息的目的。

产品方案二：基于产品已有的消息转发功能，在长按消息弹出的操作列表中提供“转发给我的电脑”的快捷入口

用户选择“转发给我的电脑”后，再回到PC端后，转发的消息在PC端作为新消息对待，会有未读提示，用户点开即可查看。由于转发给我的电脑的消息一般不多，因此不存在消息定位困难的问题。

方案对比：

方案一通过开发新功能功能满足了用户需求，而方案二则通过改进已有的消息转发功能满足了用户需求。两种方案都能满足用户的需求，但方案二的实现成本更低。

针对场景三的产品方案：

如何帮助用户在有空时想起来处理这条消息？（how）

在用户有空时，提醒用户。

但是用户不确定什么时候有空，那么如何能在恰当的时机提醒TA呢？（how）

IM手机客户端是在工作中使用频率很高的工具，用户会时不时查看。如果在用户查看时该消息所在会话显示未读，那么每当TA打开app时都会注意到，直到TA有空时再次点开会话并处理了该消息为止。（这一做法与电子邮箱中广泛采用的邮件标记未读功能是异曲同工的）

产品方案：在用户长按消息弹出的操作列表中提供“标记未读”的功能

用户将消息“标记未读”后，该消息所在的会话会变成未读状态，在消息页面有未读红点提示，从而在用户每次打开消息主页面时引起TA的注意。

当用户再次点击进入会话后，会话自动回滚到“标记未读”的具体消息附近，且该消息被高亮显示，用户据此可知未被处理的具体消息。

四、总结：

虽然上述场景中用户的困境比较明显，产品的功能方案比较容易得到，why和how的思考层级也就比较浅，但通过这些例子不难看出：从用户需求过渡到产品需求，再到提出解决方案，需要经过先问why再问how的过程，而不是“用户提了什么需求就去做什么功能”。

作者：刘增明（微信号lzm479364262），浙江大学研究生，目前产品实习中，寻求相关工作机会。

本文由 @刘增明 原创发布于人人都是产品经理。未经许可，禁止转载。