需求採集

實際的工做中，到底採用何種需求採集方法，每每取決於可用資源。好比人員數量和能力、時間、經費等等。

不過一般來說，這些用戶研究或者說需求採集過程，每每有以下幾步：

明確目標、選擇採集方法、指定採集計劃、執行採集、資料整理，最後，進入需求分析階段。

上一篇隨筆中有一個用戶研究方法的思惟導圖，將其簡化爲下圖的需求採集方法：

其中四個步驟分別對應下面的集中需求採集方法。

 

一、定性的說：用戶訪談

用戶訪談通常採用訪談者一對一或一對多的形式，圍繞幾個特定的話題，咱們問，用戶答，用戶說，咱們聽，這是一種典型的定性研究。

用戶訪談經常使用於新產品方向的預研工做中，或經過數據分析發現現象後，探索現象背後的緣由。

用戶訪談常見問題與對策

①、用戶「說」和用戶「作」常常不一致

其實大多狀況下，用戶不是故意欺騙咱們，多是：他們被問了本身也沒仔細想過的問題，又不想回答不知道，或者用戶在回答時候都是下意識的回答他們以爲咱們但願獲得的答案，

而不是本身的真實想法。（想深刻了解的話，能夠去看看社會心理學，裏面有詳細論述）

咱們須要儘量的讓用戶「說」的時候同時「作」，注意區分用戶說的事實與觀點，是否清晰明確，對「我以爲、我認爲」等詞語，帶着問號去聽。

②樣本少，以偏概全

好比有時候咱們的用戶層涉及的範圍比較廣（地域、年齡等），但大量的樣本成本又太大，性價比不高。

這時候就須要儘可能作到隨機，而後從中選取不隨機的例子，分析出可能形成差別的緣由，並在訪談記錄裏註明；

還可使用增量的方式，多進行一些樣本，而後統計其變化規律，和預約的結果誤差大小，若是沒有改變或誤差較小（可聯想下冪等性的屬性），便可中止訪談活動。

（關於樣本選取，這屬於機率與統計學範疇，想深刻了解的話，能夠自行查閱）

③用戶過於強勢，把咱們往溝裏帶

有時候會遇到一些個性比較鮮明或者表達慾望較強的用戶，要解決這個問題，須要牢記訪談的目的。

若是發現話題不對，就馬上扳回來，若屢次扳不回來，就須要儘快結束，用戶不少，不要在不合適的對象上花費太多時間。

④咱們過於強勢，把用戶往溝裏帶

這個問題的對策，一樣，牢記訪談目的，言多必失。

推薦一本書：《軟件觀念革命：交互設計精髓》，做者是軟件交互之父Alan Cooper，感興趣的話能夠自行查閱資料。

下面摘錄一些關於用戶訪談的要點：

△避免一組固定的問題：應準備好一個問題清單，但清單只是引導

△首先關注目標，任務其次：比用戶行爲更重要的是行爲背後的緣由

△避免讓用戶成爲設計師：聽用戶說，但不要照着作

 做者蘇傑提出了一個種子用戶的概念，具體可參考其博客連接：http://iamsujie.com/1000/1024/

△避免討論技術：不要與用戶糾纏產品的實現方式

△避免誘導性問題：通常來講遇到這類問題，用戶給出的答案毫無心義

 

二、定量的說：調查問卷

一樣是聽用戶說，常見的定量研究方法是————調查問卷。

調查問卷和用戶訪談的區別：

用戶訪談：一般是開放式的問題，適用於咱們還比較疑惑時尋找產品方向，適合較少的訪談對象進行深刻交流；

調查問卷：封閉式問題較多，適合大用戶量數據收集，但不夠深刻，通常採起前者來爲後者服務；

調查問卷注意事項：

不管線上線下，最好不要超過5分鐘，開篇通常是簡單不需思考的問題，須要思考和比較敏感的問題放中間，關於訪談者我的信息的問題放最後，避免訪談者顧忌而影響結果。

調查問卷常見問題與對策

