需求分析初探:詳解需求定義、來源及需求關系
無論是產品還是技術,做的時間長了,會漸漸發現工作之中最困難的往往不是工具的使用、技術打磨,而是如何準確的理解用戶的需求,并將之轉化成一套可行的解決方案。所以需求分析能力對于一個產品經理來說,是最核心的競爭力!
文章結構如下:
- 需求分析的定義
- 需求的來源
- 用戶需求與公司需求的關系
1. 需求分析的定義
如果使用幾句話來概括需求分析的定義,那么便是“從用戶需求出發,挖掘用戶的真正目標,并轉化為產品需求的過程”。
在上面的定義中,引出了用戶需求與產品需求這兩個概念,這里的用戶需求指的是用戶最表層的需要,而產品需求則是為了滿足用戶需求所想出的產品方案!例如,用戶問產品經理要一輛汽車,此時的用戶需求便是一輛汽車,產品經理仔細詢問了用戶之后,發現用戶要汽車的目的是為了到一個遠方去取物品,那么取物品是用戶的真正目標,在得知了用戶的真正目標之后,產品經理經過權衡,覺得使用快遞的方式可以更好地達到目的,既經濟,又便捷!所以產品經理便提出了自己的想法,那么使用快遞這個解決方案就是產品需求。
用戶/產品需求分析,如果從來源上劃分可以分為面向普通用戶的需求分析與面向企業的需求分析,前一類就是針對普通消費者,比較容易理解,而后者一般以功能性為主,對于人機交互,使用體驗等方面不是很看重!一方面是因為面向企業的軟件少有公開的競品,另一方面企業追求成本,看重效率,所以只要能夠解決企業的問題,其他的老板都不會太在乎!
在這一小節的最后,說明一下互聯網產品跟用戶需求的關系:需求一直存在,互聯網產品只是更好的滿足了這些需求,從來都不是互聯網創造了這些需求!例如,百度搜索往往是人們獲取信息的入口,但是百度誕生之前,人們可以通過電視、報紙、口頭傳播等方式來獲取信息,但是百度的出現讓一切都變得更加的便捷、高效!
2. 需求的來源
需求的來源有很多,這里經過思考,大致列舉了以下幾種:
- 自己感覺
- 用戶調研
- 數據分析
- 競品分析
- 老板
- 運營銷售等工作人員的反饋
自我感覺
對于這種來源一般不適合初級的產品經理,憑借自我感覺產生靠譜需求的產品經理,要么有著過人的天賦,例如喬布斯,能夠在諾基亞盛行的時代,就準確的預測出用戶即將拋棄實體按鍵,投向虛擬按鍵的懷抱;要么有著豐富的行業背景,能夠通過自己的閱歷與經驗,來判斷市場的下一步走向。總之這些都是可以稱得上是興風作浪的人,普通人離他們的距離還是比較遠的!
用戶調研
用戶調研如其名,就是通過與用戶直接或者是間接的交互,來獲取用戶需求,這是最常用,通常也是最靠譜的方式!用戶調研分為直接用戶調研與間接用戶調研,直接用戶調研可以是調查問卷、用戶訪談等方式來獲取,間接用戶調研是從第三方渠道獲取用戶的反饋,需求等信息,例如若產品經理想開發一款旅游產品的軟件,那么可以在網上搜集一些有關用戶吐槽“去哪兒”與“攜程”的帖子,看看還有哪些點沒有解決,還可以搜集一些用戶給這兩款軟件點贊的帖子,整理一下用戶對哪些功能點比較滿意。通過這么一前一后的對比,哪些需求可以做,那些需求還有待完善,可能就會了然很多!
數據分析
很多時候,產品經理是無法直接接觸到用戶,只能通過冰冷的數據來揣摩用戶的需求。好處是數據時客觀的,分析出來的需求往往是準確的有效的,缺點是無法跟用戶直接產生交互,往往挖法進行更深層次的需求挖掘,所以很多時候問題只能一點一點的解決,不能一次性較為徹底的解決!例如在網絡購物的環節,產品經理會發現,用戶從瀏覽商品到加入購物車的轉化率為30%,從購物車到提交訂單的轉化率為20%,從提交訂單到付款的轉化率為90%,所以這種現象需要產品經理去思考,以及提出相關的的解決方案,以提高公司的盈利!
競品分析
在開始入手一款產品時,競品分析是繞不過去的,在分析競品的時候,除了分析競品的市場、定位、目標人群等宏觀上的東西,一些功能點等細節上的東西也需要認真的整理與總結,因為競品出現的更早,也經受了更多的磨練,所以存留在競品上的功能往往是經過時間考驗的。在分析競品功能的同時,更多的要思考競品功能點設置的背后原因:為什么競品會有這么一個功能點,這個功能點對應了用戶的哪些需求,這些需求還可以通過什么樣的方式來解決等等
老板
在做產品的時候,往往會經歷老板直接拋出需求的案例,首先要強調一點,老板之所以能夠稱之為老板,首先是有著一些過人之處,對于員工來說,尤其是產品新人,老板往往有著更高的市場嗅覺。一般來說,老板提出的需求都是有原因的,所以這就決定了當我們遇到這種情況的時候,如果覺得不妥,首先要反思自己,如果仍然發現老板的想法有問題,那么便可以通過搜集數據,列舉證據的方式來找老板溝通,而不是憑著自己的感覺和老板叫板!如果情況允許,甚至是可以先產出一個demo,投放到市場去,然后再通過實際的市場數據來論證自己的觀點!
運營、銷售等工作人員的反饋
在做產品的時候,往往會遇到客服、銷售、運營工作同事的反饋,要求添加一些功能,滿足他們的需求。對于這類情況,首先不能僅僅聽他們的一面之詞,因為這種需求的表達是他們口述中的需求,并不是用戶的直接表達。同樣的需求,可能通過不同人的轉述,就變成了另外一個需求,這個時候,如果能夠獲取直接的用戶錄音或者是用戶交易記錄等一手數據,是一個很好地解決方式。另外在面對這種來自同事的需求時,一定要站在整個產品的角度上去思考問題,因為每個人都是站在自己的角度上來闡述問題,所以都會把自己的需求描述的很緊急,很重要,如果不能跳出來,很容易被別人牽著鼻子走!
3. 需求判斷
需求判斷是指要從用戶的描述中,找到用戶的真正需求,這一點在最開始的例子中也有描述,因為用戶往往是感性的,而是很多時候是不經過大腦的思考,直接把想法表達出來,這里重新舉一個例子:用戶說自己想喝水,但是用戶真正的需求是解決口渴問題!如果產品經理僅僅是給出“提供水”的解決方案,可能在面對著下一個想和飲料的用戶時,方案又得推倒重來!所以產品經理在與用戶溝通的過程中,一定要問清楚用戶目的是什么,例如用戶跟產品經理講:我想喝水!產品經理繼續問道:為什么想喝水呢?用戶回答:因為我渴了!由此產品經理便得知了用戶的真是訴求!從而為后來找到一個合理的解決方案奠定了基礎!
4. 需求驗證
在獲得了用戶的需求后,產品經理往往會篩選出比較重要的核心需求,并進行優先滿足。但是產品經理認為的核心需求真的就是嗎?往往還需要進一步的驗證!驗證的方式有很多種,例如可以先做一個簡單的demo,投放到市場,看看市場、用戶的反應,如果可以,那么便繼續的進行。這種方法雖然最有效,但是往往實現難度也最大,因為現實中很少有公司愿意為一款驗證軟件去投放開發、設計資源!但是也有其他的途徑,例如將這些需求再次做成一個調查問卷,讓用戶投票,看看票數排在前幾的需求跟自己之前的判斷是否相符合;或者是針對自己人的核心需求做一個展示廣告,觀測用戶的點擊量與瀏覽量,從而得出進一步的判斷!
5. 需求的構成
在完整描述一個需求的時候,需要包括以下四個要素:
- 用戶
- 場景
- 目標
- 任務
用戶
用戶可以進一步劃分為使用者,購買者,決策者。對于To C的軟件來說,這三者往往是同一個用戶。但是對于To B的軟件來說,可能是不同的角色。例如在一個To B的場景中,一家公司想購買一套結算系統。那么購買者與決策者是公司的老總,但是使用者是公司的員工,所以面對這種情況,軟件設計的過程中,要著重考慮使用者的感受,而不是購買者與決策者!
場景
場景可以理解為用戶使用某款產品的所處背景/環境,這里的背景/環境可以是具體的,也可以是抽象的。例如用戶在使用餓了么軟件的時候,場景就是用戶感到餓了,而且不想出門,不愿意自己做;用戶在使用地圖的時候,往往是在路上,這也是一個場景。在描述場景的時候,最好遵循著“時間”、“地點”、“人物”、“事件”的方式去進行描述,這樣比較全面,可以引發產品經理更為深入的思考!例如一個小伙子(人物)早上(時間)在地鐵生(地點)感到很無聊(事件)!通過場景的深入分析,往往會發現很多潛在的需求!
目標
用戶目標在需求判斷的小節里面已經進行了比較詳細的闡述,這里不再過多描述!
任務
任務指的是,用戶在實現目標的過程中,與產品所產生的交互過程!這里依然拿餓了么來舉例,用戶為了解決饑渴問題,使用餓了么訂餐,在使用餓了么訂餐的過程就是所謂的任務!
所以在考慮到一個具體需求的過程中,“用戶”、“場景”、“目標”、“任務”這四個因素一個都不能少,只有這樣,才能盡可能全面的展開任務分析!
6. 需求的轉化
需求的轉化是將用戶需求轉化為產品需求的過程!在進行轉化的過程中,可以遵循以下三個步驟
- 確定用戶目標
- 篩選產品需求
- 根據用戶目標設計產品任務
確定用戶目標
其實關于用戶目標的描述,前文提到的已不下三遍,這里之所以再次重復,是因為確定用戶目標真的是重中之重,在于用戶溝通的過程中,用戶往往提出的是自己主觀的解決方案,但是這種解決方案往往是片面、低效的。產品經理在進行溝通的過程中,一定要多問用戶幾個為什么,刨根問底,發覺用戶最本質的需求!
篩選產品需求
對于同一個用戶目標,往往有多個產品需求可以滿足,如何篩選出最有效的產品需求,是我們需要考慮的,在篩選功能需求的過程中,可以考慮一下幾個因素:
- 覆蓋用戶的數量
- 用戶的體驗
- 用戶習慣
- 成本(溝通成本、開發成本、運營成本等)
根據用戶目標設計產品任務
在確定了用戶目標,明確了產品需求之后,接下來就是進行具體的任務設計。在設計任務的過程中,可以按照以下順序進行:
- 設計任務流,盡可能的細化拆解相關的步驟
- 同類步驟分組
- 組之間建立關聯
- 頁面原型設計
- 進行易用性補充
設計任務流
任務流是用戶在使用產品完成用戶目標的過程中,所進行的具體步驟!在進行任務流設計的過程中,要盡可能的詳細。例如在進行打車軟件設計的過程中,詳細的任務流可以作如下安排:
同類步驟分組
在設計任務流之后,要把同一類的步驟放在一組,分組的標準有很多種,這里建議按照需求的執行步驟來進行劃分,以及需以打車的任務為例,具體分組如下所示:
組之間建立關聯
所謂的組與組之間的關聯,是指組1以何種方式與組2進行交互,這里強調組1與組2之間的動作/信息交互。例如上面的組A與組B是通過點擊發送訂單的按鈕進行交互的,組C與組D是經過電話/短信的方式進行交互的等等
頁面原型設計
在進行頁面原型設計的過程中,往往同一組任務放在一個頁面之中,在進行具體的任務布局的時候,要考慮用戶的使用習慣、簡單易用等因素,具體實例如下圖所示
進行易用性補充
這一點牽扯到具體的頁面設計,重點是對用戶習慣的尊重,以及減少用戶操作等細節的把握,例如在上面的例子中,可以通過gps定位的方式,自動獲取用戶當前位置并填并完成出發地的填寫;以當前時間為準,自動填寫出發時間;在出發前,進行價格預估,并提醒用戶等!
Feature List
在做完需求的轉化之后,功能需求也確定了下來,下面要做的就是對功能需求進行進一步的梳理,Feature List可以比較好的幫助我們來完成這一任務,Feature List可以理解為將用戶的一個大的動作分解為具體的具體的功能清單,每個功能清單包括以下幾個部分:
- 模塊
- 子模塊
- 功能描述
- 價值描述
- 需求分析
- 需求優先級
- 工作量
- 備注
具體以Uber的例子作為展示:
7. 需求的表達工具
需求表達工具有很多種,重點以流程圖的形式展現出來,流程圖重點聚焦目標和任務,簡化不必要的流程,能夠提升重點交互環節效率,評估用戶行為路徑、快速的評估工作量!這里重點以業務流程圖與頁面流程圖為例, 業務流程圖是以用戶行為為主導,以圖的形式將最核心的業務展現出來,是PRD的重要組成部分!而頁面流程圖是針對業務流程圖對應的頁面展示,在畫頁面流程圖的時候,頁面的細節可以忽略,但是頁面與頁面的交互方式邏輯要重點突出出來!下面以一個具體的案例來說明:
案例說明:
阿強要買一桶桶裝水,在手機上進行預訂,寫明要送的桶裝水品牌、數量、上門時間、地址。送水站確定訂單,在APP提示預計的送水時間。到了預定的時間,送水工上門送水,拿出手機打開訂單二維碼,阿強掃碼支付,獲得積分。送水工取走空桶!阿強買了10桶水后,發現擁有不少積分,阿強在”我的積分”中兌換一張水票!
首先針對上述案例,要按照以下步驟進行:
- 確定用戶角色
- 確定用戶需求
- 確定業務流程
- 繪制頁面流程
確定用戶角色
在上述案例中,只有兩個角色:阿強、送水工
確定用戶需求
對于阿強要進行登陸注冊,然后進行填寫訂單并提交,收到水進行支付操作,最后進行積分的兌換。
對于送水工,要進行訂單的確認,然后進行送水工作,最后進行訂單確認工作。
確定業務流程
繪制頁面流程
通過示例可以看出,頁面流程圖能夠聚焦用戶的目標和任務,同時簡化了不必要的流程,提升了重點交互環節的效率,并為工作量的評估提供了很重要的參考!
8. 需求優先級管理
在確定了具體的產品需求之后,還要確定產品需求完成的順序,先做那些東西,后做哪些功能。根據筆者的經歷,首先要根據產品所處的不同生命周期而采取不同的策略!每一款產品都會經歷以下四個時期:
- 引入期
- 成長期
- 成熟期
- 衰退期
引入期
產品的初始階段被稱為“引入期”,這個時期產品剛剛進入市場,重點是吸引用戶,培養市場。所以重點確?;A功能可以使用的同時,突出產品的特色功能!以微信為例,微信的基礎功能是聊天,在前期的幾個版本基本上都是圍繞著如何快捷有效的聊天進行展開!從單純的文字,到后來的語音視頻等,一句話總結:在產品初期重點打磨產品的核心功能!
成長期
在產品進入了市場之后,進過短期的發展,開始進入快速成長階段,不斷的擴張市場!這個時候產品所面對的用戶也漸漸從最初的種子用戶向大眾用戶擴展。這段時期,要在核心功能的基礎上不斷添加新的功能,以滿足用戶的需求,同時隨著用戶量的增加,后臺服務也面臨著巨大的壓力,如何處理好后臺龐大的數據,提供完善的服務,是這段時期的重中之重!
成熟期
在經歷了“引入期”、“成長期”之后,產品的用戶漸漸趨向于穩定,獲取新用戶成為一件十分困難的事情,這個時候要做的是維護好現有用戶,保持市場的占有率。關鍵是提供良好的用戶體驗,通過細節的變動讓產更加的完整,體驗更加的優化!
衰退期
這段時期,產品往往遭受到了新的沖擊,例如誕生了一種新的交互方式(iPhone的屏幕操作代替了功能機的按鍵操作),此時產品應該剔除短板,擴展新的方向,更確切的說,此時的產品更像是一種壯士斷腕般的涅槃重生,然后重新從“引入期”開始,重新一輪新的循環!
而作為產品經理,在經手一個項目的時候,要清晰的辨別出一個產品所處的階段,衡量一個產品所出的具體階段的標準就是該產品的用戶數量的變化趨勢,如果用戶基數小 ,增長較為緩慢,則處于引入期;如果基數小,增長迅速,則處于成長期;若基數較大,增長緩慢,則處于成熟期;若基數大,用戶有下滑趨勢,則處于衰退期!
9. 用戶需求與公司需求的關系
在做產品設計的時候,一方面要考慮用戶體驗問題,另一方面是要考慮公司盈利問題。這兩個問題都很重要,但是同時往往不可兼得,如果平衡好這兩者的關系,是一件很重要的事情,兩個的關系如下
- 分離關系
- 交集關系
- 包含關系
分離關系
這種情況完全把用戶需求與公司需求割裂開來,或者說用戶需求與公司需求是矛盾的關系,完全考慮用戶需求,改善用戶體驗,會極大地影響公司收益,但是如果完全考慮公司收益,又會讓用戶體驗很糟糕!例如在早期的網站上,會彈出各式各樣的廣告,這些廣告是強行彈出的,甚至會遮擋用戶感興趣的內容,只有通過手動關閉廣告的形式才能繼續瀏覽。在產品設計的時候要盡量避免這種情況的出現!
交集關系
用戶需求與公司需求有一部分是相通的,在盡量不影響用戶體驗的情況下,同時滿足公司的盈利目標。例如豆瓣在提供書籍/電影評分的同時,還提供了對應的購買網址,用戶通過網址購買圖書可以為公司賺取利潤,但是基本上不會影響用戶瀏覽書籍/電影的評價,用戶體驗得到了較好的保證!其實這種方式也是當前絕大多數產品所采用的方式!
包含關系
這種關系是一種比較高級的關系,完全把公司需求與用戶需求融合在了一起,這里直接用實例說明,例如有些公眾號會通過一篇優質的文章來宣傳自己的商品,假設筆者作為商家想賣一把雨傘,那么會撰寫一篇關于雨傘的文章,在這篇文章之中,把雨傘的制作過程所經歷的選材、工藝、后期處理比較好的展現出來,字里行間夾雜著筆者的情懷與感悟。那么用戶在閱讀筆者的這篇文章的時候,會被里面的內容所深深的吸引,雖然用戶知道這是一篇廣告軟文,但是依然愿意為此買單,甚至會期待筆者的下一篇文章,并主動分享到朋友圈,起到了一個良好的傳播作用!這種關系市面上的產品比較少,其實利用大數據、數據挖掘等技術給用戶推薦特定的廣告也算是一個很好地案例!同時這種關系也是以后產品設計的發展方向!
在我們進行產品設計的時候,采用哪種方式自然不言而喻~
關于需求分析的章節就暫時分析到這里,也期待著各位能夠多提出自己的意見與想法~
作者:MING,個人公眾號:MING的大航海,知乎專欄:產品見知錄
本文由 @MING 原創發布于人人都是產品經理。未經許可,禁止轉載。
寫的太好了,干貨滿滿
這篇文章實在是太棒了!一文講清楚了需求分析的過程,非常棒?。。?!
真的好棒 產品小白感覺要讀上好幾遍,太干貨了。真的是收獲很多
能否加個微信 哈哈哈哈哈哈哈哈哈哈
文章寫的很棒,從各個方面闡述了需求關系,內容豐富但不冗雜,又很好的講述了本文觀點。很多干貨
文章很好,作為需求的綜述類介紹,完整而有重點的介紹了需求的方方面面,但是又不會陷入到細節里面去。
其中第6點需求轉化會特別管用,因為將實操流程拆解清晰,可以分步驟來評估目前自己的工作。
第8點也是,用產品本身的周期來解釋需求優先級管理,可以避免自己過早陷入到交互跟細節上,錯失產品的時機。
一點小建議,文章一開始的結構只寫了3點,而不是實際的8點??梢圆捎脙杉墭祟}的形式讓文章更清晰(個人習慣)
寫的太棒了,我個人覺得流程圖可以用腦圖畫,用戶在不同模塊中的流程用腦圖畫出來子功能點,然后所有的流程組合好,就成了產品架構圖。然后可以從需求出發對這些流程進行分析,挖掘滿足需求的其他功能點。
謝謝肯定哈,我會努力鏟除更多的文章的~