[講座記錄] DesignOps 04：設計系統——打造溝通無礙的統一語言

1 前言

「設計系統 Design System」的概念行之有年，但在推動上面，需要花上很大的溝通成本，進行跨部門的協作與修正，隨著產品畫面的增加，人員的來往，而且還會排擠到原先的開發進程，都可能讓設計系統的推動變得更窒礙難行。

有這麼多要考量的點，那該怎麼開始呢？🤔

DesignOps 設計營運系列講座 第四場「設計系統」邀請 PicCollage 拼貼趣（一款追求自由創造及分享的照片/影音拼貼 app）的 Design Engineer – 立秦、 Product Designer – Morgan 來分享過去在製作上的經驗，讓我們接著往下看吧！

▌如果你是設計師，可以從中了解建構設計系統的 tips，嘗試推行。

▌如果你是 PM ，或許可以導入設計系統，讓產品開發更順暢。

▌閱讀小提醒：每間公司在設計系統的管理上，會因為資源分配或專案進行方式不同而有所差異。本場講座的設計系統，屬於公司既有設計團隊共同維護。

思考設計系統的運作時，可先掌握團隊陣形，有些公司可能是一人團隊，有些則有專屬的設計系統團隊。（相關概念請參見上一場 DesignOps 03：建立團隊及文化）

在此也提供一些有趣數據，足見大家熱切關心設計系統。這場講座在全系列中，創下了一些紀錄：

1. 單場報名人次最高
2. 超時最久、討論最熱絡
3. 影片票銷量最佳

2 什麼是「設計系統」？

立秦首先拋出了一個問題引發大家思考：

過去在面對產品畫面不一致的時候，會透過系統化的方式，將相似、功能重複的 component（元件）組合並加以整理，形成 UI Kit （設計套件）。我們也很常在網路上看到許多主打元件豐富的免費或付費資源，這樣子的內容，是所謂的設計系統嗎？

從實戰定義來看，設計系統是一種語言，用來溝通團隊的開發流程、表現產品給使用者的核心價值。

設計系統不僅是介面設計，更是與工程師討論實作的文件。在每個元件製作的時候有沒有相對應的開發日誌、清單，來給予不同的設計師標準，不會有些方方的、有些圓圓的；有些不屬於這個系統、有些講不同種語言。

透過設計與工程的協作，制訂出一套合適的規範，讓設計決策用文件化的方式記錄下來，讓現有的團隊能夠友善溝通，後進也能依循對應的規範文件去處理，一步步的去融入並且運用，將時間花在更有意義的地方。

3 為什麼需要設計系統？

以 PicCollage 為例，立秦列舉出三個實際面臨的處境，讓團隊決定動手打造設計系統：

• 設計師端：過去設計版本散落在各個設計師的電腦，導致各個元件各別解讀、各自表述
• 工程師端：不斷重複做相同的功能元件，希望不要重工，把心力放在更大的挑戰上
• 使用者端：產品的體驗不一致，按鈕大小不同、陰影輕重不同

4 導入設計系統前的準備

• 人：蒐集隊友，排定會議頻率、任務優先順序，凝聚大家共識，把下一步行動講清楚
  ↳ 訣竅是可以利用午餐時間與同事聊聊，軟性尋找有共感、有意願的人，一步步鋪陳，不急著馬上 kick off
  ↳ 待人員到齊後，發起人把自己定義為主持人（而非負責人），梳理有哪些資源，去定義設計系統專案的小 road map，敲大家共同負擔項目，營造一個大家都能提問的氛圍
• 事：探討設計系統的內涵，參考類似規模團隊的文件，參考資源分配、執行方式、怎麼創新與維護
• 物：運用 Atomic Design（原子設計）概念，從最小的設計元素進行規範，再依照需求組合延伸成更多組件

5 案例分析 – PicCollage 拼貼趣

• 設計師負責內部盤點

作為一個超過 10 年的產品，在設計與工程上勢必累積了不少需要整理的地方，設計端盤點過去所有的設計文件後，決定從最基礎的元素、顏色開始執行。

↳ 拼貼趣是一款圖像與影音編輯器，每個子目錄展開都會有更多編輯功能，立秦特別以顏色為例，常見的規範大多會依照百分比的方式來整理，例如 Google 的 Material Design 單一色擁有多個色階。但還是要根據每個產品需求程度來決定，太多的選擇，反而會造成選擇障礙的情況。

↳ 整理設計系統是一段刻苦耐勞的過程，把所有能性列出來。

• 與工程師一起診斷

