用戶需求分析用戶研究方法大全

1. 用戶研究方法有哪些如何進行定性和定量的研究

基於問題的性質、變數的類型以及其他因素選擇一定的研究方法，來收集與問題有關的主客觀數據，進而為了解某些未來知的東西或者驗證某種想法提供依據。
用戶研究有很多方法，基於對已有知識的總結可知，影響研究方法選擇的因素主要以下因素：研究的對象、產品的設計階段、產品所處周期、成本、時間等。通常自情況下：
（1）根據收集的數據類型，可以將研究方法劃分為定性和定量兩種，見圖1。
定性研究方法，通常適用於對小數量規模的樣本進行分析，主要用於發現新事物的過程，揭露為什麼會發生這樣的事情，樣本數量通常為10~20個，不追求精確的結論，而只是了解問題之所在，摸清情況，得出感性認識，比如用戶訪談、卡片分類法、焦點小組、頭腦風暴、可用性測試等，見圖2。
定量研究方法，則是對大規模的樣本進行分析，適用於揭露正在發生的事情，一般是為了對特定研究對象的總體得出統計結果而進行的，比如在線大規模調查問卷、網站日誌分析以及A/B測試、自動化可用性測試等。

2. 需求分析常用方法

行為事件分析

行為事件分析是根據運營關鍵指標對用戶特定事件進行分析。通過追蹤或記錄用戶行為事件，可以快速的了解到事件的趨勢走向和用戶的完成情況。

以用戶投標的行為事件為例，出借人在完成投標過程中，所進行的注冊、認證、開戶、充值、投資等行為，都可以定義為事件，也是完成投標成功的一個完整事件。
確定投標行為事件後，我們可以根據事件屬性細分維度：用戶來源、性別、出生年月、注冊時間、綁卡時間、首次充值時間、首次投資時間、標的ID，標名、期限、利率、還款方式等。然後從中找出符合指標的規律，並制定針對性的措施。

用戶留存分析

用戶留存分析是一種用來分析用戶參與情況與活躍程度的模型。通過留存量和留存率，可以了解用戶的留存和流失狀況。比如用次日留存、周留存、月留存等指標來衡量產品的人氣或粘度。以渠道訪問的用戶留存為例，我們對APP端有過訪問行為的渠道用戶進行留存分析。用戶留存一般符合40-20-10法則，即新用戶的次日留存應該大於40%，周留存大於20%，月留存大於10%才符合業務標准。我們做用戶留存分析主要驗證是否達到既定的運營目標，進而影響下一步的產品決策。

漏斗模型分析

漏斗模型分析是用戶在使用產品過程中，描述各個階段中關鍵環節的用戶轉化和流失率情況。比如在日常活動運營中，通過確定各個環節的流失率，分析用戶怎麼流失、為什麼流失、在哪裡流失。找到需要改進的環節，要重點關注，並採取有效的措施來提升整體轉化率。

邀請人將活動專題頁分享給好友，之後進行的注冊、認證、開戶、充值到投資，用漏斗模型分析一些關鍵節點的轉化率。其中用戶注冊轉化率為68%，實名認證轉化率為45%，綁卡開戶轉化率為29%，線上充值轉化率為17%，投資標的轉化率為8%。
漏斗模型分析可以驗證整個流程的設計是否合理。經過對比發現，訪問到注冊的轉化率為68%，遠低於預期的80%。這次運營策略是用戶必須先注冊才能領取新手福利。之後採取A/B測試的方式，優化為先領取新手福利再誘導用戶注冊。經過數據對比分析，注冊轉化率提升了20%。因此，通過對各環節相關轉化率的比較，可以發現運營活動中哪些環節的轉化率沒有達到預期指標，從而發現問題所在，並找到優化方向。

行為路徑分析

行為路徑分析就是分析用戶在產品使用過程中的訪問路徑。通過對行為路徑的數據分析，可以發現用戶最常用的功能和使用路徑。並從頁面的多維度分析，追蹤用戶轉化路徑，提升產品用戶體驗。

不管是產品冷啟動，還是日常活動營銷，做行為路徑分析首先要梳理用戶行為軌跡。用戶行為軌跡包括認知、熟悉、試用、使用到忠誠等。軌跡背後反映的是用戶特徵，這些特徵對產品運營有重要的參考價值。我們可以記錄用戶從注冊、認證、開戶、充值到投資的行為軌跡。通過分析用戶的這些行為軌跡數據，來驗證訪問路徑是否和預期指標的一致。

3. 超實用的用戶研究方法

      真實的用戶可能是個圓形，但是產品經理對用戶的定義可能進行了一個變形，可能是個橢圓形，但是產品經理了解到的定義已經開始變形了，到最終我們實現開發之後的效果可能和真實的用戶差別很大。那麼用戶研究的意義就是最大限度的接觸到真實的用戶，最大限度的還原我們的用戶。讓產品更符合用戶的使用習慣。

下面介紹三種比較常用的用戶研究方法，把需要注意的問題，實際操作的步驟跟大家分享，這些都是在項目中很通用也很大概率遇到的使用方法。

態度類信息：滿意度調研、內容偏好調研

行為類信息：行為習慣調查、使用情況調查、需求挖掘

意見類信息：產品功能、服務、售後等意見反饋

Q : 為什麼一定要包含被訪者的基本信息問題？劃分人群，核心用戶是什麼人口學信息的

Q : 為什麼要把基本信息題放在最後？

       建議放在後面，在用戶填寫問卷的時候，調研產品滿意度，但是開頭就讓填寫年齡、性別、收入、職業，突然就覺得像是在查戶口，明明調研滿意度，為什麼問些不相乾的問題，用戶警惕心就起來了，所以建議開始做一些簡單的行為類的問題，然後把基本信息放在最後面。把前面的所有信息都填完後，他會覺得我知道你是幹嘛的，再放一些基本信息題，用戶就會更容易接受。

       行為類的、事實類的問題（APP的使用頻率/時長）放在前面，主觀類的放在中間，基本信息放在後面。由淺至深，再到隱私問題。

1.APP使用頻率/時長

2.APP常見功能和使用場景

3.APP使用體驗評價

4.APP新增/優化建議

5.用戶基本信息

