我們都知道用戶洞察是制定產(chǎn)品策略的基石之一。用戶洞察是十分有價值的，因為我們可以根據(jù)這些來制定產(chǎn)品階段性目標(biāo)，并且創(chuàng)造出最大的價值。

然而，你需要很小心地使用這些數(shù)據(jù)，否則你將會做出錯誤的決策或者最終根本沒有發(fā)揮這些數(shù)據(jù)的價值。如果沒有很好地使用這些數(shù)據(jù)，難道不是錯失了一個良好的機會嗎？

“所以，你想要分析這些用戶洞察數(shù)據(jù)嗎？首先，你需要整理它們……”

嚴(yán)肅地說，你需要用某種方法使用這些數(shù)據(jù)，并從海量的數(shù)據(jù)中理解用戶的訴求和洞察。

我的團隊已經(jīng)意識到這一步的關(guān)鍵在于如何整理這些數(shù)據(jù)，為了做出數(shù)據(jù)驅(qū)動的產(chǎn)品策略，你需要瀏覽數(shù)據(jù)，然后快速地確定需要聚焦在哪一部分數(shù)據(jù)上。

一、使用什么方式來整理數(shù)據(jù)？?Can any structure work？

我的團隊曾嘗試使用一種備受推薦的結(jié)構(gòu)來整理數(shù)據(jù)，這一年內(nèi)，我們在根本沒有考慮洞察的情況下就做出了產(chǎn)品策略。

這種備受推薦的結(jié)構(gòu)如下：

我們把產(chǎn)品分成幾個部分（比如注冊/首頁），在每個部分下面把從不同渠道收集到的數(shù)據(jù)以主要功能和其下的子功能的形式標(biāo)明。

遵循這一結(jié)構(gòu)，哪一洞察出現(xiàn)的數(shù)量越多，我們就可以關(guān)注這一部分的功能需求并且制定產(chǎn)品階段性目標(biāo)（給每個洞察打分會比單純的計算哪一洞察出現(xiàn)的數(shù)量多更加復(fù)雜和嚴(yán)謹）。

但是這一方法并不奏效，因為一些原因這個方法是誤導(dǎo)的且令人迷惑的。

二、問題所在?The problem

1. 更快的馬還是一輛汽車

這是一個來自 Henry Ford 的著名的故事，F(xiàn)ord 說，如果我問人們他們想要什么，人們會說他們想要更快的馬。

這意味著用戶不會總是告訴你最佳的解決方法，在這個情境下，給人們一輛車是更加理想的選擇，但是你會理解用戶的需求并且想出一個更好的解決方案。

“更快的馬”是我們使用備受推薦的結(jié)構(gòu)來整理數(shù)據(jù)時遇到的一個問題，讓我來舉一個例子。

這是 Jimmy，他正在使用一款視頻會議軟件，他想要我們加入一個音頻故障排除功能。

這的確是一個解決方案，但是問題在于 Jimmy 在音頻連接上有太多問題了，在我們這邊解決這個問題，而不是讓他自己手動解決這個問題是一個更好的解決方式。不幸的是，Jimmy 并沒有提出這個更好的解決方式，但是我們不會責(zé)備他，因為他并不是專家。

所以想象一下，你一直使用這種備受推薦的結(jié)構(gòu)來整理數(shù)據(jù)，把每一條需求都放進去，不斷得獲得越來越多的投票，之后你就決定實現(xiàn)這個需求，可是這個方案并不理想，這根本就不是最佳的解決方案。

2. 隨處可見的碎片化信息

這是 Katie，她在使用視頻會議軟件，她說軟件加載需要很多時間。

現(xiàn)在我們來看我們的整理結(jié)構(gòu)，我們有許多功能需求可以解決這個問題（比如增強加載指示，修復(fù)前端加載問題等）。所以你會把這些需求放在哪里呢？把他們放在一個需求下面，還是兩個？

不管用哪種方式，你都沒有從宏觀角度來看問題，我們無法意識到一個問題的重要性，是因為我們把這些碎片放在不同的部分下面且沒有統(tǒng)一考慮。

這并不能幫助我們確立問題的優(yōu)先級。

三、如何去解決？?How tosolvethis?

讓我來給你們展示一種我們整理定性數(shù)據(jù)的技巧。在這個新技巧的幫助下，我們可以更快地從產(chǎn)品和調(diào)研的角度來關(guān)注那些重要的部分。

