產品開發流程之 UX 設計師日常
想像一下五十個設計師的工作方式，除此之外還有產品經理、工程師、研究員等許多角色，開會的時間比打開 Figma 做設計的時間還多。
Hi👋 我是 Salie，目前在 Agoda 總部擔任 UX 設計師已有兩年多的時間。之前分享過面試流程和海外工作心得等相關文章，都可以到個人主頁參閱。本來想輕鬆一點條列星期一、星期二依序下去做了什麼，但好像有點無聊，從組織架構講起又好像有點繁重，但 UX 設計師的日常又勢必和軟體開發流程息息相關，只好從頭說起囉！
這篇會介紹 Agoda 的產品開發團隊組織架構（粗略說明）、設計流程與會議時程，其實放諸四海皆準，目前中大型規模的設計組織大多是以這個大方向運作，再依據團隊需求微調。
產品開發團隊組織架構
這裡介紹的組織架構源自 Spotify 於 2012 年發表的 Scaling Agile @ Spotify 白皮書，其實我們內部並沒有正式套用此架構，但實際的運作模式大致可以相互對照如下圖：
- 一樣顏色的小人代表同一個團隊：PM（產品經理）、DEV（工程師）、DES（設計師）。
- 一個小隊（Squad）代表最小單位的開發團隊，會包含 PM、多位工程師（前端、後端、QA）以及設計師。
- 一個部落（Tribe）由多個小隊（Squad）組成，通常是一個產品下有多個開發團隊各自負責流程中的一個部分，因產品高度相關而緊密合作。
- PM／工程師／設計主管（Lead）：也因為部落（Tribe）內部高度合作的關係，通常設計主管會帶領一個部落（Tribe）裡的所有設計師，但工程師因人數多，通常一個小隊（Squad）內就會有一個工程師主管。
- 圖示底部其他角色像是視覺設計師（Visual）、UI 設計師（主要負責 Design System）和 UX 研究員（Researcher）等仍隸屬於設計團隊，但工作內容較獨立，UI/UX 設計師會依據專案需求與這些角色合作，其他像 資料分析師（Data Scientist）、行銷部門人員（Marketing）也是依需求合作。
以 Agoda 飯店訂房產品為例：
可以看到下圖的垂直小隊（Vertical Squad）是以產品流程命名，也就是說每個小隊負責的是整個產品流程的其中一部分，雖然每個流程都有各自要解決的問題和任務，但設計實務上，還是會有許多共用的設計元件或功能等。
而水平小隊（Horizontal Squad）主要負責會員制、優惠訊息或 SEO 等會觸及所有流程的工作內容，因此水平小隊和各個垂直小隊其實有更加緊密的合作，透過頻繁的溝通確保彼此開發功能時不會有衝突。
介紹到這裡希望大家沒昏頭，雖然圖示上看起來有點複雜，但日常工作上還是以自己負責的小隊（Squad）為主和各自的 PM、工程師有緊密的會議。先把組織放一邊，接下來會介紹設計實務上的工作方法。
設計開發流程（Design Sprint）
業界常聽到的設計開發流程不外乎 Google 提出的 Design Sprint，在五天內完成發想 Ideas、產出設計、測試 Prototype、取得使用者回饋的高速設計開發流程。然而，設計師沒有一整天的時間可以關在會議室裡 Brainstorm 啊！一個禮拜的開發流程真的會很緊繃。
所以實際上，我們是跟隨工程師的 Sprint，開發週期以兩個禮拜為單位，也就是兩週的 Design sprint 後，就會緊接著工程師的開發 sprint，然後跑四週的 A/B testing，再決定要不要 100% 上線新的設計。也就是說理想上，至少要兩個月所有用戶才會看到新的設計上線，也可能 A/B testing 跑得不理想，新功能就這樣胎死腹中。
再來 zoom in 以設計流程（design sprint）和會議時程來看，平常 UX 設計師的工作以兩週的時間為單位是如何運行：
🟢 綠色小隊（Squad）相關會議：
- 綠色代表以自己所屬小隊為主的會議。
- 第一個禮拜會先有一個計畫會議（Sprint planning）以釐清 PM 在接下來兩個禮拜需要設計師完成的任務和優先順序，設計師就會開始發想、與利害關係人（stakeholder）討論（其他設計師或工程師）。
- 設計審查（Design review）是只有設計師參與的會議，主要討論目前手上的設計，給予回饋和建議，必要時也可以要求支援以便協調資源，通常僅有 Squad 內相關的設計師參與（例如一個做 Web 平台，一個人做 App 平台會有相似的功能需求，對於所屬產品的了解程度也比較在同一個水平上）。
- 與產品經理的設計審查（PM review）是在設計內部討論有共識後，展示設計與 PM 討論的會議，通常第一個禮拜會著重在大方向上的確認，設計師可能會提出幾個不同的 solution，在會議中與 PM 取得共識後，於第二週的設計審查提出最終設計，包含 UI 細節與 edge cases 等，準備好交付給工程師進行開發。
- 依照各自團隊的工作節奏，有些小隊會省略第一週的 Sprint planning，在第二週的 PM review 一併進行下一個 sprint 的規劃。
💡 只要和團隊角色之間，不管是設計師還是 PM 能清楚知道這個工作週期的任務，並密集在slack 回報進度、徵求回饋等，大家都希望會議越少越好。🔵 藍色工程師（Dev）相關會議：
- 工程師回顧／計畫會議（Dev retro/ planning）是設計師主要會加入的工程師會議，因為工程師會透過這個會議開始拆解設計、釐清需求，並著重討論接下來兩週 dev sprint 的任務，所以設計師的主要工作就是提供協助，若會議中討論到設計的改動，也能立即給予回饋和修正。
- 工程師前置會議（Dev pre-planning）跟上面的計畫會議有點類似，但是比較彈性，並不以時程為主，主要目的是提前討論任何階段的設計，以便工程師先行做功課、撈資料，或提出工程端的疑慮以便發想新的設計方向。
💬 工程師當然不只這個會議，但其他會議設計師僅依需求參與。🟣 紫色設計師（Design）相關會議：
- 紫色則是以廣義的設計團隊為主的會議（例如以 Tribe 為單位的所有設計師）。
- 設計主管會議（Design lead meeting）通常是主管提供資訊透明度的時間，會宣布較高層級的規劃，例如 COO 在主管會議提了這個策略，設計團隊這邊會如何因應。有時間的話也會回報每個人這週的工作規劃，或自由報名不限主題的五分鐘分享（Lightning talk）。
- 這裡還有一個別於小隊內部的設計審查（Design review）會議，一樣只有設計師參與，但是廣義的設計團隊都會參與，一個人約 15~20 分鐘自由報名分享，主要是希望設計師有更多機會討論設計，尤其是一些涉及多的流程、規模較大的專案。
除了這些例行性會議，其他一對一面談的會議就沒列上去了。撇除會議時間，除了做設計，還要寫研究計畫、追蹤 A/B testing 成效，真正打開 Figma 做設計的時間真的不多，也因此會議以外的時間，時常透過 slack 或五分鐘的通話討論設計方向，會省去很多溝通成本。
🎉 中場休息，給大家看一下辦公室一隅
溝通技巧是 UX 設計師必備的軟實力
看下來應該不難發現，UX 設計師除了畫 UI 想 UX，溝通技巧不外乎是最重要的軟實力，下面舉例的情境幾乎每天每週都在上演：
- 跨團隊／部門溝通
- 與 PM 達到設計提案的共識
- 開發中協助工程師開發需求（補 flow、補 spec、補 edge cases、提供 icon）
- 測試前與 QA 工程師審查上線版本（QA 主要看流程，設計師盯設計細節）
- 發想性質的專案（Exploratory project）通常不走 design sprint，設計師要思考是否需要抓研究（Research）時程，或拉視覺設計師的資源進專案
- 追蹤實驗結果並更新設計檔案，與利害關係人分享進度
除此之外，被例行性會議塞滿的工作時間，也凸顯了時間管理的重要性，除了確保自己手上的專案能按時交付，在有必要的情況下，拉長專案時程也是有可能的，這時候就要協調 PM 時程和其他設計師的 bandwidth 是否能支援等等。有時候也必須確認其他團隊相關專案的時程，以避免上線衝突。
最後，擁抱新科技的心態雖然很少人提到，但對新創或軟體開發團隊尤其重要，雖然這篇沒提到工作中會使用到的軟體（繁多不及備載），但除了大家熟悉的 Figma、Notion、JIRA 等，業界不時都在推出新軟體，公司也有許多內部工具要學習，因此保持開放心態不斷學習很重要。
希望看完這篇大家對 UX 設計師的日常與在組織內扮演的角色有更清楚的認識。
