如何進行需求分析:從消息提示相關的需求場景出發
“需求分析”的過程到底是什么?如何將搜集到的用戶需求轉化為產品需求、再映射到產品功能中去呢?
蘇杰先生在《人人都是產品經理》中提到了“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),浙江大學研究生,目前產品實習中,尋求相關工作機會。
本文由 @劉增明 原創發布于人人都是產品經理。未經許可,禁止轉載。
- 目前還沒評論,等你發揮!