問卷的題目最好不要超過 30 個！15-20個是合適的題目數量，人口學信息要3題，主體問題佔10個左右。

       詢問有沒有這種需求？需求的頻率和深度是什麼樣的？需求強烈不？如果需求強烈，願意花多少錢解決這個需求？目前這個需求有沒有被別的競品滿足？如果沒有滿足，是哪方面沒有滿足？這一些列問題投放出去，可以幫助我們衡量商品投放出去，他能夠買的幾率有多大。但是如果直接問買不買偏差會非常大。把需求拆分成不同的細節去驗證。

       滿意度梯度很明顯，非常滿意   比較滿意  一般  不太滿意 非常不滿意，用戶看起來會很順。會知道自己會屬於什麼程度。

       問答題回收率會很低，選擇題思考成本會低。調研10幾個用戶，基本能覆蓋大部分問題，把問題羅列出來，讓他選擇，如果沒有包含到的加一個其他。

        基本上每個問卷前都建議大家做個訪談，如果沒有充分的調研，有50%的人都選了其他，根本不知道其他是什麼，如果其他佔比很多，說明事先沒有做充分的准備去做這個問卷。然後不得不再做一個調研和訪談，來問問這個其他是什麼。所以不如把訪談前置，把所有的選項列舉出來，避免讓太多的用戶去選其他。當你發現把很多問題都列舉出來，選其他的可能只有百分之幾的時候，就說明你對用戶足夠的了解。

用戶會懵，會思考，第一到底和用戶沒有建立新人關系，會關掉。

        每個流程都需要跟業務方反復去對，包括做項目之前小組之內要討論的非常清楚，現在有什麼問題我們是不知道的，這次問卷要幫我們解決什麼問題，可能影響因素，先去做幾個訪談，先去看一看。比如做新項目，對背景人群都不太了解，直接去設計問卷可能不知道是為什麼。問了之後，選項也不知道怎麼設置。

選項超過 6~7 個的時候，可以考慮設置選項隨機排列

Q：您使用過哪些導購類的APP？

A.拼多多B.折800 C.返利網D.什麼值得買

E.卷皮F.一淘網G.蘑菇街H.其他

在選項不能完全列舉的情況下，需要添加「其他」選項

Q：您在使用分期的時候有哪些不滿？

A.申請麻煩B.申請額度低C.分期利息高D.擔心忘還款E.商品價格比市面高F.其他

選項超過 10 個，需要設置先選個數，一般設置為3個或5個。

Q：您在使用分期的時候有哪些不滿？

A.申請麻煩B.申請額度低C.分期利息高D.擔心忘還款E.商品價格比市面高F.其他

當出現「以上都不是」「我不知道」「沒有我想選的」等選項，當出現這類選項時，需要設置互斥選項

Q：您在網上繳過哪些生活費用？

A.電費B.水費C.燃氣費D.寬頻費用E.都沒在網上交過

當問題只針對選擇了某個選項的部分用戶，需要給題目設置出現條件或跳轉邏輯

Q：您使用過以下哪些產品？

Q：您認為拼多多有什麼優勢？

1.初稿完成後，需要使用問卷至少對1-2個用戶進行試訪談

2.試訪中可能會出現很多問題：

• 問卷問題有歧義

• 缺少選項

• 題目邏輯不對

投放合適的人群

•投放群體與目標群體一致

•抽樣需要配比

回收多少份問卷才能代表整體？

1.看總計數據，確定總趨勢

2.對比、對比、對比，找差異

•不同人群之間

• 不同機型之間

• 不同競品之間

•……

Q：用戶升級系統的動力是什麼？       

A：新版本要有更明顯的更新和性能的超越

開發版VS 穩定版

發現穩定版用戶更擔心卡頓、不穩定的問題

為什麼？對比機型內存，發現穩定版用戶配置不如開發版用戶，容量較小

用戶訪談的小技巧

先讓用戶主動回答潛意識的答案，

如果用戶不知所錯，再給出參考選項

提前准備每個問題可能的假設答案，直到挖掘出用戶本質需求

然後呢

用戶訪談之後可以做什麼

人物角色

在各大互聯網公司，被認為是最具價值的研究方法

可用性測試是指讓用戶使用產品(服務)的設計原型或者成品，通過觀察，記錄和分析用戶的行為和感受，並加以 分析，用以改善產品(服務)可用性的一系列方法

可用性測試提供了這樣一種簡單直接的溝通方式。通過這種方式獲得用戶反饋，並以此為設計依據迅速調整產品功能乃至產品方向。

小到一個圖標的辨識，頁面導航，功能使用，大到某項業務的辦理，都可以拿來做可用性測試

• 影響任務完成的行為

• 導致用戶「偏離航線」的行為

• 用戶表達出來的挫敗感

•沒有看到本該看到的內容

• 用戶自己說已經完成任務但實際未完成

• 導致任務偏離成功完成的操作

•對內容的錯誤理解

• 使用網頁導航時，點擊了錯誤的鏈接

5-8 個

明確這是這是一個定性研究，根據尼爾森關於可用性測試的數據研究，5-8人便可以找到產品80%以上的可用性問題；

任務成功率=(完全完成的用戶數+求助後完成*0.5)/用戶總數

版本改進比較：優化前用時VS優化後用時

不同任務的效率水平：用戶的平均用時/熟練用時所得的倍數

產品規劃：訪談法、問卷調查法

設計開發：kano模型、可用性測試

上線效果：NPS、可用性測試

4. 如何進行用戶需求分析

