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