同時我也附上了團隊用戶洞察數(shù)據(jù)整理工作坊的流程，所以你們可以創(chuàng)建自己的整理結(jié)構(gòu)。這個技巧可能適合我們的產(chǎn)品團隊，但是可能并不適合你們的，所以讓我們來創(chuàng)造自己團隊的整理結(jié)構(gòu)吧！

四、我們尋找理想方法的過程?Our way to the ideal structure

首先，讓我先來展示一下你已經(jīng)非常熟悉的雙鉆模型。

根據(jù)這個流程，首先需要找到你所探究的一般問題，接著，作為一個用戶體驗研究者，你將深挖問題并且發(fā)現(xiàn)更多的問題，然后，你需要決定哪個問題是接下來要著手去解決的。

到這里就結(jié)束了嗎？還沒有！我們?nèi)匀恍枰ふ覇栴}的解決方案……所以我們會如何做呢？我們開始發(fā)散創(chuàng)意去尋找最佳的解決方案。我們最終會擁有許許多多的提案，然后我們從這些提案中找出最優(yōu)秀的那一個（擁有最高的價值和最少的實現(xiàn)成本）。

這是一個高效且合適的產(chǎn)品設(shè)計流程。

從 Jimmy 的想法來考慮，他給出了一個具體的解決方案。現(xiàn)在，我們與其去收集功能需求，然后根據(jù)哪個需求獲得更多的票數(shù)來決定去實現(xiàn)哪個功能，不如嘗試另外一個方法，同樣也順應(yīng)了雙鉆模型。

根據(jù)這個流程，你要從解決方案反向追溯到需要解決的具體問題。在這個例子中，具體的問題就是用戶有音頻連接問題。

知道了問題所在，所以接下來怎么辦？現(xiàn)在就到了創(chuàng)意發(fā)散環(huán)節(jié)，我們需要找到這個問題的最佳解決方案。也許你們可以給用戶一個音頻故障排除指南，或者你們可以自己修復(fù)連接的問題。

我們這樣做得到了什么？我們得到了一個根本問題更多更好的解決方案，我們當(dāng)然可以確認這些解決方案都是圍繞著這個根本問題展開的。

現(xiàn)在最激動人心的部分來了，隨著產(chǎn)品的成長，你將會獲得海量的用戶反饋，這些反饋映射出海量的問題。你需要耐心地去選擇哪些需要深挖，哪些不需要。理想情況下，你需要去解決那個最緊迫的問題，實現(xiàn)最大的用戶需求來創(chuàng)造最大的價值。好消息是，你現(xiàn)在可以著手去做了！

我們現(xiàn)在，有 100 個問題可以選擇去深挖。根據(jù)用戶反饋的數(shù)量和比重以及其他因素（業(yè)務(wù)目標(biāo)，用戶畫像等），你可以選擇去深挖哪一個問題。然后你會進行創(chuàng)意發(fā)散環(huán)節(jié)，獲得 100 個解決方案。

接下來，進行優(yōu)先級劃分，有許多方法去尋找最佳和最終的解決方案。這篇文章并沒有涵蓋這個部分，如果你有興趣，可以閱讀這篇文章：https://plan.io/blog/feature-prioritization/

太好了！我們有一個解決方案來實施了，它非常重要，非常棒，是我們所希望的一切，我們真的很喜歡它，非常感謝！

五、最終的數(shù)據(jù)整理結(jié)構(gòu)?The final structure

現(xiàn)在我們來可視化一下我們最終的方法是如何去整理數(shù)據(jù)的。

正如你所見，用戶洞察被分配到不同的功能下，功能可以關(guān)聯(lián)到問題所在，問題可以整理到用戶場景或者用戶目標(biāo)下。我們引入用戶場景的層級是因為我們的產(chǎn)品非常龐大，我們所以希望對問題進行分組，以便在不同問題之間瀏覽切換。

如果我們是那個視頻會議產(chǎn)品的團隊成員，下圖就是我們用這種方法來整理Katie和Jimmy反饋意見的例子。

正如你所見，一個用戶洞察并不一定被分配到一個功能下，如果沒有功能這一層級，你可以優(yōu)先考慮問題，然后你就可以發(fā)散出更多的解決方案，所以這個方法是完全可用的。