當設計列出顏色後，協同工程師調閱顏色的 code。就如簡報中放大的湖水綠，有 4 個 code 都指向同一種顏色，需要校正為一個項目。這相當考驗有沒有好的工程師隊友，理想上意識到這是必要改變的工作，但執行上很花時間，得反覆溝通。

• 爭取開發資源

設計師與工程師的合作，能否根據團隊固定開發流程，變成固定任務？這是發展設計系統很重要的思考面向，按部就班逐一執行，先做一小部分、看看合作效果，而不是列很多待辦清單，打高空球。

當顏色處理到一段落，接著立秦分享用相似工作原理整理 icon，強調製作過程具體規格化，此部分範例詳見講座影片。

• Automation 自動化交付

為了讓設計師與工程師協作間更省時，立秦也分享 Figma handoff script 的應用經驗，讓工程端只要跑一個 script，設計端的資料就能跑到 code base 裡面。

6 案例分析 – Umbo

Morgan 分享自己在 Umbo（安全監控產品）做設計系統的實戰經驗，當時由組織成員發起，在前期就有工程師一起參與，參與討論的同時也能讓他們了解設計師的思考脈絡。 在 UX guideline 的文件中，需要將組件的規範定義清楚，包括使用的情境、與其他元件交互的樣態，讓工程師可以自行參照著處理。 以整理 Search Bar 為例，總共進行了 4 個環節：

• Audit：大量去找現有的相關元件，每個都截圖下來
• UI Proposal：盤點過所有元件和需求，提出新的 UI 應用方式
• UX Guideline：汰選並推敲後的元件，都需合乎使用邏輯，透過詳細文件資料記載用途、解剖元件內容、彈性變化的狀況
• Implementation：當文件確認無誤後，再交由工程師實作

7 迭代：維護設計系統

設計系統建置完成後，Morgan 認為團隊能否有維護的心態很關鍵。透過團隊一起打造出來的內容，同樣也需要大家一同維護。用 質化 的方式在日常搜集問題，寫下完整的描述利於討論與瞭解使用情境，定期覆盤確保設計系統的健康程度，讓大家一起更新。

立秦接著提出 量化 的方式來檢視設計系統的健康程度：

– 製作面
製作新元件的速度：團隊接收並了解需求，加上與工程協作的時間
更新既有元件的速度：掌握更新時會產生的影響，並在一定時間內處理完成

– 使用面｜透過 Figma Design system 分析
Component 使用率：元件使用的情況
Component Detach 頻率：比例高的話，代表元件被使用的情況不佳，可再做調整
在產品中使用的比例：所有元件在介面上的使用情況

總括來說，以下幾點有助建立統一且有規律的迭代流程：

• 固定在專案結束 / 工作期結束進行
• 知會團隊，一起討論
• 記錄問題、累積問題、討論問題
• 文件、解法、要資源
• 依照資源與需求決定定期回訪的時間 （每雙週的設計系統建立會議 → 每月/每季的更新會議）

8 參考資源

二位講者分享了工作中參考過、覺得很棒的設計系統與資源，分別有不同的屬性：

• Orbit
  適合正要導入設計系統的團隊，從不同角度了解團隊需求，以及規劃相關排程。這是一人設計團隊，設計師利用許多小故事闡述原本有設計系統，但團隊都不領情，透過溝通技巧讓大家漸漸接受。

• Data-informed Design Systems
  給已經在維護設計系統團隊一些數據分析模式，去評估系統的成效與生命週期。用數據驅動設計系統的成效，在每個階段時應該了解哪些人的需求，應該拉哪些資源去做相對應的功能。

• Design Systems Survey 2022
  這份國外的設計系統調查，談論到執行設計系統的首要任務與最大挑戰。其中，「人員編制」普遍可能認為緊要性不高，但實際執行時，才發現人力不足是個硬傷，回應 Morgan 提到的能否有個主持人固定敲大家推進下一步。

• In the file – A masterclass in organization with Dataguard
  這場講座中，產品設計師 Santosh Komaragiri 的設計系統，不只是服務設計團隊本身，更拓展到業務與行銷團隊上，很值得按暫停回頭去看講者怎麼管理檔案。

9 總結

設計系統的建置，團隊所要付出的心力不亞於開發一個產品，透過不斷的盤點內容、討論規範、使用情境，讓團隊更加熟悉這個工具的操作，更重要的是團隊心態需要維持一個開放的氛圍，才能更靈活的去維護與更新。

接下來，講座將進行到第五場「人才培育」的主題，邀請二位資深設計主管，談談如何辨別人才特性因材施教，並設定適合的目標。

「DesignOps 系列講座」講題、案例與講者資訊皆為 2022 年時空背景。

2023 年起，DesignOps 概念依然實用，講座不拆售，我們鼓勵參與全場，學習更扎實！