設計師必學的利害關係人交涉術！7 種常見問題實用句庫
學設計更要學說話，如何管理利害關係人、適當地應對各種意見反饋、掌握會議的走向，對產品設計師來說是很重要的一件事。我時常會覺得「話說得好，設計稿改得少」，設計稿是溝通的一部份，而好的團隊互動、應答可以確保自己有效傳遞設計決策。良好的溝通技巧也可以確保團隊不貿然做決定，因為部分次要因素而犧牲使用者體驗。
以下是根據自身的開會經驗，總結出的常見情境、經常收到的團隊成員提問，以及我的應對方式。
在分享完設計方案後，與會者突如其來地提出其他解法，但沒有明確的理由。
- 「你提出的這個解法是想要解決什麼問題呢？」「可以多分享一些背景脈絡嗎？」引導對方回到「問題」本身，可以避免與會者執著於解法本身，但忽略了我們想要解決的問題。
- 有時候與會者提出其他解法，其實是覺得現有方案的某個部分可以更好，但部分人的發言習慣是「提出另一個解法」來傳達自身的想法。
- 有時候對方提出這個問題，只是想要確認設計師有沒有想過更多其他方案，與會者不一定會參與到先前的所有討論，所以自然會想要了解更多。因此我都會留著先前嘗試過的各種版本當作備案，簡單分享我們探索過的方向，以及這些方向被淘汰的原因。
與會者提出有建設性的點子，但是因為實行成本高、複雜度高等原因，超出第一階段的範疇。
- 「這個想法很不錯，我們會把他納入下一階段的討論」予以肯定可以提供發言者正面反饋，讓他日後更願意提出想法。（如何維持團隊的參與感也是一個課題！）實際記錄下來，以行動表示『我們有聽進去』，可以避免對方覺得被敷衍。
- 相比於直接回答「這個太複雜了，這階段做不了」我相信前者更能照顧到發言人的感受，也提供團隊比較正面的討論態度。
與會者提出了一個你之前已經想過，但因為一些問題而最後沒有採用的解法。
- 「是的，你的建議點出了重要的 x，不過因為 y 可能造成 z 問題，我們需要有些權衡。」相比於果斷的否決，可以先正面肯定對方想法中與你有共鳴的部分，但再隨之點出自己設計過程中發現的問題。
到設計階段的尾聲，產品經理說某個功能 Phase 2 再排進開發。
- 「什麼時候會開發 Phase 2？我們排進 Roadmap 了嗎？」對大公司來說，要做的專案太多，Phase 2 常常遙遙無期。了解更明確的時程，可以確保「真的有 Phase 2」，以及實際計算 Phase 1 到 Phase 2 的時間差，以便計算對產品體驗的實際影響
- 「如果缺少這個功能，會限制專案的成效，因此不足以達到專案目標」因為產品經理多半是定義專案目標的人，回歸到專案目標亦即回歸到產品經理的需求，如此可以更審慎地評估是否該調整專案範疇。
在評估可行性跟開發時程時，工程師說某部分做不到。
- 進一步了解：「是開發技術上有限制？還是在現有時程限制下做不到？」在還沒明確定義「做不到」之前就妥協會有些可惜，若是技術上有限制，可以盡量釐清技術細節，在我過去的經驗中，有時會發現彼此在細節上有些誤會，在討論過後會發現沒有想像中的複雜。如果是受時程限制，則可以和產品經理討論是否有調整空間。
- 預先準備其他產品作為範本：「XX 產品也有類似的功能／效果，可以嘗試研究一下他們是怎麼實現的」做為具體例子證明特定的設計細節可行，而不是設計師的憑空想像。
- 在會議之前，事先找幾個開源專案、套件作為範例輔助溝通，例如產品功能要提供畫布供使用者繪製流程圖，因為這是一個常見的介面互動形式，也不需要工程師從頭做起，這時我就會先找好幾個套件來更精準表達預期的效果，但最後使用的套件還是依照工程師的選擇為主。
當需求方臨時提出很緊急、時程短的任務。
- 「截止日訂在這天有什麼特別的原因嗎？如果往後延會有什麼問題嗎？」釐清細節可以幫助權衡，具體比較延期的影響及低劣產品品質的損害孰輕孰重。
- 有時候需求方不了解產品團隊有既定的開發流程，這時我就會介紹（科普）產品的開發時程常態，並且以 Sprint 為基礎跟對方討論並調整時程。
- 公開透明地讓對方知道自己手頭上有哪些進行中的專案，讓對方了解其他專案的重要性。
- 如果緊急任務確實很重要，那我就會列下進行中的各項任務及緊急需求給主管，說明：「我們需要優先執行緊急任務，因為 OOO 原因，所以我會暫停進行 XX 專案。」詢問主管優先級排序是否與他預期相符。
準備開發只會上線一段時間的產品實驗、改動時，工程師或其他利害關係人詢問：「這個功能幾個月後會下架，為什麼還是要做？」
- 作為產品團隊的一員，我們的視角會和使用者不同，所以這時我會從使用者的角度出發，讓團隊以他們的觀點思考：「相比於思考這個功能會上線多久，我們應該要關注這數個月內多少使用者會受影響／接觸這個功能，如果每天會有數以萬計的使用者因為這個改動而受益，那即便這個功能只上線三個月，也會對上萬個使用者帶來好處。」
- 對產品團隊來說，即便產品實驗可能不會成為永久的版本更新，我們也可以在有限的時間內取得一些洞察，並且對使用者有更深的了解。對產品團隊有價值的不只是營收以及達成各項商業指標，使用者相關的資料也是重要的資產！
團隊合作的過程中，會碰到的問題和情境百百種，上述的情境只是其中一小部分，寫下來覺得更好地歸納了過去的經驗哈！希望未來隨著經驗的累積，能夠再沈澱更多應對進退的方式 ♪( ´θ｀)ノ。
雖說「話說得好，設計稿改得少」，不過！「溝通技巧」不是推工作的工具，我也有遇過反面案例是一些人會為了想偷懶而巧妙地「溝通」來推工作，溝通只是合作的一部分，有沒有積極的解決問題、採取行動，團隊夥伴們都看在眼裡，所以該改的設計稿、該做的事還是得好好做，希望好的工作技巧是用於維護使用者的體驗、堅守產品的品質。（＾Ｏ＾☆♪
我是露西，感謝你讀到這裡！ʕ •ᴥ•ʔ 如果你對新加坡工作和生活、產品觀察、使用者體驗設計有興趣的話，請記得追蹤我才能看到更多新文章哦！
