產品開發之 UX 設計師溝通與合作技巧
產品開發過程中不免會接觸相當多利害關係人，身為產品設計師，除了要面對團隊中的 PM 和工程師，遇到中大型的專案，可能會與更多外部利害關係人合作，因此愈是大型的組織，愈加重視溝通技巧。
以我自己的經驗，即便在公司待了多年，換到新的產品線還是會有些許不同的文化和溝通模式，尤其身為主產品線的設計師，還須兼顧其他副產品線的團隊需求，不然等到新功能都 build 完上線了才發現，真的是會很尷尬。因此在開發流程中設立各個溝通的接觸點（touch points），才能盡量避免這樣的情況發生。
下面這張圖我列了幾個常見的溝通方式，這篇會針對幾個非常推薦或是比較少見的溝通方式作分享。不只適用於設計師，而是能幫助整個產品開發團隊事半功倍的小撇步。（其實很多都是跟工程師偷學的）
主要會以下面這些工具作討論，但其實功能大同小異，應該在不同工具上都能找到類似的功能。🎨️設計/討論工具：Figma
💡專案管理工具：JIRA、Confluence
💬溝通工具：Slack、Outlook
1. 群組通知
從最頻繁的進度更新或即時討論開始，我會善用 Slack 的使用者群組（User groups）通知所有相關人員。例如設計師和 QA 工程師會有一個 @sign-off 群組，當工程師將新功能放上測試網站時，就只需要標記 @sign-off 這個群組，而不需要一一標記我和其他 QA 工程師。
當身為設計師的我需要找工程師討論設計時，我也只需要標記 @developer-all 群組，而不需要標記團隊裡的七位工程師和 PM 等一堆人。
當然這個方式可能會有一個缺點是，假如是一個 bug fix 的確認，如果標記 @sign-off ，那身為設計師你就會收到一個可能無相關的通知，要花個幾秒鐘看看需不需要回應還是不關設計的事，這種情況可能就要設定更細節的群組。但我自己是比較傾向不管有沒有相關，都留意一下團隊更新，了解工程師的開發進度，持續追蹤自己的設計。
收信工具 Outlook 其實也有類似 Slack 使用者群組的功能叫聯絡人群組（Contact Group），用途上大同小異，只是功能是套用在收發信和會議邀請上。
2. 討論群 Slack channel/ Figma comment
不只是 Slack，大部分的通訊軟體都有支援群組（Channel 或 Private Group）功能，讓公司內部大大小小的團隊能建立各自的討論群溝通工作內容。以我所屬的產品開發團隊為例，我們在 Slack 上就有至少五個相關的討論群：
#fe-design：設計師和工程師討論
#fe-review：工程師內外部的 code review 或外部工程師發問
#fe-internal：工程師內部使用（請假、討論 team building、閒聊等）
#design-pm：設計師和 PM 討論
#design-internal：設計師內部使用（請假、討論設計、閒聊等）
針對臨時的短期專案，或是針對設計規範的問題等當然也會有另外的討論群，但以上主要是針對產品開發為主基本會有的討論需求而建立的群組。
另外每週和 PM 開完例行會議，我也會在 Slack 列下結論，例如這週設計師預計會完成的工作和進度，若有多餘的時間會發想其他專案等。以免會議上時間緊湊，或沒有說清楚的地方。3. 例行性團隊會議
在之前的文章裡有分享過這張會議時程圖，跑敏捷的產品開發團隊幾乎每天都有 Sprint 相關的例行性會議，身位設計師的我其實不會所有會議都參加（例如工程師的回顧會議（Retro）），每天的 Standup 也太瑣碎。但工程師的規劃會議我就不會錯過，以便了解開發進度，並即時回答任何設計相關問題。
除此之外，每週二我們也會有設計團隊的 Critique 會議，即便做不同產品的設計師，也會分享任何設計進度，邀請大家集思廣益，或者分享使用者研究的洞察，多多少少對彼此的專案都有幫助！
4. 發起工作會議（working session）討論想法
當時間緊迫的專案，或日常的例行會議太發散，沒辦法聚焦討論時，我們就會另外拉一個會議，邀請跟討論主題密切相關的設計師，一起發想解法。
這類會議通常會發生在兩個產品團隊在設計階段就遇到衝突時，例如圖示的例子，兩個團隊都在做類似的功能，就會需要協調出共識，再各自和專案 PM 溝通。
5. 有效的專案管理減少溝通成本
大部分的人想到專案管理，可能就是 JIRA 上的工作進度規劃，或是 PM 給的需求文件，但其實身為設計師也必須做好專案管理工作。
特別是執行大型專案時，前期的設計時程規劃、使用者研究報告和重點，以及設計迭代的歷程，如果沒有妥善整理好來龍去脈，到了專案後期常常會發生忘東忘西的情況，例如：當初不走某個方向的原因，可能還在專案初期，大家的意見都比較發散。這時如果有記錄下結論或會議筆記，就可以回去翻找，不用想破頭了。
這邊舉的例子是我在 Figma 上會有一個專案的 Master File，在這個檔案裡可以找到所有專案相關資料並以數個頁面整理，從每週的設計迭代、原型、使用者研究報告，到遞交給工程師的 Hand-off（通常會另外拆成獨立檔案，但這裡還是會留底）。不僅幫助自己梳理設計流程，也方便其他設計師或 PM 了解進度並留下回饋。
相信不同規模的組織、專案都適用不同的溝通方式，希望分享這些方法能帶給你一些啟發和嘗試的機會，最重要的不是溝通的形式，而是搭起溝通的橋樑，並練習給予有建設性的回饋（這部分應該可以另外寫一篇）。共勉之！