1.概念
需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.
關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".
百事通
而實際上,UGGs,需求並未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.
需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等".這些定義強調的是產品是什麼樣的,而並非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:
需求是指明必須實現什麼的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.
從上面這些不同形式的定義不難發現:並沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶並不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.
任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.
2.需求分析的任務
開發軟體系統最為困難的部分就是准確說明開發什麼.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟體系統的介面.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,並且以後再對它進行修改也極為困難.
目前,國內產品的龐雜,一家企業可能有幾個系統並立運行,它們之間介面是系統開發人員最頭痛的問題.
對於商業最終用戶應用程序,企業信息系統和軟體作為一個大系統的一部分的產品是顯而易見的.但是對於我們開發人員來說,並沒有編寫出客戶認可的需求文檔,我們如何知道項目於何時結束?而如果我們不知道什麼對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?
然而,即便並非出於商業目的的軟體需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟體.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重復返工這種不可避免的後果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟體開發者身上發生.
近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟體.不幸的是,當他們開發完這個工具後,發現這個工具不能列印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤並構思准確,如果我們沒有編寫文檔,軟體達不到期望目標也只能是咎由自取了.
相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此系統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.
事實上,需求文檔在開發過程中一直起指導作用.
3.需求分析過程
可把整個軟體需求工程研究領域劃分為需求開發和需求管理兩部分更合適,如圖4-1所示:
圖4-1 需求工程域的層次分解示意圖
需求開發可進一步分為:問題獲取、分析、編寫規格說明和驗證四個階段.這些子項包括軟體類產品中需求收集、評價、編寫文檔等所有活動.需求開發活動包括以下幾個方面:
確定產品所期望的用戶類別.
獲取每個用戶類的需求.
了解實際用戶任務和目標以及這些任務所支持的業務需求.
分析源於用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息.
將系統級的需求分為幾個子系統,並將需求中的一部份分配給軟體組件.
了解相關質量屬性的重要性.
商討實施優先順序的劃分.
將所收集的用戶需求編寫成文檔和模型.
評審需求規格說明,確保對用戶需求達到共同的理解與認識,並在整個開發小組接受說明之前將問題都弄清楚.
需求管理需要"建立並維護在軟體工程中同客戶達成的合同" .這種合同都包含在編寫的需求文檔與模型中.客戶的接受僅是需求成功的一半,開發人員也必須能夠接受他們,並真正把需求應用到產品中.通常的需求管理活動包括:
定義需求基線(迅速制定需求文檔的主體).
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它.
以一種可控制的方式將需求變更融入到項目中.
使當前的項目計劃與需求一致.
估計變更需求所產生影響並在此基礎上協商新的承諾,這種承諾具體體現在項目解決方案上.
讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤.
在整個項目過程中跟蹤需求狀態及其變更情況.
以上幾點說明是我總結了成功實施項目後系統分析人員的經驗,同時也根據國內外的其他系統實施的相關成功經驗,進行了總結.
4.需求的類型
下面這些定義是需求工程領域中常見術語的定義.
軟體需求包括三個不同的層次:業務需求、用戶需求和功能需求(也包括非功能需求).
1.業務需求(business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求,它們在項目視圖與范圍文檔中予以說明.
2.用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務,這在使用實例(use case)文檔或方案腳本說明中予以說明.
3.功能需求(functional requirement)定義了開發人員必須實現的軟體功能,使得用戶能完成他們的任務,從而滿足了業務需求.
在軟體需求規格說明書 (SRS)中說明的功能需求充分描述了軟體系統所應具有的外部行為.軟體需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用.對一個大型系統來說,軟體功能需求也許只是系統需求的一個子集,因為另外一些可能屬於子系統(或軟體部件).
作為功能需求的補充,軟體需求規格說明還應包括非功能需求,它描述了系統展現給用戶的行為和執行的操作等.它包括產品必須遵從的標准、規范和合約;外部界面的具體細節;性能要求;設計或實現的約束條件及質量屬性.所謂約束是指對開發人員在軟體產品設計和構造上的限制.質量屬性是通過多種角度對產品的特點進行描述,從而反映產品功能.多角度描述產品對用戶和開發人員都極為重要.
下面以一個字處理程序為例來說明需求的不同種類.業務需求可能是:"用戶能有效地糾正文檔中的拼寫錯誤",該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器.而對應的用戶需求可能是"找出文檔中的拼寫錯誤並通過一個提供的替換項列表來供選擇替換拼錯的詞".同時,該拼寫檢查器還有許多功能需求,如找到並高亮度提示錯詞的操作;顯示提供替換詞的對話框以及實現整個文檔范圍的替換.
從以上定義可以發現,需求並未包括設計細節、實現細節、項目計劃信息或測試信息.需求與這些沒有關系,它關注的是充分說明你究竟想開發什麼.項目也有其它方面的需求,如開發環境需求或發布產品及移植到支撐環境的需求.盡管這些需求對項目成功也至關重要,但它們並非本書所要討論的.
5.需求分析的原則
不重視需求過程的項目隊伍將自食其果.需求工程中的缺陷將給項目成功帶來極大風險,這里的"成功"是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望.下面將討論一些需求風險.
不適當的需求過程所引起的一些風險:
1. 無足夠用戶參與
客戶經常不明白為什麼收集需求和確保需求質量需花費那麼多功夫,開發人員可能也不重視用戶的參與.究其原因:一是因為開發人員感覺與用戶合作不如編寫代碼有意思;二是因為開發人員覺得已經明白用戶的需求了.在某些情況下,與實際使用產品的用戶直接接觸很困難,而客戶也不太明白自己的真正需求.但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中,並一同經歷整個開發過程.
系統人員在實踐過程中,也有些感覺,在實施一家公司的項目時,若無足夠的用戶參與,系統人員獲得的需求是片面的,不完整的,這樣系統在需求之初就埋下風險.
2. 用戶需求的不斷增加
在開發中若不斷地補充需求,項目就越變越龐大以致超過其計劃及預算范圍.計劃並不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致,這使得問題更難解決.實際上,問題根源在於用戶需求的改變和開發者對新需求所作的修改.
要想把需求變更范圍控制到最小,必須一開始就對項目視圖、范圍、目標、約束限制和成功標准給予明確說明,並將此說明作為評價需求變更和新特性的參照框架.說明中包括了對每種變更進行變更影響因素分析的變更控制過程,有助於所有風險承擔者明白業務決策的合理性,即為何進行某些變更,相應消耗的時間、資源或特性上的折中.
產品開發中不斷延續的變更會使其整體結構日漸紊亂,補丁代碼也使得整個程序難以理解和維護.插入補丁代碼使模塊違背強內聚、松耦合的設計原則,特別是如果項目配置管理工作不完善的話,收回變更和刪除特性會帶來問題.如果你盡早地區別這些可能帶來變更的特性,你就能開發一個更為健壯的結構,並能更好地適應它.這樣設計階段需求變更不會直接導致補丁代碼,同時也有利於減少因變更導致質量的下降.
3. 模稜兩可的需求
模稜兩可是需求規格說明中最為可怕的問題.它的一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明.
模稜兩可的需求會使不同的風險承擔者產生不同的期望,它會使開發人員為錯誤問題而浪費時間,並且使測試者與開發者所期望的不一致.一位系統測試人員曾告訴我,她所在的測試組經常對需求理解有誤,以致不得不重寫許多測試用例並重做許多測試.
處理模稜兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍.僅僅簡單瀏覽一下需求文檔是不能解決模稜兩可問題的.如果不同的評審者從不同的角度對需求說明給予解釋,但每個評審人員都真正了解需求文檔,這樣二義性就不會直到項目後期才被發現,那時再發現的話會使得更正代價很大.
4. 不必要的特性
"畫蛇添足"是指開發人員力圖增加一些"用戶欣賞"但需求規格說明中並未涉及的新功能.經常發生的情況是用戶並不認為這些功能性很有用,以致在其上耗費的努力"白搭"了.開發人員應當為客戶構思方案並為他們提供一些具有創新意識的思路,具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡,開發人員應努力使功能簡單易用,而不要未經客戶同意,擅自脫離客戶要求,自作主張.
同樣,客戶有時也可能要求一些看上去很"酷",但缺乏實用價值的功能,而實現這些功能只能徒耗時間和成本.為了將"畫蛇添足"的危害盡量減小,應確信:你明白為什麼要包括這些功能,以及這些功能的"來龍去脈",這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能.
5. 過於精簡的規格說明
有時,客戶並不明白需求分析有如此重要,於是只作一份簡略之至的規格說明,僅涉及了產品概念上的內容,然後讓開發人員在項目進展中去完善,結果很可能出現的是開發人員先建立產品的結構之後再完成需求說明.這種方法可能適合於尖端研究性的產品或需求本身就十分靈活的情況.但在大多數情況下,這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作),也會給客戶帶來煩惱(他們無法得到他們所設想的產品).
6. 忽略了用戶分類
大多數產品是由不同的人使用其不同的特性,使用頻繁程度也有所差異,使用者受教育程度和經驗水平也不盡相同.如果你不能在項目早期就針對所有這些主要用戶進行分類的話,必然導致有的用戶對產品感到失望.例如,菜單驅動操作對高級用戶太低效了,但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難.
7. 不準確的計劃
據統計,導致需求過程中軟體成本估計極不準確的原因主要有以下五點:頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析.
對不準確的要求所提問題的正確響應是"等我真正明白你的需求時,我就會來告訴你".基於不充分信息和未經深思的對需求不成熟的估計很容易為一些因素左右.要作出估計時,最好還是給出一個范圍.未經准備的估計通常是作為一種猜測給出的,聽者卻認為是一種承諾.因此我們要盡力給出可達到的目標並堅持完成它.
6.需求分析人員和用戶的合作關系
優秀的軟體產品是建立在優秀的需求基礎之上的.而高質量的需求來源於客戶與開發人員之間有效的交流與合作.通常,開發人員與客戶或客戶代理人,如市場人員間的關系反而會成為一種對立關系.雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦,在這種情況下,不會給雙方帶來一點益處.
只有當雙方參與者都明白要成功自己需要什麼,同時也應知道要成功合作方需要什麼時,才能建立起一種合作關系.由於項目壓力與日漸增,所有風險承擔者有著一個共同的目標這一點容易被遺忘.其實大家都想開發出一個既能實現商業價值,又能滿足用戶需要,還能使開發者感到滿足的優秀軟體產品.
軟體客戶需求權利書列出了十條關於客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求.每一項權利都對應著軟體開發人員、分析人員的義務.而軟體客戶需求義務書也列出了十條關於客戶在需求過程中應承擔的義務.如果願意,可以將其作為開發人員的權利書.
客戶有如下權利:
1:要求分析人員使用符合客戶語言習慣的表達
需求討論應集中於業務需要和任務,故要使用業務術語,你應將其教給分析人員,而你 不一定要懂得計算機的行業術語.
2:要求分析人員了解客戶的業務及目標
通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業務任務和怎樣才能使產品更好地滿足你的需要.這將有助於開發人員設計出真正滿足你的需要並達到你期望的優秀軟體.為幫助開發人員和分析人員,可以考慮邀請他們觀察你或你的同事是怎樣工作的.如果新開發系統是用來替代已有的系統,那麼開發人員應使用一下目前的系統,這將有利於他們明白目前系統是怎樣工作的,其工作流程的情況,以及可供改進之處.
3:要求分析人員編寫軟體需求規格說明
分析人員要把從你和其他客戶那裡獲得的所有信息進行整理,以區分開業務需求及規范、功能需求、質量目標、解決方法和其它信息.通過這些分析就能得到一份軟體需求規格說明.而這份軟體需求規格說明便在開發人員和客戶之間針對要開發的產品內容達成了協議.軟體需求規格說明書可以用一種你認為易於翻閱和理解的方式組織編寫.要評審編寫出的規格說明以確保它們准確而完整地表達了你的需求.一份高質量的軟體需求規格說明能有助於開發人員開發出真正需要的產品.
4:要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文字性軟體需求規格說明的補充.因為如工作流程圖那樣的圖表能很清楚地描述出系統行為的某些方面.所以需求說明中的各種圖表有著極高的價值.雖然它們不太難於理解,但是你很可能對此並不熟悉.因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發工作結果和符號的意義,及怎樣檢查圖表有無錯誤及不一致等.
5:要求開發人員尊重你的意見
如果用戶與開發人員之間不能相互理解,那關於需求的討論將會有障礙,共同合作能使大家"兼聽則明".參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間.同樣,客戶也應對開發人員為項目成功這一共同目標所作出的努力表示尊重與感激.
6:要求開發人員對需求及產品實施提供建議,拿出主意
通常,客戶所說的"需求"已是一種實際可能的實施解決方案,分析人員將盡力從這些解決方法中了解真正的業務及其需求,同時還應找出已有系統不適合當前業務之處,以確保產品不會無效或低效.在徹底弄清業務領域內的事情後,分析人員有時就能提出相當好的改進方法.有經驗且富有創造力的分析人員還能提出增加一些用戶並未發現的很有價值的系統特性.
7:描述產品易使用的特性
你可以要求分析人員在實現功能需求的同時還要注重軟體的易用性.因為這些易用特性或質量屬性能使你更准確、高效地完成任務.例如,客戶有時要求產品要"用戶友好"或"健壯"或"高效率",但這對於開發人員來說,太主觀了並無實用價值.正確的應是:分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性.
8:調整需求,允許重用已有的軟體組件
需求通常要有一定的靈活性.分析人員可能發現已有的某個軟體組件與你描述的需求很相符.在這種情況下,分析人員應提供一些修改需求的選擇以便開發人員能夠在新系統開發中重用一些已有的軟體.如果有可重用的機會出現,同時你又能調整你的需求說明,那就能降低成本和節省時間,而不必嚴格按原有的需求說明開發.所以說,如果想在產品中使用一些已有的商業常用組件,而它們並不完全適合你所需的特性,這時一定程度上的需求靈活性就顯得極為重要了.
9:獲得滿足客戶功能和質量要求的系統
每個人都希望項目獲得成功.但這不僅要求你要清晰地告知開發人員關於系統"做什麼"所需的所有信息,而且還要求開發人員能通過交流了解清楚取捨與限制.一定要明確說明你的假設和潛在的期望.否則,開發人員開發出的產品很可能無法讓你滿意.
客戶有下列義務:
1:給分析人員講解你的業務
分析人員要依靠你給他們講解的業務概念及術語.但你不能指望分析人員會成為該領域的專家,而只能讓他們真正明白你的問題和目標.不要期望分析人員能把握你們業務的細微與潛在之處,他們很可能並不知道那些對於你和你的同事來說理所當然的"常識".
2:抽出時間清楚地說明並完善需求
客戶很忙,經常在最忙的時候還得參與需求開發.但無論如何,你有義務抽出時間參與"頭腦風暴"會議的討論,接受采訪或其它獲取需求的活動.有時分析人員可能先以為明白了你的觀點,而過後發現還需要你的講解.這時,請耐心一些對待需求和需求的精化工作過程中的反復,因為它是人們交流中的很自然的現象,何況這對軟體產品的成功極為重要.
3:准確而詳細地說明需求
編寫一份清晰、准確的需求文檔是很困難的.由於處理細節問題不但煩人而且又耗時,故很容易留下模糊不清的需求.但是,在開發過程中,必須得解決這種模糊性和不準確性.而你恰是為解決這些問題作出決定的最佳人選.不然的話,你就只好靠開發人員去正確猜測了.在需求規格說明中暫時加上待定(to be determined, TBD也可採用漢語拼音略寫"DQD:待確定")的標志是個不錯的辦法.用該標志可指明了哪些需要進一步探討、分析或增加信息的地方.不過,有時也可能因為某個特殊需求難以解決或沒有人願意處理它而註上TBD標志.盡量將每項需求的內容都闡述清楚,以便分析人員能准確的將其寫進軟體需求規格說明中.如果你一時不能准確表述,那就得允許獲取必要的准確信息這樣一個過程.通常使用所謂的原型技術.通過開發的原型,你可以同開發人員一起反復修改,不斷完善需求定義.
4:及時地作出決定
正如一位建築師為你修建房屋,分析人員將要求你做出一些選擇和決定.這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等.有權做出決定的客戶必須積極地對待這一切,盡快做處理、做決定.因為開發人員通常只有等你做出了決定才能行動,而這種等待會延誤項目的進展.
5:尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本價格,開發人員最適合預算這些成本(盡管許多開發人員並不擅長評估預測).你所希望的某些產品特性可能在技術上行不通,或者實現它要付出極為高昂的代價.而某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的數據,開發人員會對此作出負面的評價意見,你應該尊重他們的意見.有時,你可以重新給出一個在技術上可行、實現上便宜的需求,例如,要求某個行為在"瞬間"發生是不可行的,但換種更具體的時間需求說法("在50ms以內",但若沒有準確的技術分析不能輕易下結論),這就可以實現了.
6: 劃分需求優先順序別
大多數項目沒有足夠的時間或資源來實現功能性的每個細節.決定哪些特性是必要的,哪些是重要的,哪些是好的,是需求開發的主要部分.只能由你來負責設定需求優先順序,因為開發者並不可能按你的觀點決定需求優先順序.開發者將為你確定優先順序提供有關每個需求的花費和風險的信息.當你設定優先順序時,你幫助開發者確保在適當的時間內用最小的開支取得最好的效果.在時間和資源限制下,關於所需特性能否完成或完成多少應該尊重開發人員的意見.盡管沒有人願意看到自己所希望的需求在項目中未被實現,但畢竟是要面對這種現實的.業務決策有時不得不依據優先順序來縮小項目范圍或延長工期,或增加資源,或在質量上尋找折衷.
7:評審需求文檔和原型
正如我們將在第1 4章討論的,無論是正式的還是非正式的方式,對需求文檔進行評審都會對軟體質量提高有所幫助.讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性.評審也給客戶代表提供一個機會,給需求分析人員帶來反饋信息以改進他們的工作.如果你認為編寫的需求文檔不夠准確,就有義務盡早告訴分析人員並為改進提供建議.通過閱讀需求規格說明,很難想像實際的軟體是什麼樣子的.更好的方法是先為產品開發一個原型.這樣你就能提供更有價值的反饋信息給開發人員,幫助他們更好地理解你的需求.必須認識到:原型並非是一個實際產品,但開發人員能將其轉變、擴充成功能齊全的系統.
8:需求出現變更要馬上聯系
不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響.變更是不可避免的,但在開發周期中變更越在晚期出現,其影響越大.變更不僅會導致代價極高的返工,而且工期也會被迫延誤,特別是在大體結構已完成後又需要增加新特性時.所以一旦你發現需要變更需求時,請一定立即通知分析人員.
9:應遵照開發組織處理需求變更的過程
為了將變更帶來的負面影響減少到最低限度,所有的參與者必須遵照項目的變更控制過程.這要求不放棄所有提出的變更,對每項要求的變更進行分析、綜合考慮,最後作出合適的決策以確定將某些變更引入項目中.
10:尊重開發人員採用的需求工程過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性.分析人員採用的方法有其合理性.也許你認為需求過程不太劃算,但請相信花在需求開發上的時間是"很有價值"的.如果你理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術,那麼整個過程將會更為順利.盡管去詢問分析人員為什麼他們要收集某些信息,或參與與需求有關的活動.
系統分析人員在開發過程中可能會遇到以下問題,一些很忙的客戶可能不願意積極參與需求過程,而缺少客戶參與將很可能導致不理想的產品.故一定要確保需求開發中的主要參與者都了解並接受他們的義務.如果遇到分歧,通過協商以達成對各自義務的相互理解,這樣能減少今後的摩擦.
7.需求文檔
需求開發的最終成果是:客戶和開發小組對將要開發的產品達成一致協議.協議綜合了業務需求、用戶需求和軟體功能需求.就像我們早先所看到的,項目視圖和范圍文檔包含了業務需求,而使用實例文檔則包含了用戶需求.你必須編寫從使用實例派生出的功能需求文檔,還要編寫產品的非功能需求文檔,包括質量屬性和外部介面需求.只有以結構化和可讀性方式編寫這些文檔,並由項目的風險承擔者評審通過後,各方面人員才能確信他們所贊同的需求是可靠的.
你可以使用以下三種方法編寫軟體需求規格說明:
用好的結構化和自然語言編寫文本型文檔.
建立圖形化模型,這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系.
編寫形式化規格說明,這可以通過使用數學上精確的形式化邏輯語言來定義需求.
由於形式化規格說明具有很強的嚴密性和精確度,因此,所使用的形式化語言只有極少數軟體開發人員才熟悉,更不用說客戶了.雖然結構化的自然語言具有許多缺點,但在大多數軟體工程中,它仍是編寫需求文檔最現實的方法.包含了功能和非功能需求的基於文本的軟體需求規格說明已經為大多數項目所接受.圖形化分析模型通過提供另一種需求視圖,增強了軟體需求規格說明.

