昨天談資訊架構（IA），把重點放在「內容怎麼組織、怎麼命名、怎麼被找到」——那是一張看不見的骨架圖，決定使用者在腦中如何建立地圖。但骨架定好之後，總得長出血肉：導覽列要用哪顆按鈕、卡片的圓角與陰影長什麼樣、深色模式下的文字對比夠不夠。若每個畫面都重新捏一次，團隊很快就會做出十七種略有差異的按鈕。設計系統（Design System）就是把「介面建構」這件事，從一次性手工藝，升級成一致、可複用、可規模化的生產線。今天講的，是從「內容組織」跨到「介面一致性與規模化」的那一步。
📖 學
設計系統不是一份漂亮的規範文件，而是一整套「讓一群人持續做出一致產品」的活系統。它至少包含四層東西：設計原則（我們相信什麼、為什麼這樣做決策）、設計代幣與樣式基礎（顏色、字級、間距的數值真相）、可複用元件（按鈕、輸入框、對話框的設計與程式碼）、以及使用指引與治理（何時該用哪個元件、誰維護、怎麼貢獻）。少了原則，它退化成素材包；少了程式碼，它只是給設計師看的圖；少了治理，它半年後就分叉成一堆殭屍元件。真正的設計系統是「設計 + 程式碼 + 文件 + 人」的組合，缺一角都撐不住。
釐清幾個常被混用的名詞，能幫你判斷手上那份東西到底是什麼。UI Kit 是一包可拖拉的視覺素材（多半是 Figma 檔），給你現成的按鈕、卡片、圖示，但它通常不管背後的程式碼，也不談原則。樣式指南（Style Guide）偏重「品牌與視覺規範」——logo 留白、色票、字體用法，源自平面設計傳統，講的是「長怎樣」。模式庫（Pattern Library）收錄「可複用的介面解法」，例如「表單驗證錯誤要怎麼呈現」「分頁 vs 無限捲動何時用哪個」，講的是「怎麼解問題」。設計系統則是把上面全部包起來，再加上程式碼實作與治理流程的最大集合。簡單記：UI Kit 給你零件，Style Guide 給你外觀規範，Pattern Library 給你解法，設計系統把三者接上真實產品並讓它持續運轉。
Atomic Design 是理解元件如何組裝的經典心智模型，由 Brad Frost 提出，借用化學的比喻把介面拆成五層。原子（Atoms）是最小不可分的元素，例如一個標籤、一個輸入框、一個按鈕、一個色票；它們單獨存在時沒什麼用，但是一切的基礎。分子（Molecules）是幾個原子組成的小功能單元，例如「標籤 + 輸入框 + 送出按鈕」組成一個搜尋列。組織（Organisms）是分子與原子拼成的較大區塊，例如網站的頁首（含 logo、導覽選單、搜尋列）。模板（Templates）是把組織排進版面骨架，定義佈局但先用假資料佔位。頁面（Pages）是模板灌入真實內容後的具體實例，也是拿去做可用性測試、發現「這欄標題太長會爆版」的地方。這套框架的價值不在於嚴格分類（實務上原子和分子的界線常吵不完），而在於它逼你「由小到大、可複用地思考」，而不是一個畫面一個畫面地硬刻。
| Atomic Design 層級 | 化學比喻 | 實際 UI 對應 |
|---|---|---|
| 原子 Atoms | 最小元素 | 按鈕、輸入框、標籤、色票、字級 |
| 分子 Molecules | 原子組合 | 搜尋列、帶標籤的輸入欄、卡片標題列 |
| 組織 Organisms | 較大區塊 | 頁首、商品卡片、留言區、導覽列 |
| 模板 Templates | 版面骨架 | 商品列表頁佈局、文章頁佈局（佔位資料） |
| 頁面 Pages | 具體實例 | 灌入真實內容的首頁、某篇文章頁 |
設計代幣（Design Tokens）是整個系統的「單一真相來源」，也是近兩年最關鍵的基礎建設。所謂代幣，就是把設計決策存成有名字的變數，而不是散落各處的魔術數字。與其在程式碼裡到處寫 #1A73E8，不如定義 color.primary；與其記住「間距用 16px」，不如用 space.4。成熟的做法會分三層：原始代幣（Primitive，如 blue-500 = #1A73E8，純粹的調色盤）、語意代幣（Semantic，如 color.action.primary = blue-500，帶意義的用途）、元件代幣（Component，如 button.background = color.action.primary，綁到特定元件）。這種三階架構的威力在切換主題時最明顯：深色模式只要把語意層重新指向不同的原始值，color.text.primary 在亮色是近黑、暗色是近白，所有元件自動跟著變，不必逐一改。代幣還能跨平台同步——同一份來源可以輸出成 Web 的 CSS 變數、iOS 的 Swift、Android 的 XML，讓設計、前端、行動端說同一種語言。
元件庫的核心挑戰，是讓「設計裡的元件」和「程式碼裡的元件」保持同步，也就是同時維護「兩個單一真相來源」的一致性。設計端（多為 Figma）有元件與變體（variants），工程端（多為 React、Vue、Web Components）有對應的程式元件。理想狀態是：設計師改了按鈕的內距，工程端能透過共用的代幣自動吃到變更；工程端新增了 loading 狀態，設計庫也該補上對應變體。實務上這條同步線很容易斷——Figma 改了顏色但程式碼沒更新、工程師偷偷 hardcode 了一個新樣式。解法有幾種：用代幣當作兩端共同的底層（Tokens Studio、Style Dictionary 這類工具把 Figma 變數輸出成程式碼變數）、用 Storybook 當作「程式元件的活文件」讓設計師直接看到真實渲染、以及用命名一致的元件對應表讓兩邊對得起來。關鍵心法是：不要讓 Figma 和程式碼各自為政，而是讓它們共用更底層的真相（代幣），這樣同步的就不只是像素，而是決策。
可及性（無障礙）與一致性最好的策略，是把它們「做進元件裡」，而不是事後補。當一個 <Button> 元件在系統層級就內建了正確的鍵盤焦點樣式、足夠的觸控目標尺寸、aria 屬性、以及通過 WCAG 對比檢查的顏色代幣，那麼每個用它的人都自動繼承這些好處，不需要每次記得。反過來，如果無障礙靠每個工程師「自己記得加 alt、記得補 label」，那漏掉只是時間問題。這正是設計系統最被低估的複利：你把難的、容易忘的事情解決一次，封裝進元件，往後成百上千次的使用都免費受惠。一致性同理——當日期選擇器、表單錯誤、對話框關閉行為在系統裡只有一種標準實作，使用者在整個產品裡學一次就會用，介面的「可預測性」本身就是一種體貼。
文件與治理決定一個設計系統能活多久，也是最容易被忽略的一環。技術問題（怎麼寫元件）通常好解，難的是人的問題：誰維護？新元件由誰核准進庫？某個團隊需要一個庫裡沒有的元件時，是自己做（分叉風險）還是提案貢獻（流程摩擦）？好的治理會回答這些：明確的維護者或核心團隊、清楚的貢獻流程（提案、審核、合併）、語意化版本控管（讓使用者知道這次更新會不會破壞相容）、以及淘汰機制（標記 deprecated、給遷移期）。沒有治理，最典型的病是「元件氾濫」——同一種按鈕出現七個版本，沒人敢刪，也沒人知道哪個是對的。治理不是官僚，而是防止系統退化成一堆互相矛盾的殘骸。可以把它想成園丁：不只種下元件，還要持續修剪、除草、汰換。
看幾個成熟的公開設計系統，能快速校準什麼叫「做到位」。Google 的 Material Design 是規模最大、文件最完整的其中之一，把代幣、動態顏色、無障礙、程式碼實作都串起來。Apple 的 Human Interface Guidelines（HIG）偏重原則與平台一致性，講「為什麼」多於給你現成元件。Atlassian Design System 以清楚的貢獻與治理著稱，適合觀摩大型團隊怎麼協作。IBM 的 Carbon 是開源、以代幣為核心的典範，能看到三階代幣架構的真實落地。Shopify 的 Polaris 專為商務後台場景打磨，示範了設計系統如何服務特定產品情境而非泛泛通用。這些不是拿來照抄，而是拿來偷師：看它們怎麼組織文件、怎麼命名代幣、怎麼寫使用時機（do / don’t）。
2025 到 2026 年最實質的變化，是設計代幣從「各家自訂格式」邁向「產業標準」。W3C 的設計代幣社群小組（DTCG）在 2025 年 10 月 28 日發布了第一個穩定版本（2025.10）的 Design Tokens Format Module，背後有 Adobe、Google、Microsoft、Meta、Figma、Salesforce、Shopify 等二十多個組織背書。這件事的意義在於：當代幣格式變成一個「無聊到大家都遵守」的標準，工具之間就能互通，設計端與工程端的橋接不再各自造輪子。同期的趨勢還有兩條值得盯：一是設計與程式碼的橋接工具愈發成熟（Style Dictionary、Tokens Studio 把 Figma 變數直接輸出成多平台程式碼），二是 AI 輔助元件生成崛起——當 AI 要幫你生一個按鈕，它需要一份可靠的「詞彙表」才能生對，而代幣正好是設計、工程、品牌與 AI 工具共用的那份契約。有調查顯示代幣採用率一年內從約 56% 跳到 84%，這不是巧合，而是 AI 寫程式的爆發把代幣從「加分項」推成了「必需品」。
🧠 記
- 設計系統 = 設計 + 程式碼 + 文件 + 人；不是素材包，是持續產出一致產品的活系統。
- 名詞分辨：UI Kit 給零件、Style Guide 給外觀規範、Pattern Library 給解法、設計系統把三者接上真實產品並治理。
- Atomic Design 五層：原子 → 分子 → 組織 → 模板 → 頁面，逼你由小到大、可複用地思考。
- Design Tokens 是單一真相來源，三階最實用：原始（調色盤）→ 語意（用途）→ 元件（綁定）；切主題只改語意層，跨平台輸出同一份。
- 設計庫 ↔ 程式庫的同步，靠共用更底層的代幣，而非只對齊像素。
- 無障礙與一致性要「做進元件」，解一次、複利受惠成千上萬次。
- 沒治理就會元件氾濫；要有維護者、貢獻流程、語意化版本、淘汰機制。
- 2025.10 W3C DTCG 第一個穩定版落地，代幣成為設計、工程與 AI 的共同契約。
✍️ 實踐
- 盤點你手上任一產品，數數看「按鈕」到底有幾種視覺變體。若超過三種你講不出理由，你就有元件氾濫問題——這是導入設計系統最好的起點證據。
- 挑一個小元件（例如按鈕），把它的硬編碼數值抽成代幣。至少定義背景色、文字色、內距、圓角四個，命名用語意（
button.bg而非blue），並試著讓深色模式只靠改語意層就切換。 - 拿一個現有畫面，用 Atomic Design 由下往上標註：圈出原子、框出分子、標出組織。你會馬上看到哪些區塊其實在重複、可以合併成一個元件。
- 打開 IBM Carbon 或 Material Design 的官網，找它們的「代幣」與「元件使用時機（do / don’t）」頁面，觀察它們怎麼命名、怎麼寫該用不該用。挑三條你能直接搬進自己專案的規則。
- 幫你團隊的元件庫寫一頁最小治理文件：誰維護、新元件怎麼提案、版本怎麼標、舊元件怎麼淘汰。哪怕只有半頁，也勝過完全沒有。
🔗 延伸學習
- Atomic Design（Brad Frost 全書線上版） — Atomic Design 的原始出處，五層方法論講得最清楚。
- Material Design — Google 的旗艦設計系統，看代幣、動態顏色與無障礙如何整合。
- W3C Design Tokens Community Group — 代幣格式標準的官方來源，2025.10 首個穩定版就在這裡。
- Nielsen Norman Group：Design Systems 101 — 用研與可用性視角把設計系統的定義與價值講白。
- IBM Carbon Design System — 開源、以代幣為核心的落地典範，適合偷師三階代幣架構。
💬 問 AI
我正在為一個 [產品類型，例如 SaaS 後台 / 電商 App] 建立設計系統，目前團隊有 [人數 / 設計與工程比例]。
請幫我：
1. 用 Atomic Design 的角度，列出我最該優先建立的 5～8 個基礎元件，並說明理由。
2. 為「按鈕」這個元件設計一份三階 design tokens（原始 / 語意 / 元件），包含亮色與深色模式，用具體命名與範例數值呈現。
3. 指出我在 Figma 元件與程式碼元件同步上最可能踩的 3 個坑，以及對應的預防做法。
4. 給我一份最小可行的治理清單（維護者、貢獻流程、版本、淘汰）。
請以繁體中文（台灣用語）回答，並在能舉例處給具體命名或數值。