產品開發之 UX 設計師溝通與合作技巧

產品開發過程中不免會接觸相當多利害關係人,身為產品設計師,除了要面對團隊中的 PM 和工程師,遇到中大型的專案,可能會與更多外部利害關係人合作,因此愈是大型的組織,愈加重視溝通技巧

以我自己的經驗,即便在公司待了多年,換到新的產品線還是會有些許不同的文化和溝通模式,尤其身為主產品線的設計師,還須兼顧其他副產品線的團隊需求,不然等到新功能都 build 完上線了才發現,真的是會很尷尬。因此在開發流程中設立各個溝通的接觸點(touch points),才能盡量避免這樣的情況發生。

下面這張圖我列了幾個常見的溝通方式,這篇會針對幾個非常推薦或是比較少見的溝通方式作分享。不只適用於設計師,而是能幫助整個產品開發團隊事半功倍的小撇步。(其實很多都是跟工程師偷學的)

主要會以下面這些工具作討論,但其實功能大同小異,應該在不同工具上都能找到類似的功能。🎨️設計/討論工具:Figma
💡專案管理工具:JIRA、Confluence
💬溝通工具:Slack、Outlook

1. 群組通知

標記一個 User Groups 就能通知所有相關人士

從最頻繁的進度更新或即時討論開始,我會善用 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 了解進度並留下回饋。

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

👏 記得拍手、追蹤或 Donate 支持我分享更多經驗

--

--

Product designer with curiosity and a growth mindset. Offering time on ADPList, or find me via LinkedIn.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Salie Chien

Salie Chien

725 Followers

Product designer with curiosity and a growth mindset. Offering time on ADPList, or find me via LinkedIn.