5. 用戶需求調研分析

1、明確調研目標

2、選取調研對象

3、確認調研方法：訪談、問卷、競品分析、數據分析……

4、執行調研計劃

5、總結歸納輸出調研報告

1、產品定位：即產品做什麼、核心價值、差異化，一句話概括：該產品主要向**用戶提供**功能，具有**特色

2、標桿產品：國內外競品，共有功能、差異功能

3、典型用戶：用戶分別有哪幾類，每一類用戶的核心需求又是什麼，分析用戶的特點、行為

4、核心功能：找出核心功能有哪些，分別滿足用戶的哪些核心需求

5、核心內容：用戶最關注哪些內容，哪些內容能吸引用戶

6、商業模式：即如何賺錢盈利，如收入分成、廣告、商城等

1、信息的二次確認：重復對方的需求，並問對方自己是否理解的正確，保證充分的理解。

2、陳述事實，在溝通的過程中，陳述需求完成的基本條件，以解決需求問題作為溝通。

3、提供1~2種建議的解決方案，並引導對方，給對方做選擇題，加快溝通目標達成一致。

做需求調研，一般都會要輸出成果。非正式的話就給一份需求調研表，整理收集到的需求列出，然後給到用戶簽字確認。正式一點的需要一份調研分析報告。PS：需求調研一定要有記錄，且最好是被調研對象簽字&蓋章確認，然後存檔。為什麼呢，不僅僅是作為溝通記錄的存檔，同時也是為了避免後期用戶再做需求驗收時不承認或遺忘以及需求調整過程反復變更需求的依據。

