我們都知道用戶洞察是制定產品策略的基石之一。用戶洞察是十分有價值的，因為我們可以根據這些來制定產品階段性目標，并且創造出最大的價值。

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

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

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

我的團隊已經意識到這一步的關鍵在于如何整理這些數據，為了做出數據驅動的產品策略，你需要瀏覽數據，然后快速地確定需要聚焦在哪一部分數據上。

一、使用什么方式來整理數據？?Can any structure work？

我的團隊曾嘗試使用一種備受推薦的結構來整理數據，這一年內，我們在根本沒有考慮洞察的情況下就做出了產品策略。

這種備受推薦的結構如下：

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

遵循這一結構，哪一洞察出現的數量越多，我們就可以關注這一部分的功能需求并且制定產品階段性目標（給每個洞察打分會比單純的計算哪一洞察出現的數量多更加復雜和嚴謹）。

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

二、問題所在?The problem

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

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

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

“更快的馬”是我們使用備受推薦的結構來整理數據時遇到的一個問題，讓我來舉一個例子。

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

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

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

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

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

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

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

這并不能幫助我們確立問題的優先級。

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

讓我來給你們展示一種我們整理定性數據的技巧。在這個新技巧的幫助下，我們可以更快地從產品和調研的角度來關注那些重要的部分。

同時我也附上了團隊用戶洞察數據整理工作坊的流程，所以你們可以創建自己的整理結構。這個技巧可能適合我們的產品團隊，但是可能并不適合你們的，所以讓我們來創造自己團隊的整理結構吧！

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

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

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

到這里就結束了嗎？還沒有！我們仍然需要去尋找問題的解決方案……所以我們會如何做呢？我們開始發散創意去尋找最佳的解決方案。我們最終會擁有許許多多的提案，然后我們從這些提案中找出最優秀的那一個（擁有最高的價值和最少的實現成本）。

這是一個高效且合適的產品設計流程。

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

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

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

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

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

我們現在，有 100 個問題可以選擇去深挖。根據用戶反饋的數量和比重以及其他因素（業務目標，用戶畫像等），你可以選擇去深挖哪一個問題。然后你會進行創意發散環節，獲得 100 個解決方案。

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

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

五、最終的數據整理結構?The final structure

現在我們來可視化一下我們最終的方法是如何去整理數據的。

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

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

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

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

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

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

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

1. 優點1

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

2. 優點2

產品設計與開發變得更加高效。不再需要去做那些毫無價值的、浪費時間且無法結局問題的工作。

3. 優點3

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

4. 優點4

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

七、使用軟件?Tools

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

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

八、定量數據?Quantitative data

到現在為止，我們一直在談論定性數據，但是，這個方法同樣也適用于定量數據！是不是很棒！

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

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

非常感謝 Linda Czinner（Bitrise 的首席產品經理），她與我一起參與了這個旅程。

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

作者：Zsófia Kothencz

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

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

本文由@TCC翻譯情報局 翻譯發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議