“需求分析”的過程到底是什么？如何將搜集到的用戶需求轉化為產品需求、再映射到產品功能中去呢？

蘇杰先生在《人人都是產品經理》中提到了“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），浙江大學研究生，目前產品實習中，尋求相關工作機會。

本文由 @劉增明 原創發布于人人都是產品經理。未經許可，禁止轉載。