那麼這個分別怎麼寫呢？

1、需求調研表： 可以分系統名稱、需求模塊、需求描述（可加附頁）、調研時間、調研對象、調研地點、調研人員、調研對象確認（簽字）、日期這幾部分。模板可參考如下：

1、需求調研報告： 可寫明背景目的，調研過程（范圍、方式、計劃），調研的成果（客戶的概況、基本情況、組織架構、業務流程梳理、需求及分析總結等）

可參考以下文檔的目錄結構，具體可以根據實際情況進行增減

產品喵🐱小結：

在做需求調研分析時，我們不能只是簡單的記錄堆砌未經分析的需求，而是需要對收集到的需求進行分析思考清楚（邏輯性、必要性）。不能被用戶帶偏直接採用用戶給的解決方案，而應該要去了解清楚業務現狀、痛點所在，進一步的挖掘出用戶的潛在需求。在現有的技術條件下，尋求可能的最優的解決方案。

最後總結關於需求必要性的幾個關鍵詞—— 大眾、主流、高頻、剛需 。

2019/12/23（2021.07更新）

By  dandan米娜

6. 用戶體驗研究方法及分析方法是哪些

需求

1.用戶和客戶是誰？

（1）調查（survey）：發現用戶是誰、他們想要什麼、他們在做什麼、他們買什麼、他們在哪裡購物以及他們擁有什麼的最便宜的方式就是調查他們。

