Design System 文件化（上）— 設計師如何將 components 變成開發團隊看得懂的文件？
本文是以設計師的角度，分享 design system 文件化前的前置作業，著重於將 UI elements 收斂成 token 和 components 的流程，讓有聽過 design system 但不知道怎麼執行的開發團隊人員有個切入點。
最近參加了一場講座，發現在 Q&A 環節中，有好幾個人想知道怎麼在公司進行 design system 專案，講師也分享了他們的現況、流程與方式，但是這個問題有蠻多細節可以說，恐怕不是在 Q&A 環節就能夠講清楚的，受到啟發的我想來分享一下我們公司的狀況。
1. 流程簡述
我們會先在 Figma 上把 UI elements 設計成可複用的 components，並在旁邊加上註解或使用規則，以工程師能夠先完成專案為主。只有少部分的 components 會在專案開發階段，被工程師製作成日後可複用的 UI component library。
由於沒有專門的小隊在處理 design system，設計師會在專案空檔先將 components 文件化，讓開發團隊理解並達成共識，等工程師趁專案空檔把更多 components 變成 UI component library，所以對於設計師來說，這個流程的任務會是：
- 建立 design system 中的 components
- 將 Figma components 文件化
2. 如何建立 design system 中的 components？
兩個任務的細節雖然多，但其實可以合併步驟一氣呵成執行完畢，不過在我們公司任務間隔時間蠻長的（不要問多長，很可怕），所以拆開解釋比較適合，我會分成上下篇來說明。
如何把一個 Figma 中的 UI elements，變成可複用的 components，步驟如下：
- 地毯式搜索
- 分門別類
- 檢視當前使用情境
- 拆解與重組
2–1. 地毯式搜索
將產品內所有新舊檔案的 Ul elements 大量截圖，或在 Figma 開一個新的設計檔，把 Ul elements 都放進該檔案方便日後進行比對，如果是在網站截圖的，可以用 Inspector 把相關資訊記錄下來，檢視上線產品與設計稿是否有不相符之處，先前因為沒有統一風格和結構的設計，還有重複開發內容相似但結構迥異的 code 在這時統統抓出來。
2-2. 分門別類
將蒐集到的 Ul elements，依照功能與使用情境區分類型，以 form 為例可能分成常見於表單的 input、dropdown 和 check box 等，在使用目的和操作行為就有明顯的差異，但如果是通知類型的 Ul elements 可以怎麼區分呢？
- 忽視通知是否會影響操作？（阻礙用戶下一步操作）
- 通知是不是來自系統的反饋？（用戶操作後觸發的回應）
- 用戶需不需要與通知互動？（可操作要素的有無）
- 通知會不會自動消失？（通知的留存機制）
根據行為和操作情境來判斷，可以分成的類別如下：
alert
- 不可忽視的存在
- 來自系統的反饋
- 會強迫用戶一定要操作
- 不會自動消失
announcement
- 放在很明顯的位置，但可以忽視
- 自動顯示於瀏覽器中
- 滑動頁面時，可能置頂顯示或者被隱藏
- 不會自動消失，可點擊關閉
toast
- 會擋住內容，但可以忽視
- 自動顯示於瀏覽器中
- 可互動，顯示維持在置底位置
- 可自動消失或利用點擊關閉消失
flash notice
- 會擋住內容，但可以忽視
- 來自系統的反饋
- 不需要互動
- 會在時限內自動消失
光是通知就可分成四種類別了，要注意分類方式與命名依照不同公司的產品而有所不同，像是我們的 alert 跟 Boostrap 的 Modal 以及 Skyscanner 的 alert 很接近，如果不確定怎麼處理，先參考知名企業的做法。
2–3. 檢視當前使用情境
檢視 UI elements 的應用範圍與產品中使用的狀況，以 button 為例，將所有的設計或截圖放在一起觀察後可能會發現多處不同，要讓各種不同形式的 button，統一成可用的 components，可以從幾個地方收斂：
- button 的顏色，除了 Primary Color和 Secondary Color，是否還需要其他的？（例如 Neutral Color）
- button 的樣式，是否有 Solid 和 Outline 就足夠，有沒有在曾經使用過沒有邊線沒有底色的 button？
- button 的字重，是否有需要使用多個？（使用 web font 的話，越多的字體或字重可能會拖累網路效能影響體驗）
- button 的間距，是否能依照 S / M / L 不同的尺寸，以及與 icon 的間距，統整合適的間距？
- button 的狀態，除了 enable、hover 和 active，有沒有需要 loading、visited 和 disabled？
將以上問題思考過，保留當前需要的就好，曾經使用但不再需要的封存，目前還沒有但日後可能會出現的，與工程師討論架構與保留可擴充性即可，暫時不需處理。
2-4. 拆解與重組
接下來要將 UI elements 拆解成不同的層級如 token、components 和 pattern，整理尺寸、間距、對齊等，才能在 Figma 建立一個 design system。
如果說 components 是可重複使用的物件，例如 button，而 pattern 是特定場景下的物件組合，例如 search bar （text field+dropdown+button），那 token 是什麼呢？
3. Token
我們可以看一下 Adobe 是怎麼解釋 token 的：
Design tokens — or tokens, for short — are design decisions, translated into data. They’re ultimately a communication tool: a shared language between design and engineering for communicating detailed information about how to build user interfaces.
Tokens consist of values needed to construct and maintain a design system, such as spacing, color, typography, object styles, animation, and more. They can represent anything that has a design definition, like a color as a RGB value, an opacity as a number, or an animation ease as Bezier coordinates. We use tokens instead of hard-coded values so Spectrum can scale and support the complex ways that Adobe products need to intersect as a cohesive ecosystem.
把顏色、字體、間距等屬於 components 屬性的數值，看作是組成 components 的最小單位，我們使用語意化的命名，例如 primary-background-color，來取代編碼 #1E9FD2 或是 rgb(30, 159, 210) ，這種方便設計師與工程師開發與溝通的代碼化語言，就是 token。
以 button 來說就由非常多個 token 組成：
- 顏色
- 文字
- 邊線寬度
- 圓角
- 間距
- 陰影
拆解與重組的過程可參考知名公司的 design system 中 token 的使用方式，並根據自家產品選擇合適的方法來應用在設計或程式碼中，token 可以讓開發團隊在不同的平台保持一致和同步，減少重複的工作和錯誤。
介紹完 token 後，想來分享一下我們在 Figma 建立的 token ，分別是：
- 顏色
- 間距
- 文字
- 陰影
3–1. 顏色
顏色可以區分成主題色、狀態用色與中性色三個類別。
主題色一定會有一個 Primary color，有時候包含 Secondary color，Primary color是產品中最重要的顏色，它能吸引用戶的注意，會出現在 call-to-action、button 或重要情報上，Secondary color 則用來強調相對重要的資訊。
狀態用色則是依據各種情境，提供符合對應情緒的色系，Warning color 代表著注意提醒，Success color 強調安心感以及任務達成，Danger color 會用在不可逆的毀滅性操作。
Neutral color 也就是中性色，代表缺乏色調、低飽和度的黑白灰以及咖啡色，這些顏色不與人競爭，統合整體氛圍，能夠很好的襯托其他顏色，並增加頁面的層次和深度。
我們產品有 Primary / Warning / Success / Danger / Neutral 五種色系，每一種都有 10 個色階，色階是借用 Ant Design 的色版生成工具 和 Shade Generator 算出來的，這兩個工具都只要輸入色碼，就可以自動產生一組色階。
同場加映另一個色票生成的網站 0to255，只要輸入色碼，就可以自動產生一組色階，這個網站的特色是可以選擇色階顯示的方式為 HEX、RGB 或 HSL。
若想看更多 Neutral Color 的介紹請看：
3–2. 間距
我們的元件是採用 8 point grid system 建立的，原則上是以 8 為單位的網格系統，利用 8 的倍數來設計頁面中元件或版型的尺寸及各自間距的大小的設計法則。
8 point grid system 的優點：
- 提高設計效率，減少思考尺寸的時間。
- 方便設計師和工程師之間的溝通，減少細節上的差異。
- 增強產品的一致性和專業性。
8 point grid system 的缺點：
- 早期多數裝置的尺寸是可以被 8 整除的，但現在不是了，需要設計師靈活調整。
- 佈局的尺寸應該根據內容而定，有時 8 點的網格並不適用。
什麼情況可能會不適用呢？以收藏旅宿 button 為例，根據格式塔原則，佈局中距離接近的物件們，能被視為同個群體，如果跟隨 8 point grid system，愛心 icon 與收藏旅宿會保持 8px 的間距，但我們想要強調兩者的關聯性，討論過後最後選擇使用 4px。因此除了原本的 8 point grid system，我們還是增加了幾個 4 的倍數的間距，增加設計上的彈性。
若想看更多 8 point grid system 和格式塔原則的介紹請看：
3–3. 文字
Heading 和內文的字型設定，我們使用 Google Fonts ，讓不管是顯示在 Mac 或者 Windows 系統的裝置，都能有相同的呈現。字級則借用線上工具 Type Scale 來輔助，因為我們網站頁面資訊量蠻多的，不希望字太大讓頁面過長，因此選定 base size 為 14px 來產生字級級距，並做一些調整。
Type Scale 產生的 font-size 有時有小數點，而 line-height 偶有奇數，除了 base size 14px 不能被 4 整除，我們把其他的 font-size 和 line-height 的參數都調整成可以被 4 或 8 整除的整數。
3–4. 陰影
我們參考了 Google Material Design 的 Elevation 和 Light and shadows，確認 UI elements 在佈局中的相對位置與高度後，才定義使用的陰影的參數：
- shadow 01，可用於 raised card
- shadow 02，可用於 dropdown 和 popover
- shadow 03，可用於 navigation、drawer 和 header
- shadow 04，可用於 floating button
4. 結語
以上是由設計師的角度來介紹建立 design system 中的 components 的步驟，從開始意識到 design system 的重要性，著手建立 UI elements，持續製作 token 和 components，到最後的文件化，可能會有人想知道，什麼時候有做完的一天？但隨著專案進行，這個計劃可能會擴增內容或是封存舊設計，我們設計師能做的就是盡力讓 design system 越來越完整。
如果想要更了解 token ，推薦看以下這篇文章。
如果想要更了解原子設計 ，推薦看以下這篇文章。
如果是想要以工程師的角度來理解，PicCollage 的工程師 Lichin Lin 有在 youtube 進行長達6小時免費的直播課程，也有教授 Design System Handbook 設計系統實作指南，我在寫文章前有看了直播，對我很有幫助！
下一篇會介紹我們怎麼定義規則來統一文件化的格式！！