①樣本誤差，即樣本與用戶羣體出現誤差

用戶訪談因爲樣本量的限制，得出的答案比較模糊，而調查問卷的客觀性，多分問卷的獨立性，能夠有效避免該問題。

在採用調查問卷時，應儘量覆蓋目標羣體中各種型用戶，要保證各種型用戶樣本比例接近全體比例，將一些潛在篩選條件標明。

②樣本過少

樣本量過少時，採用百分比來分析是沒有意義的；拋開嚴謹的統計學機率不談，最少要有大約100份及以上的問卷答案。

③問卷內容的細節問題

首先，問題表述應毫無引導性；其次，答案的順序也影響被調查者的選擇優先級，應多備幾種形式的問卷，每種問卷答案的排列順序都不一樣；

還有個通用辦法就是先進行小範圍的試答，根據反饋結果修改後，再大面積投放（這與咱們產品發佈上線的灰度發佈很相似）

 

三、定性的作：可用性測試

可用性測試：經過讓實際用戶使用產品或原型的方法來發現界面設計中的可用性問題

可用性測試主要的過程以下：

①招募用戶

主要原則是這些用戶要能儘量的表明未來的真實用戶；好比產品主要用戶特質是新手，那麼就應該選擇對產品不熟悉的用戶；

②準備測試任務

測試前測試的組織者應準備好一系列要求用戶完成的任務，任務應當是一些實際使用中的典型任務；

③測試過程（重點）

用戶經過使用產品來完成所要求的任務，同時組織者在一旁觀察用戶操做全過程，並把發現的問題記錄下來；

④測試結束

組織者能夠詢問用戶對產品總體的主觀見解或感受，以及用戶在使用中的一些想法，以及爲何作出這些操做；

⑤研究分析

可用性測試結束後，須要根據記錄進行分析併產出一份可用性問題列表，對問題嚴重度進行分級，根據項目進度決定優先處理；

可用性測試常見問題與對策

①若是可用性測試作的太晚，發現問題也於事無補

其實在項目的各個階段均可以作可用性測試。好比上線運行階段，能夠用真實的產品給用戶作測試；產品只有頁面demo時，拿demo給用戶作測試；在產品只有直面原型時，拿手繪產品

加紙筆給用戶作測試；甚至尚無任何成型產品時，拿競爭對手的產品給用戶作測試，目的是爲了不咱們犯一樣的錯。

②以爲可用性測試很專業，乾脆不作

可用性測試，聽起來很專業，但收益沒法量化，且常常由於時間緊張和投入有限等緣由被略過；

但能夠簡化步驟，根據產品類型適當進行測試，效果也比不作好不少。

③測試產品，而不是測試用戶

邀請用戶來測試使用產品前，應明確告訴用戶，測試的目的是發現軟件產品中的問題，而不是測試用戶是否有能力使用產品（能夠對用戶說：試試咱們的產品，提點意見）；

④測試過程當中，組織者該作和不應作的

開始時能夠告訴用戶大概持續的時間、要作什麼，讓用戶心中有數，輕鬆愉快完成任務；測試中要求用戶在使用過程當中提出本身的一些想法以及作的緣由等；

過程當中不能有任何引導和暗示，而只是觀察和記錄；結束後和用戶作一些互動，贈送一些禮品，讓用戶以爲時間沒有白費；儘快總結結果，併發給用戶等。。。

 

四、定量的作：數據分析

數據分析是一種定量的研究方法，不管是考察用戶目標全體或是採樣，都徹底可控且最難被駁倒。

2013年開始火爆的大數據概念，全面提出了「全樣本」分析方法。

PS：一般來說，數據分析只能發現一些現象和問題，並不能瞭解緣由。

數據分析常見問題與對策

①過於學術，沉迷於「科學研究」

數據分析，科學研究一般只注重「性價比」的性，只要結果好，方向新，每每不計投入，但實際生產環境中，就須要考慮到性價比，特別是小步快跑的創業團隊，不可能在每次分析