（2）用戶角色/市場細分（persona/market segmentation）：將調查結果轉換為有意義的聚類。特定用戶群想要什麼樣的功能、他們在做購買決定時最在乎什麼？不要僅僅考慮性別、收入和年齡，把任務和領域經驗也作為關鍵的區分指標。

（3）競品分析（competitive analysis）：很少會有一個產品或網站之前從來沒有人做過。了解你的市場，找出市場上的類似公司並將眼光投向類似行業。有哪些特性是共同的？什麼能夠討得客戶的歡心？使用行業基準，比如測量口碑的凈推薦分數和測量可用性的系統可用性量表。

（4）現場調查（Contextual Inquiry）：用戶不是總能清楚地說明自己需要什麼或想要什麼。通過在他們的工作場所或家裡觀察用戶如何解決他們的問題和達到他們的目標，我們能夠發現未滿足的需求和理解他們執行的任務。

（5）利害關系人訪談（Stakeholder Interviews）：大量的信息已經存在於公司的不同部門。可以使用結構化訪談的方法來詢問客服、QA、開發、市場和銷售來發現什麼需要建立、修正和排除。

（6）質量功能展開（Quality Function Deployment）：將來自內部利害關系人的想法和來自用戶和客戶的數據整理成矩陣，以理解什麼功能可以滿足大部分的內部和外部需求。

2.用戶想要做什麼？

（1）任務分析（Task Analysis）：將用戶想要完成的事情分解以理解應用應該如何讓任務更有效率和更為有效。

（2）關鍵任務分析（Top Tasks Analysis）：你的應用不能一直為每個人做所有的事情。大部分人使用應用（軟體或網站）只是用來完成一小部分任務。調查你的用戶並找出哪些關鍵任務可以在大部分時間滿足用戶大部分的需求。同事要保證你的應用能夠很好地完成這些任務。

設計和開發

界面看起來怎麼樣？

（1）線框（Wireframing）：早期可以用紙筆、Visio或PowerPoint將界面的主要元素繪制出來。對理解功能、流程和發現改進的機會，這已經足夠了。這可以讓你領先利害關系人而得到設計。

（2）原型（Prototyping）：提高設計的保真度，並盡早和經常地進行測試。

測試和評估

1.如何組織？

（1）卡片分類（Card Sorting）：你要如何稱呼你的功能、屏幕和抽象概念？你要如何組織它們？不要猜測，讓用戶來將這些項目歸類並給每個類別命名。

（2）Tree Testing：使用僅僅一個抽象分類，讓用戶嘗試著在導航上定位項目來測試導航的線框和原型。

（3）首次點擊測試（First Click Testing）：如果用戶去到了錯誤的路徑，他們更可能迷失並在任務上失敗。理解用戶會從哪裡開始。

（4）鍵擊級別模型（Keystroke Level Modeling）：在沒有測試一個用戶的情況下，你也可以對任務完成時長或提出的改進是否增加或降低了完成時長有一些了解。KLM方法用到了一些核心的HCI法則來估計一個技能嫻熟的用戶要花多長時間來完成任務。

（5）啟發式評估（Heuristic Evaluations）：在將問題帶給用戶前提早發現它們。啟發式評估可以發現用戶會遇到的大概30%的問題。理想情況下，你有至少兩名獨立的評估者，他們指導HCI法則和該領域的知識。在浪費有價值用戶的時間前修正這些明顯的問題。

2.用戶會遇到哪些問題？

（1）有主持的個人測試（Moderated In Person Testing）：移動設備測試的理想方法，或者很難遠程地提供原型時，可以在實驗室、會議室甚至過道測試用戶，以了解哪些任務有問題，以及哪些地方有待修正。

（2）有主持的遠程測試（Moderated Remote Testing）：使用廉價和普及的服務如GoTo Meeting 或WebEx，你可以招募世界各地的人來參與任務，甚至可以利用攝像頭來記錄他們的面部表情。不要只是問他們對設計怎麼想，讓他們參與任務，並調查任務的困難度、收集定量數據。

（3）無主持的遠程可用性測試（Unmoderated Remote Usability Testing）：如果你的設計和任務很明確，你可以在網上測試你的原型，用戶可以遠程參與任務而不必面對面。你甚至可以使用熱點來測試圖像。使用諸如UserZoom, Usertesting.com和Loop11的服務來實施結構化的任務和詢問特定問題，你可以在一天得到10多個到上百個用戶的數據結果。按這種方法測試，然後再次測試。

