平台型產品如何從「分散用戶痛點」推導「統一優化方案」

 　　在產品告別初創階段之後，基於業務方、PD 收集的用戶痛點反饋，思考體驗優化方案、推進迭代優化就成為了用戶體驗設計師的日常工作。而對於同時有多類目標用戶共存的平台型產品來說，用戶痛點具備 多、零碎、(不同用戶之間)彼此沖突等特征，如果保持「用戶吐槽一句 – PD 找設計師改一次方案」的項目迭代節奏的話，久而久之就會產生一系列問題：陷入細節失察全局、前後矛盾反復修改、被動改進缺少沉澱、信息結構越來越復雜脆弱……

　　之前的文章也提到過幾次遇到這樣的情況和自己的改進想法，但沒有系統地梳理總結過整體分析推導思路。今天這篇文章想結合一下個人實踐經歷(由於是公司項目，只抽象了框架方法論，不涉及具體內容細節)，總結一下遇到這樣的情況時，如何將「多而散」的用戶痛點歸納聚焦，推導出統一的體驗設計優化方案的方法思路。

　　 和日常快速優化迭代相比，這樣做有什麼好處呢?

　　產品設計新人最容易犯的錯誤之一，就是過於注重「摳細節」，而無法從更全局、整體的角度來統一看待和解決問題。針對單一的用戶痛點吐槽逐一提出的優化方案，割裂開來看似乎都很合理，但卻掩蓋了痛點之間可能存在的矛盾沖突等關系，也容易讓設計師陷入細節而不去考慮對產品整體、長遠發展的影響。最終無數個看似合理的單一方案加起來，卻讓產品變得割裂、前後矛盾、結構脆弱難以擴展。

　　因為逐一思考解決方案容易忽略用戶痛點之間的關聯和矛盾，所以也容易出現方案之間前後矛盾、迭代上線後需要反復修改回滾一類的現象，給設計和開發都增加了工作量。而如果將用戶痛點聚焦起來分析，一次打包成統一解決方案交付，這樣的狀況就能相對減少(當然，不能完全避免)。

　　對於設計師自身來說，分析推導的過程也是沉澱個人價值和影響力的機會，能幫助提升自己的系統分析洞察能力，從更整體的角度來解決問題的能力，而不是做一個尴尬的被動執行者。

　　具體的分析推導流程

　　1）定位用戶

　　B 端產品目標用戶群通常很確定，直接咨詢 PD、業務方獲取信息即可。在溝通確認信息的過程中，需要明確以下幾個要點：

　　目標用戶群可劃分哪幾類?

　　這幾類用戶中，哪些是核心主體用戶?哪些能給平台帶來較大業務價值?

　　用戶在平台上的職責是什麼?落腳頁面是哪些?有什麼潛在訴求?

　　2）歸納痛點

　　整理各類用戶的調研反饋信息，描述故事歸納痛點，進一步提煉出背後的用戶訴求，比較建議使用表格的形式來整理，具體框架可參考如下：

　　相關環節 – 問題涉及到的具體相關流程、頁面

　　故事板 – 站在用戶角度描述典型使用場景、吐槽反饋

　　痛點總結 – 從用戶故事中總結出具體痛點

　　訴求提煉 – 推導痛點背後的用戶想要的東西

　　3）提煉目標

　　歸類用戶訴求，提煉出關鍵用戶目標、明確目標之間聯系，結合業務價值提煉體驗目標洞見。用戶目標可以按照用戶接觸、認知、產生忠誠、自發推廣產品的周期來提煉關聯，以下是我對一個平台產品的用戶目標和體驗目標抽象：

　　4）明確方向

　　定義清楚產品特征、現狀問題、設計目標等後，分模塊、場景梳理可改進點。

　　提煉具體的設計方向和改進辦法，落實到較具體的方案思路上。

　　排好優先級(結合業務目標考慮)，明確好排期時間節點，及時和項目組保持信息同步。

　　5）整合設計

　　分模塊、場景整合設計方案，平衡多方用戶痛點訴求，用一套設計稿同時解決多個問題。此處省略具體交互稿若干……

　　6）實施跟進

　　把控產品迭代節奏，跟進方案開發落地。

　　關注上線數據反饋，驗證方案實際效果。

　　整理反饋，准備下一次迭代優化。

　　但真正的實踐推進過程並不是那麼順利，也踩到了幾個坑……

　　1）流於形式

　　我在實踐嘗試過程中有些太注重前期的梳理、分析和推導過程表達，還寫了一份非常完整詳細的產品設計分析報告。但其實很多用戶分析的環節內容更多是基於 PD 收集和自己使用的反饋在 YY，而沒有科學的用戶訪談調研流程;在出具體方案的過程中思考也不夠周全，評審具體解決方案時被挑戰到不少細節，這些都是今後需要避免的地方。(下圖被刻意模糊過)

　　2）節奏不合理

　　因為自己主動推進項目的意識還不夠強，疏於設計方案交付後跟進開發的節奏把控，設計交付到正式開發動工間隔了整整一個月之久，到寫文章的時候相關功能也沒有全面開發上線完畢。一個明顯的不良後果就是等開發時我已經遺忘了部分設計細節這麼做的原因，又花了多余的時間精力來重新溝通確認，今後要更注意和 PD 一起把控好推進節奏，而不是完成設計方案交付掉就事不關己了。