什麼是 Design System？
- 文章發表於
前言
還記得那是我大學剛畢業不久，進入職場的第一份工作。當時公司前端團隊還在草創階段，整個團隊就只有主管和我這個剛入行的菜鳥，兩人得一起應付四面八方湧來的需求。那時的我對產品開發幾乎一無所知，連「套件」和「前端基礎建設」是什麼都搞不太清楚。沒想到入職場的第一個任務，就是開發一套後台發券系統，對當時的我來說，簡直是一場地獄級的試煉。
拿到設計稿後，我沒多想就埋頭開始「刻畫面」，反正畫面能跑出來就好。那時的我複製貼上的功力堪稱爐火純青，完全沒意識到 JavaScript 早就支援模組化（import / export）。自信滿滿地完成第一頁後，我把程式交給主管審閱，只見他臉色瞬間鐵青。心裡可能在想：「我是不是招錯人進來了？」
所幸當時主管沒有直接請我回家吃自己，仍不厭其煩地耐心指導。他建議我在專案的程式碼中建立一個 /components 資料夾，將像按鈕、輸入欄這類會重複使用的介面元件拆開模組化，方便統一管理。再透過元件展示工具 Storybook，集中呈現這些元件，讓設計師在對稿時也能更方便地檢視確認，省去了比對相同元件的時間。
專案完成後有種升等的感覺，當下真的覺得超酷！這是我第一次接觸模組化，也第一次學會使用 Storybook。雖然整個過程在 UI 對稿上踩了不少雷，進度硬是拖了兩倍時間，還被測試團隊抓出上百個 bug……但那又是另一段荒謬又精彩的故事了。
幾個月後，我參與了團隊的元件庫建置，從原本只有四、五個共用元件，擴展到二十多個。這段經歷讓我真正理解，一個「好用的元件」不是寫完就好，它需要反覆與設計師協作調整，更重要的是，其他工程師要能夠無痛使用，才能真正發揮它的價值。
當然，要說服產品經理和設計師不要每個專案都從頭設計，同時又要讓元件具備彈性與可擴充性，是另一項挑戰。而設計系統，正是解決這些問題的解方。
什麼是設計系統？
A design system offers a library of visual style, components, and other concerns documented and released by an individual, team or community as code and design tools so that adopting products can be more efficient and cohesive. -- by Nathan Curtis in Defining Design Systems
這段出自 Nathan Curtis 對於設計系統的解釋，也是最貼近我對設計系統的定義，Design System 含了品牌價值、設計原則 (Design Principles)、設計標籤 (Design Token)、組件庫 (UI Library)、設計模式（Design Pattern）以及可訪問性，而最終的目的是為了讓產品的開發更有效率，並且提供一致的用戶體驗。
如何設計一個設計系統？
| 沒有一個設計系統可以解決所有問題，只有適合自己團隊的設計系統。
設計系統從來不是一蹴可幾，它往往需要經歷多次迭代與調整。對於初創企業來說，設計系統甚至可能根本不是當下的必要，除了文化上傾向快速迭代，更多時候是因為產品規模尚未成熟。如果在這個階段就貿然投入設計系統的建置，往往會因應產品需求不斷修改設計系統本身，反而拉高了人力維護成本。
設計系統真正的價值，通常會在公司發展到一定規模後才逐漸顯現。想像一下，當團隊人數增加，不同工程師可能在不同頁面上實作出風格不一致的按鈕或元件，不僅造成視覺上的混亂，也會讓後續品牌更新變得更加困難，甚至需要額外投入大量人力重新整理樣式。
雖然每間公司或團隊所需要的設計系統架構都不盡相同，但仍有一些共通的基礎可以參考。根據 InVision Design System Handbook 中的建議，我們可以從以下幾個角色與步驟著手：
- 誰應該參與設計系統的建置？
- 設計師：負責定義整體視覺語言，從色彩、字體到按鈕、輸入框等介面元件的樣式。
- 前端工程師：負責將設計轉化為可重用的元件，並封裝成模組供團隊使用。
- 產品經理：負責掌握產品方向，確保設計系統能夠支援實際業務需求。
- 無障礙設計專家（Accessibility Specialist）：確保所有元件皆符合可訪問性標準，提升整體使用體驗。
團隊要如何設置？
根據 Jina Anne 的 The Salesforce Team Model for Scaling a Design System 的文章提到，
設計系統的團隊可以分成三種模型，分別是孤立式 (isolated model)，集中式 (centralized model) 以及分佈式 (distributed model)。
孤立式: 團隊剛成立時，這種模型最為常見，因為通常人力只夠有一個人負責開發設計系統，優點是快速以及不用太多討論就可以彈性的調整，缺點是可能會因為人力不足而忽略設計系統的維護。
集中式: 這種模型是將設計系統的維護交給一個專門的團隊（通常是前端基礎設施團隊)，優點是可以專注在設計系統的維護，缺點是可能不像那些直接參與產品開發的人那樣了解客戶的需求。
分佈式: 最後是分佈式，讓不同團隊的人員一起參與設計系統的維護，優點是產品端的開發者通常有更好的用戶洞察力，可以建立更符合用戶需求與體驗的組件，缺點是可能會因為不同團隊的人員不一定會有足夠的時間貢獻在設計系統上。
讓設計系統可以符合公司的品牌價值
大多數的公司都會有該公司的品牌價值，而這個品牌價值就會反映在設計系統的視覺元素上，其通常包括顏色、字體、間距與動畫。
例如 Shopify 的 Polaris Design System
又或是 AWS 的 Cloudscape Design System
如果有時間，不妨實際看看這些設計系統的展示，會更清楚「視覺元素」與「品牌價值」如何構成設計系統的基礎。設計師會根據這些視覺規範設計各種元件，前端工程師則負責將它們落實在產品中。
建立 UI Library 以及建立設計系統的文件
在完成前置作業後，下一步就是建置 UI 元件庫，將可重複使用的元件模組化。其中「原子設計（Atomic Design）」是業界常用的架構方法之一，從最小、不可再分的元件出發，逐步組合出更高層級的結構。這些小元件就像樂高積木一樣，最終組合出完整的頁面。
原子設計就是將組件分成五個層級，分別是原子 (atoms), 分子 (molecules), 組織 (organisms), 模板 (templates) 以及頁面 (pages)。
最後，需將設計系統完整文件化，明確記錄設計規範、設計標籤（Design Tokens）以及現有元件。有了這些文件，團隊成員能在開發過程中快速對齊，加快實作效率，並維持一致的使用者體驗。
延伸閱讀