開發和上線

（1）可用性基準研究（Usability Benchmark Study）：可以通過讓一批代表性用戶參與任務來了解網站或軟體的可用性。收集定量數據，使用置信區間來得到可靠的基準。在測試後或研究結束後使用標准化的問卷也是可以的。這些可以在實驗室環境下實施或遠程實施。

（2）無主持的遠程可用性測試（Unmoderated Remote Usability Testing）：你可以使用一個在線網站來讓用戶參與你在關鍵任務分析和構型設計階段確定的任務。你可以記錄點擊，甚至對整個過程進行錄像來觀察用戶在你不在場的情況下會遇到哪些麻煩。

（3）比較性基準研究（Comparative Benchmark Study）：用戶使用你在需求階段確定的競爭性產品來完成一個任務有多困難？招募用戶，使用諸如成功率、時間和任務難度來考察網站的優缺點。有時最好的比較是在不同行業中提供類似服務的一個最佳網站。如果你正在銷售你的移動服務，可以考慮比較DirecTV或Zappos結賬體驗。

（4）A/B測試（A/B Testing）：不要猜，要測試。在你發布產品後設計和改善並沒有結束。測試表單、按鈕、拷貝、圖片和價格。不要害怕測試通配符（wild-card）。

（5）多變數測試（Multivariate Testing）：一次測試一個變數微調網站，但如果你想要測試許多則要花費很長時間，並且你也不知道兩個元素如何相互作用。例如，當你將更低的價格和不同的產品包裝（proct package）結合時，有可能發生出乎意料的事情。你可以在一個在線網站上進行多變數的測試，或在研發環境下利用態度數據而不是實際購買來模擬這一體驗。

（6）調查（Survey）：你的用戶會推薦你的網站或產品嗎？他們信任它並覺得它有吸引力嗎？將你的分數和行業基準比較，並使用標准化的問題。詢問用戶進一步改進的意見，並開放性評論和定量數據聯系起來。

7. UI設計怎麼做用戶需求分析方法有哪些

1. 用戶目標

這里有一些我們要試著回答的問題.這些問題幫助我們理清自己的思路，根據這個思路我們會得到一些答案，這些答案會讓我們知道有什麼需要填補的知識空白？這些都會指導設計過程中每一個細節

2. 我們的設想

我們自己或者我們的團隊首先會有一個自己的目標與事先這一目標的設想，這些是我們相信我們已經知道的。我們團隊的設想是什麼？我們是怎麼理解我們的用戶的？包括他們的行為和對他們需求的潛在解決方案。

3. 具體方法

這些方法告訴我們怎樣去填補知識空白。基於有限時間和有限的用戶，我們該選擇什麼方法？

一旦你回答了上面的問題，整理一份單頁研究計劃給你的領導，你可以從選擇的調研方法中開始收集你需要的知識：

4. 開始動手

通過我們已選擇的方法收集數據。

5. 綜合起來

解決我們用研的問題，證實或推翻我們的假設。解釋我們收集到的數據來發現存在哪些設計可以努力的機會和深藏的點

用戶目標

假定你正處於為一款幫助人們在餓了的時候能立馬有個人送來可口的飯菜這一產品時。你的團隊正在討論是否為送來的菜品拍照促進他們在社交網路中分享該軟體，連同他們的評論一起分享。

「分享外賣美食」團隊某些成員會這么稱呼它並連連點頭「這聽起來很酷，哇塞，好棒棒哦，終於能在朋友圈秀宅男的幸福生活了」 但是你不能明確知道這個功能的適用人群，為什麼用戶想用它。

放下線框製作和代碼編寫，和你團隊成員一起坐下，快速討論你們已經知道和了解的產品目標。為促進這次討論，讓你的團隊成員准備一系列設定的問題來幫助他們辨別他們所需要填補的知識空白。他們最好把這些問題寫在便利貼上，一個問題一個條兒，這樣比較容易管理和討論。

這些設定問題是5個「W」（WHAT、WHEN等等）和1個「H」（HOW）開頭的結構的問句，類似於一個記者寫一篇新聞報道時需要回答的一些問題：

例如：

態度相關設想

「使用外賣軟體的用戶喜歡聽取他們朋友的評論。」

行為相關設想

「外賣用戶只願意分享他們吃的新奇事物，美味事物。」

方法

一旦你確定了研究目標和一堆設計設想，你也需要考慮哪種研究方法適合達到你的目標。通常，為了達到調研目標，我會在以下分類中選擇不止一種方法，把它們結合起來進行調研。

1：實景觀察法

你花時間到用戶生活和工作的地方去，能幫助你建立一個關於他們居住環境和潛在未滿足需求的基本理解。

2：紙質原型

這個領域的方法包括日常研究，卡片分類，紙面原型和其他一些參與式的設計活動。一旦我很好的理解了我的用戶的專業知識和信仰，我就可以開始深層次探究迎合他們需求的內容，功能和產品。這些可以在與研究參與者密切合作中產生潛在設計解決方法時完成，當然也可以在設計設想初期接受他們的真實反饋。

開始動手

當調查結果跟你原來的設想有差異時，不要試圖改變用戶想法，而是站在中立態度上試著詢問原因，了解這是否是用戶的真實想法。

針對調研的問題，進行解決方案設計（此時你最初的設想會大面積瓦解）

需求來源可以大致已經搜集完了，其中產品數據、用研是從產品側提出，更有老大（老闆）敏銳的眼光則是「人為」思考的結果。這個每個老大不同我就不好說了嘛

通過不同渠道收集到一堆需求之後，不可能全部都能做，需要按照一定規則和流程，篩選出來最有價值的需求，將有限的投入產出最大化。這里有個方法就是「關鍵詞檢索」，無論是功能方面的，用戶屬性方面，場景方面，找出簡短的詞或者語句表現出來，能想到的全部寫在便簽條上不要限制自己的思維，貼在黑板上，之後對便簽條上的內容進行分類整合，然後篩選出大家公認最應該留下的。除了後來的用研資料，你一開始的設想如果同隊對用戶的反饋後大致吻合也寫到上面，不吻合的就果斷推翻掉，一定要了解用戶最真實的需求，了解用戶目標，了解用戶的使用場景，了解用戶的使用習慣，這些資料就為我們要設計的產品定位提供了一半的依據。

今天給大家簡單的介紹了用戶需求的內容，和一些比較使用的用戶需求分析方法，了解工作項目中了解用戶的需求是非常重要的，當然這個用戶可能是直接使用你產品的人，也可能是你的老闆。只有了解他們內心的真實想法才能讓你的事情做的更漂亮，得到認可。當然如果你是創業者，需要自己去面對各種個樣的客戶那麼今天所講內容，對你更有意義。

