產品設計需求梳理溝通法，有效推動設計決策的關鍵方法與實例
前言 — 設計方案改來改去好頭痛 😵💫
身為一名產品設計師，時常需要跟 PM 協作，並擔當著轉化具體設計的關鍵角色，因應不同公司不同的戰隊形式，多數時候 PM 相對跑得更前面，釐清多數核心需求與掌握 Stakeholders，但當下列情況存在時：
- PM 尚與 Stakeholders 在建立默契
- 對團隊來說，還處於相對陌生的場域或議題
尚未習得需求梳理技能的產品設計師，會碰到下列問題：
- 不知道設計目標為何，該如何開始或放錯重點
- 無法說服 Stakeholders 採用設計方案，在改動過程忽略使用者體驗
- 丟失設計方案的掌握度，因而失去了成就感
這時候可以先反思，身為一名產品設計師，還有哪些是自己的角色能切入的，如何做能改善這個問題減緩在未來發生？
接下來會分為三大部分分享
- 從需求對話中釐清關鍵問題與脈絡
- 透過梳理模板傳達設計決策與方案，強化設計面向的說服力
- 即便最終方案說服失敗，平衡心態，做到有「戰」有「合」
本文架構
- 前言：設計方案改來改去好頭痛
- 從需求對話中釐清關鍵問題與脈絡
- 從需求對話中釐清關鍵問題與脈絡
- 適當放下設計堅持，平衡心態聚焦專案推進
- 結語從需求對話中釐清關鍵問題與脈絡
如前言所述，產品設計師也會有在最前端與 PM 一同參與、深入了解需求或議題的時候，甚至在看過 MRD 或 PRD 後，也會因為需要從中轉化出「體驗角度的目標」而有著下列思考與反饋 。
舉個例子，在對上營運或客戶端的需求時，可能會碰到以下情境：
1. 思考整段對話的關鍵切點
先思考這段話背後的可分支點？哪些是「問題」？哪些是「期待」？哪些是「關鍵」？
- 想要獲取到 Roadmap 嗎？為什麼？
- 還是要新增一個後台可控卡片的模組？為什麼？
- 還是想要可控卡片模組的主控人要是營運端？為什麼？
…
2. 不馬上聚焦明確做法，而是持續問「為什麼」
不從分支點討論解法，而是持續詢問背後可能的脈絡：
通常更多線索會逐漸水落石出：
- 原來提及 Roadmap，是希望知道後續專案相關的發展安排
- 原來目前因為營運過程新增或移除卡片的方式不夠即時，在這樣的情況下時常難以向客戶說明
- 原來營運不在意實際可控的是誰
…
3. 定調要帶回團隊的核心目標與脈絡收整
依據上述，產品目標釐清出爐：
通常除了核心目標，也會有次要目標，也就是「如果能被解決很好，沒有也無妨」，因應上述情境，就好比在後續的對焦都帶出下一步的安排，而不是馬上長出 Roadmap。
而在溝通過程中的脈絡，也應該被收整帶回團隊，產品團隊通常聚焦於主要目標，能夠從多個維度思考出不少解決方案，同時因為未能參與需求溝通的成員一定也有許多疑問，多數時候這是 PM 職能中關於 MRD 及 PRD 要能回應的，關於需求訪談也有許多課程或資料，在此不贅述，而是聚焦在產品設計師角色如何釐清梳理出關乎設計體驗面的關鍵。
設計梳理規劃方案與說服溝通
不論手邊的資訊是來自於 PM 還是營運、收整的顆粒度又如何，身為一名產品設計師，我會盡可能要求自己在做設計前，盡可能套用「為什麼」到所有資訊裡尋求脈絡。
我認為值得分享給大家的幾個實戰 Key Points，包含：
- 在帶到設計方案前幫助與會者先聚焦議題
以下是我過去在 91APP 所制定的，歷經與當時的 Product design Lead Sophie、Product Director Ivan 、體驗團隊成員們的討論，而後加入目前在 Gamania 所碰到的情境，綜合出的梳理模板，當越能撰寫出對應的回應，在方案的理解甚至轉化上，通常能夠越精準，在溝通時碰到的設計挑戰也會相對少。
- 溝通時先專注聚焦一項解決方案
即便規劃出許多設計解法、不少設計角度的思考或競品分析，都應該收整於邊緣，先擇一方案來溝通，避免討論過度延伸而難以聚焦，當討論時指向其他思量過的方案，也能即時帶出，並說明為何不採用該方案。
- 避免帶入色彩及細節，以防討論失焦
若議題與解法還很抽象，通常停留在架構設計討論，不要急著進入設計細節，而是採用手稿、Mindmap 又或是轉化為黑白的設計稿，聚焦設計，因爲通常看到解法或色彩的 Stakeholders 容易興奮至極，冒出許多過於具體的反饋，影響了討論主軸。
其餘具體在討論時的與會應對，我自己很喜歡 Lucy 所撰寫的這篇文章，精準的帶出什麼樣的設計回應能夠更有效的傳遞設計決策。
適當放下設計堅持，平衡心態聚焦專案推進
最後這一 Part ，是我在一路工作上的觀察及自身經驗，所得出的關鍵環節，當設計方案溝通失敗，或不如自己預期時，我認為應該在過程中回顧反思：
- 需求方的說服失敗是否有受「感受」因素所影響？
有時候需求方其實期望「加入參與決策與討論的過程」，當沒有參與至足夠的深度，有可能會有防禦心理產生而不自知，在這時候可以考慮未來多在過程中私下拉對方討論，先解「感受」題。
- 反思自己是否落入「沈沒成本偏誤」(Sunk Cost bias)
保持開放心態接收不同 Stakeholders 的想法至關重要，接收不代表接受，身為「人」，當耗費越多時間在該專案的設計中，也難免會越難接受改動，適時抽離能夠幫助抽離偏誤情況。
- 有「戰」有「合」
別忘了堅持自己的設計決策，但也別忘了適當放下自己的設計決策，若立場是於跨公司的合作，可能還能夠破局，但如果身在一個公司所有的討論與溝通應該都要能幫助專案持續推進，分享我自身評估「合」的判斷點：
當 Stakeholders 極度堅持，且提出的反饋也能解決該問題，並不會造成使用者體驗的破損！
(是否會造成開發量能延長、時程延長則是 PM 為主的評估範圍)
結語
到目前為止，我認為以上在工作經驗中得出的方法或心法，希望幫助大家也能順利推進自己的設計方案，一起共享設計方案被落實推進那一刻的成就感！
最後希望這篇文章有成功幫助到大家，拍拍手與 Follow 我的 Medium 佛心隨性，我會不定期分享許多實戰型經驗！ :)