前都去驗證樣本羣體是否符合某種統計分佈，也不須要「人工神經網絡」等高大上的手段，甚至「A＞B」的結論時也不用作「顯著性校驗」，一切只須要一種感受，一種對數字的敏感，

對商業的敏感。

②數據不會主動騙人，但常常被有意無心誤讀

無心誤讀數據，舉個例子，常常看到各地平均工資，而後各路人馬紛紛感嘆被平均，拉了後腿，其中以北上廣深最甚，其中種種，你們都明白的。

這個問題的對策，多學學統計學的知識，就明白了。推薦《黑天鵝》和《統計數字會撒謊》這兩本統計類圖書，內容生動，比較適合工做的人羣閱讀。

有意的誤讀，這個就比較有趣了，在提取數據分析前，可能咱們心中已經有了答案，無非是想經過數據分析驗證它，對此，能力越強的人越容易作到這點；對此的對策就是對數據

保持中立的態度，儘可能「不要爲了迎合一個觀點去找數據」，好比爲了證實老闆的判斷，或爲了保持本身的拍腦殼結果等。

③平時不燒香，臨時抱佛腳

這是個實際的問題，不少人都是在作決策時纔想起數據分析，但發現手頭沒有可分析的數據。爲了不此類問題，應在產品設計時就加入數據分析的需求，好比記錄按鈕的點擊次數，

統計用戶的登陸在線頻率，這是一種典型的非功能需求，但對產品長期規劃發展很是必要。

數據分析如何轉化爲商業價值？

總體思路是：對產品足夠熟悉的基礎上，先作方向性的假設，再提取相應的數據並分析，獲得一些現象，最好是以前沒發現的現象，而後嘗試解釋，接下來作用戶調研

修正解釋，最終指導產品發展方向和市場運營等。

 

五、需求採集，人人有責

關於需求採集，蘇傑本人提出過這麼一個概念：直接採集＞間接採集。可參考其博客，連接：http://iamsujie.com/1000/1025/

固然，還有一個關於需求採集的場景問題，不一樣場景採用不一樣的適合的方法，也很重要。一樣可參考其博客，連接：http://iamsujie.com/1000/1020/

要作需求採集，首先必須明確一點：產品需求工做不僅是需求分析人員的事，而是涉及到產品的每一個干係人的義務，至少要參與「採集」的過程。

需求採集，有一點很重要，那就是：儘量的多采集！

下面列舉幾個經常使用的需求採集例子：

①現場調查

簡單說，就是去客戶現場，看看客戶在說什麼，作什麼，不過受衆面較小，持續時間較長，要注意不要被用戶「帶到溝裏去」；

②AB測試

基於大用戶量比較合適，通常的作法是基於某個不肯定的功能點，發佈一個beta版本，隨機選擇一部分用戶使用，一段時間後根據用戶的使用結果來決定，正式發佈怎麼作。

不過，這是土豪大公司玩的遊戲，通常中小型公司，受制於資金等因素，玩不起啊。。。

③日記研究

互聯網新興我的應用比較適合，產品發佈後，大多產品經理都會嘗試寫一些使用體會，用戶報告，但這每每是同行的結論，可參考。

④卡片分類法

不少時候，用戶想法和產品人員的想法老是不一樣的，可讓用戶提出本身心中的關於產品或某個模塊是什麼樣的，而後產品設計人員作參考，不然很容易致使用戶的理解和使用

困難，這樣作的目的是使產品更符合用戶的心理模型。（關於這點，能夠延伸閱讀學習「設計模型」和「用戶模型」的概念）

⑤本身提需求

每一個靠譜的產品都有一批忠實用戶，產品人員本身多用相關產品，多看相關的報告內容，多和這批用戶交流，會發現用戶能夠給你帶來不少驚喜。

產品只有在使用過程當中，才能辨別好壞，特別是本身的產品。本身多提需求，才能從側面使得產品更完美。

 

最後，說說需求採集，其實和任何領域的知識同樣，建議首先創建知識框架，而後「需求驅動學習」，即：須要什麼，學習什麼。。。