在產品告別初創階段之後，基於業務方、PD 收集的使用者痛點反饋，思考體驗優化方案、推進迭代優化就成為了使用者體驗設計師的日常工作。而對於同時有多類目標使用者共存的平臺型產品來說，使用者痛點具備 多、零碎、（不同使用者之間）彼此衝突 等特徵，如果保持「使用者吐槽一句 – PD 找設計師改一次方案」的專案迭代節奏的話，久而久之就會產生一系列問題：陷入細節失察全域性、前後矛盾反覆修改、被動改進缺少沉澱、資訊結構越來越複雜脆弱……
之前的文章也提到過幾次遇到這樣的情況和自己的改進想法，但沒有系統地梳理總結過整體分析推導思路。今天這篇文章想結合一下個人實踐經歷（由於是公司專案，只抽象了框架方法論，不涉及具體內容細節），總結一下遇到這樣的情況時，如何將「多而散」的使用者痛點歸納聚焦，推匯出統一的體驗設計優化方案的方法思路。
和日常快速優化迭代相比，這樣做有什麼好處呢？
產品設計新人最容易犯的錯誤之一，就是過於注重「摳細節」，而無法從更全域性、整體的角度來統一看待和解決問題。針對單一的使用者痛點吐槽逐一提出的優化方案，割裂開來看似乎都很合理，但卻掩蓋了痛點之間可能存在的矛盾衝突等關係，也容易讓設計師陷入細節而不去考慮對產品整體、長遠發展的影響。最終無數個看似合理的單一方案加起來，卻讓產品變得割裂、前後矛盾、結構脆弱難以擴充套件。
因為逐一思考解決方案容易忽略使用者痛點之間的關聯和矛盾，所以也容易出現方案之間前後矛盾、迭代上線後需要反覆修改回滾一類的現象，給設計和開發都增加了工作量。而如果將使用者痛點聚焦起來分析，一次打包成統一解決方案交付，這樣的狀況就能相對減少。
對於設計師自身來說，分析推導的過程也是沉澱個人價值和影響力的機會，能幫助提升自己的系統分析洞察能力，從更整體的角度來解決問題的能力，而不是做一個尷尬的被動執行者。
具體的分析推導流程
1）定位使用者
B 端產品目標使用者群通常很確定，直接諮詢 PD、業務方獲取資訊即可。在溝通確認資訊的過程中，需要明確以下幾個要點：
-
目標使用者群可劃分哪幾類？
-
這幾類使用者中，哪些是核心主體使用者？哪些能給平臺帶來較大業務價值？
-
使用者在平臺上的職責是什麼？落腳頁面是哪些？有什麼潛在訴求？
2）歸納痛點
整理各類使用者的調研反饋資訊，描述故事歸納痛點，進一步提煉出背後的使用者訴求，比較建議使用表格的形式來整理，具體框架可參考如下：
-
相關環節 – 問題涉及到的具體相關流程、頁面
-
故事板 – 站在使用者角度描述典型使用場景、吐槽反饋
-
痛點總結 – 從使用者故事中總結出具體痛點
-
訴求提煉 – 推導痛點背後的使用者想要的東西
3）提煉目標
歸類使用者訴求，提煉出關鍵使用者目標、明確目標之間聯絡，結合業務價值提煉體驗目標洞見。使用者目標可以按照使用者接觸、認知、產生忠誠、自發推廣產品的週期來提煉關聯，的以下是我對一個問題流轉平臺產品的使用者目標和體驗目標抽象：
4）明確方向
定義清楚產品特徵、現狀問題、設計目標等後，分模組、場景梳理可改進點。
提煉具體的設計方向和改進辦法，落實到較具體的方案思路上。
排好優先順序（結合業務目標考慮），明確好排期時間節點，及時和專案組保持資訊同步。
5）整合設計
分模組、場景整合設計方案，平衡多方使用者痛點訴求，用一套設計稿同時解決多個問題。此處省略具體互動稿若干……
6）實施跟進
把控產品迭代節奏，跟進方案開發落地。
關注上線資料反饋，驗證方案實際效果。
整理反饋，準備下一次迭代優化。
但真正的實踐推進過程並不是那麼順利，也踩到了幾個坑……
1）流於形式
我在實踐嘗試過程中有些太注重前期的梳理、分析和推導過程表達，還寫了一份非常完整詳細的產品設計分析報告。但其實很多使用者分析的環節內容更多是基於 PD 收集和自己使用的反饋在 YY，而沒有科學的使用者訪談調研流程；在出具體方案的過程中思考也不夠周全，評審具體解決方案時被挑戰到不少細節，這些都是今後需要避免的地方。
2）節奏不合理
因為自己主動推進專案的意識還不夠強，疏於設計方案交付後跟進開發的節奏把控，設計交付到正式開發動工間隔了整整一個月之久，到寫文章的時候相關功能也沒有全面開發上線完畢。一個明顯的不良後果就是等開發時我已經遺忘了部分設計細節這麼做的原因，又花了多餘的時間精力來重新溝通確認，今後要更注意和 PD 一起把控好推進節奏，而不是完成設計方案交付掉就事不關己了。