8. 獲取用戶需求的主要方法

需求獲取分四個階段：獲取需求、分析需求、撰寫需求文檔、驗證需求。需求獲取到之後要對需求進行分析，將合理的需求整理成文檔，最後再以文檔為基礎對需求進行評審、驗證。這個步驟可能需要幾次循環，不斷地優化需求。

獲取需求：也叫捕獲需求，需要人為主動地去捕捉。可以通過問卷調查、用戶訪談、競品分析、市場分析等方法獲取。

分析需求：將獲取到的需求進行過濾、分析、加工、整理，最後篩選出真正有價值的需求。在分析需求的過程會用到很多方法，例如使用SWOT分析法分析產品的優勢、劣勢、機會、威脅；使用長尾效應分析法分析產品邊界，分析核心需求、基本需求、滿意需求、期待需求、興奮需求，哪些需求是產品的頭部，哪些需求是產品的尾部，輻射到的用戶范圍有哪些；使用優先順序分析法將需求按重要度、緊急度、影響度進行劃分，區分出需求的優先順序，先開發哪些，再開發哪些。還有以競品對比、用戶偏好、商業價值等從各方面對需求進行分析，最終才能找出真正有價值的需求。

撰寫需求文檔：為了便於需求信息的傳遞和梳理，可以將分析後的需求以文檔的形式記錄下來，並形成規范，以便於與產品有關的人員之間的溝通。需求文檔中要有各模塊、頁面、功能的說明，各功能的輸入、加工和輸出信息，以及各種圖形內容，以便文檔信息更准確的傳遞。

驗證需求：此步驟是論證需求的過程，不是所有經過分析得到的需求都是正確的、合理的，需要通過評審論證以證實需求的正確性和合理性。驗證方式可能是會議評審方式，也可能是主要負責人逐條排查的方式。

如果進入下一個階段，發現有問題怎麼辦？在需求獲取的每個過程都是可逆的，當下一階段出現問題時，需求分析會回滾到上一階段。可以從用戶、網路、公司內部人員、競品、行業動態及內心感知等方面獲取用戶需求，具體介紹如下。

1．直接用戶

這是最直接的獲取用戶需求的方法，用戶會通過語言、情緒、動作、表情來表達自己的好惡，如果產品解決不了用戶的問題，他們就會用腳投票。用戶能明確說出來的都是用戶期望解決的需求，這些都屬於基本需求。有的需求是用戶表達不出的或者根本就沒有意識到的，而這種能夠引領市場、讓產品脫穎而出的需求才是高價值的需求。

2．行業動態

「與天斗，其樂無窮；與地斗，其樂無窮；與人斗，其樂無窮。」做產品要時刻關注行業動態信息，政策環境就屬於產品的「天」，市場環境就屬於產品的「地」，用戶就屬於產品的「人」，我們要隨時關注政策變化、市場環境變化，這樣才能夠保證產品的方向是正確的。這里說的「斗」是研究的意思，多研究產品的大環境，才能在第一時間抓住機遇、把控時機。

3．內部人員

一家公司往往只關注一個行業，公司內的同事都是這個行業的精英，對自己所從事的行業有著較深的感悟。例如運營人員大多關注產品與市場之間的關系，客服人員大多關注著產品與真實用戶之間的關系，業務人員大多關注產品與潛在客戶間的關系……公司內的每個人對產品都有不同的解讀和思考，從他們那裡可能會找到正確的答案。

4．競品分析

當我們剛進入一個行業時，最快速的了解產品的方式就是研究競品。除要研究競品的功能外，還要研究產品功能背後的邏輯和思想。為什麼要這樣做，根據什麼邏輯，能解決用戶什麼問題，用戶的反應是什麼。研究競品並不是要克隆競品，要了解市場、行業及用戶。我們最好能找到真實的數據，用數據來說話，找出哪些功能是用戶最迫切需要的。我們只有更好地了解競品，才能更好地解決問題，為客戶提供更優質的服務。

5．網路信息

調研和獲取需求不一定非要與用戶面對面地溝通，實際上有很多種方式都可以收集到用戶需求，如網站的留言，企業的公眾號、微信、微博等，這些窗口都可以作為與用戶溝通的渠道。

6．內心感知

「樹欲靜而風不止」，用戶的需求是不斷變化的，會因時間、地點、人物角色的不同而不同，每個人看問題的角度都不同，每個人的思想和成長經歷也不同。

同樣的產品在不同時期對用戶的價值也不同，如「大哥大」、BB機在20年前風靡全國，而如今它們已經被淘汰在歷史的長河中。據說，喬布斯是從不做市場調研的，他只是看鏡子中的自己，用心去領悟產品。世上的功夫有很多種，長拳、八仙拳、天羅拳、地煞拳、六星拳等，但我認為最高境界的功夫應該沒有招式，即以無招勝有招，套路是固定的，但現實的變化是無窮的，用有招數的套路去應對無窮的變化一定會失敗。所以最好的需求獲取方式就是用心去領悟，把自己真正融入產品的世界中。

9. 用戶需求分析方法

客戶的需求是我們銷售行為的關鍵，但是客戶不會每次都會毫無保留的告訴你，所以我們要通過行業分析，客戶需求分析，了解客戶需求，解決問題。


一、分析競爭對手

想要了解客戶需求，就要先了解市場發展及我們的競爭對手。中國自古就有一句古話：知己知彼百戰百勝，銷售更應牢記這句話，因為只有你足夠了解你的競爭對手，才能做出應對。了解競爭對手，不僅要了解競爭對手的價格、特徵，還要了解有哪些長處、不足、銷量及銷售形式等，我們只有足夠透徹的了解競爭對手，才能在市場掌握主動權，同時也能從另一方面了解到市場需求。


二、客戶特點及習慣

一方面要了解客戶的興趣愛好，消費習慣等，另一方面要從銷售本身出發，了解客戶的內心，一般客戶都比較重視產品質量和售後服務，我們只需要把握好這兩點往往銷售會比較容易成功。

三、客戶的真實需求

要想了解客戶的真實需求需要尋找客戶需求、仔細發現、等待客戶需求呈現、確認客戶需求、最後成交。了解客戶需求是成交的必要條件。


四、滿足客戶

要學會維護客戶自尊，溝通過程中多用：有什麼我可以幫您的嗎？您的事我一直放在心上，會盡快給您處理的；您好有眼光等等。可以讓對方感覺到受到了尊重和重視，同時客戶也會感覺有良好的消費體驗。

細心聆聽客戶心聲，溝通過程中多用：您的意思是......對嗎？原來是這樣；我知道您的感受或心情等。要認真聽客戶講的話，體會對方感受，並及時給予回應，說出自己的想法。