產品開發之 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 了解進度並留下回饋。
相信不同規模的組織、專案都適用不同的溝通方式,希望分享這些方法能帶給你一些啟發和嘗試的機會,最重要的不是溝通的形式,而是搭起溝通的橋樑,並練習給予有建設性的回饋(這部分應該可以另外寫一篇)。共勉之!