我想強調(diào)的是，這是一個可以不斷添加的結(jié)構(gòu)。適用于今天的整理結(jié)構(gòu)不一定適用于明天。這導(dǎo)致整個結(jié)構(gòu)化主題更加困難。除此之外，適用于我們公司的結(jié)構(gòu)不一定適用于你的公司，這就是為什么我會把工作坊流程發(fā)布出來來引導(dǎo)我們每個人去尋找適用于自己產(chǎn)品的方法，所以一定會根據(jù)這個方法找到你們的整理結(jié)構(gòu)。

我們目前嘗試去讓我們的結(jié)構(gòu)更加扁平，但是如果你發(fā)現(xiàn)瀏覽不同問題時很困哪，這可能就是你需要拓展出更多其他層級的信號。這種情況下，你可以在更小的問題上面引入另一個更大的問題層級，或者在低層級的用戶場景之上加入更廣泛的用戶場景。這取決于你需要什么。

小建議：如果你在創(chuàng)建一個問題還是兩個問題上猶豫，或者是否需要把一個問題拆解成兩個問題，你可以選擇后者，因為你永遠可以把任何內(nèi)容組合起來，但是很難去分開他們。

六、這個新的整理結(jié)構(gòu)如何幫助你的日常工作？How does this new structure help our job?

1. 優(yōu)點1

從現(xiàn)在開始，這個結(jié)構(gòu)不僅只是對產(chǎn)品管理有用。同樣也適用于用戶體驗研究。體驗研究人員可以看到哪個問題是緊迫的并且可以開始深挖研究。另外，這種思考方式也會鼓勵每個人去思考每一個用戶需求背后的原因，而不是一味去增加產(chǎn)品功能。

2. 優(yōu)點2

產(chǎn)品設(shè)計與開發(fā)變得更加高效。不再需要去做那些毫無價值的、浪費時間且無法結(jié)局問題的工作。

3. 優(yōu)點3

這是一個適用于產(chǎn)品、用戶體驗研究之間合作的完美工具。用戶研究人員可以非常簡單地加入到流程圖的設(shè)計中，產(chǎn)品經(jīng)理也可以更好地去選擇創(chuàng)造更多價值的功能。

4. 優(yōu)點4

用戶體驗設(shè)計師和不能在洞察處理環(huán)節(jié)中緊密參與的其他同事（營銷、銷售等）可以更加簡單地瀏覽這個結(jié)構(gòu)，給予更宏觀的呈現(xiàn)與總結(jié)，并且可以讓緊迫的大問題只需要看一眼就可以快速定位。

七、使用軟件?Tools

現(xiàn)在有非常多的軟件可以幫助你整理這些內(nèi)容（Productboard、User Voice、Aha!、ProductPlan 等等）。

我非常建議謹慎思考哪個工具會更加滿足你的需求。一旦你使用了一款軟件，就得在那里收集數(shù)據(jù)，然后按照這種結(jié)構(gòu)整理；所以一旦開始使用就不要更換，把數(shù)據(jù)遷移到另一個平臺上需要巨大的時間和精力。

八、定量數(shù)據(jù)?Quantitative data

到現(xiàn)在為止，我們一直在談?wù)摱ㄐ詳?shù)據(jù)，但是，這個方法同樣也適用于定量數(shù)據(jù)！是不是很棒！

比如說，每當(dāng)你看到某個功能需求在公共功能需求頁面上有 88 票時，你只需要把這個洞察分配到相應(yīng)的功能需求下，然后給它賦予一個比基礎(chǔ)影響分數(shù)（當(dāng)在用戶訪談中，只有一個人提出了這個功能需求）更大的影響分數(shù)。

這個方法也適用于一些問卷和其他定量調(diào)研方法，你只需要變得稍微有創(chuàng)造力一點，但是這個方法是適用的！

非常感謝 Linda Czinner（Bitrise 的首席產(chǎn)品經(jīng)理），她與我一起參與了這個旅程。

本文翻譯已獲得作者的正式授權(quán)（授權(quán)截圖如下）

作者：Zsófia Kothencz

原文：https://uxdesign.cc/how-to-make-the-best-product-decisions-based-on-thousands-of-user-inputs-7fc0d7658a12

譯者：王英睿；審核：徐曼璐、李澤慧、張聿彤；編輯：孫淑雅

本文由@TCC翻譯情報局 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議