昨天我們把間距與版面網格 token 化,把「留白多少」變成一組可複用的變數;今天要把這件事放大到整套設計語言——當顏色、字體、間距、圓角、陰影、動效全部都被系統化地命名、儲存、分發，並配上元件庫與使用規範時,你擁有的就不再是零散的樣式,而是一套設計系統(Design System)。設計系統是團隊規模化做設計與前端的基礎設施,它把「一次做對的決策」變成「所有人自動遵守的預設」,讓一致性不靠人盯、而靠制度。
📖 學
設計系統到底是什麼:不只是元件庫
很多人把設計系統等同於「一堆 UI 元件」,這是最常見的誤解。設計系統是四層東西的總和:設計 token(最底層的設計決策值)、元件庫(把 token 組裝成按鈕、輸入框、卡片等可複用單位)、規範與準則(什麼時候用哪個元件、為什麼、內容怎麼寫),以及文件與工具(讓所有人查得到、用得到、跟得上更新的入口)。
換句話說,元件庫只是設計系統的一個交付物。真正讓它成為「系統」的,是把設計決策沉澱成可共享的資產,並且用文件與治理讓這些資產能被正確、持續地使用。Nielsen Norman Group 對設計系統的定義是「一套完整的標準,用來管理設計規模化的過程,靠可複用的元件與模式達成一致性」——重點在「規模化」與「一致性」,而不只是「有元件」。
一個實用的判斷:如果你的元件庫只有 UI 檔案、卻沒有「什麼情況該用主要按鈕 vs 次要按鈕」的準則,沒有版本、沒有貢獻流程、沒有人維護,那它比較像元件倉庫,還不是設計系統。系統之所以是系統,是因為它有規則、有邊界、有生命週期。
Design Tokens 三層架構:primitive → semantic → component
Design token 是設計系統的「原子貨幣」,把一個設計決策(某個藍色、某段間距、某級字體)存成有名字的變數,讓設計工具與程式碼共用同一個真實來源。成熟的 token 架構通常分三層,這是今天最該記住的骨架:
第一層,Primitive / Global token(原始層)。 這是純粹的原料值,只描述「是什麼」,不描述「用在哪」。例如 color-blue-500 = #2563EB、space-4 = 16px、font-size-300 = 18px。這一層是一份調色盤與尺度表,數量大、語意中立,通常不直接給元件使用。
第二層,Semantic / Alias token(語意層)。 這一層描述「用途與意圖」,並且引用第一層的值。例如 color-action-primary = {color-blue-500}、color-text-danger = {color-red-600}、space-inset-md = {space-4}。語意層是設計系統最有價值的一層,因為它把「意圖」和「數值」解耦:當品牌色從藍改成綠,你只要把 color-action-primary 指到綠色,所有「主要動作」自動跟著變,不用逐一改元件。深色模式、多品牌、無障礙高對比主題,全都靠替換語意層的對應關係來達成。
第三層,Component token(元件層)。 最細的一層,綁定到特定元件的特定屬性,並引用語意層。例如 button-primary-background = {color-action-primary}、card-padding = {space-inset-md}。它讓個別元件可以在不破壞整體語意的前提下做局部微調,也讓元件的樣式來源一目了然。
這三層的關鍵價值是「單向引用」:元件層指向語意層,語意層指向原始層。改動集中在上游,下游自動更新;而 debug 時你可以順著引用鏈往回追,知道某個顏色究竟從哪來。2025 年 10 月,Design Tokens Community Group(W3C 社群組)發布了 token 格式規範的第一個穩定版本(2025.10),提供一份與工具無關、可在 Figma、程式碼與各平台之間交換 token 的標準格式——這代表 token 正從各家自訂走向產業共通標準,跨工具協作會越來越順。
原子設計(Atomic Design):元件如何層層組裝
如果說 token 是設計決策的組織法,那 Brad Frost 提出的**原子設計(Atomic Design)**就是 UI 元件的組織法,用化學做比喻,把介面拆成五個層級:
- Atoms(原子):最小、不可再分的元件,如按鈕、標籤、輸入框、圖示。
- Molecules(分子):幾個原子組成的小功能單位,如「輸入框 + 標籤 + 送出按鈕」組成的搜尋框。
- Organisms(組織):多個分子與原子構成的較完整區塊,如網站頂部導覽列(logo + 選單 + 搜尋 + 使用者選單)。
- Templates(模板):把組織排進版面骨架,定義頁面結構但先用假內容佔位。
- Pages(頁面):模板填入真實內容後的最終樣貌,也是驗證系統是否真的可用的地方。
原子設計的價值不在於嚴格分類每個元件屬於哪層(實務上常有灰色地帶),而在於它提供一套由小到大、可組合的心智模型:你不是一次設計一整個頁面,而是先設計可複用的小單位,再往上組裝。它和 token 三層架構是天生一對——token 供給「值」,原子設計供給「結構」,兩者結合就是可規模化的 UI 生產線。
單一真實來源與設計↔工程協作
設計系統要發揮價值,核心前提是單一真實來源(Single Source of Truth, SSOT):同一個設計決策只有一份權威定義,設計端和工程端都從它衍生,而不是各自維護一份、然後靠人力對齊。
現實中最痛的落差,是設計稿裡的顏色/間距和程式碼裡的數值對不上——設計師改了 Figma,工程師沒同步;或工程師微調了 CSS,設計稿還停在舊版。Design token 正是為了消弭這道落差而生:token 讓「設計語言」有了機器可讀、可版本控管的表示法。理想流程是設計端在工具裡定義 token,匯出成標準格式,再透過像 Style Dictionary 這類工具轉譯成各平台需要的產物(CSS 變數、iOS/Android 資源、JS 常數),工程端直接消費同一份來源。
這也重新定義了設計與工程的協作介面:過去交接的是「一張像素完美的圖」,現在交接的是「一組有名字、有語意、可訂閱更新的 token 與元件」。設計師負責維護語意層的意圖,工程師負責把它可靠地落地到各平台,雙方對著同一份契約工作。要做到這點,需要命名規範、匯出管線、以及一個雙方都認可的「誰能改什麼」的治理約定。
知名設計系統案例:各有側重的參考範本
看成熟的設計系統怎麼做,是最快的學習捷徑。四個常被引用的範本各有特色:
Material Design(Google) 是應用最廣的公開設計系統之一,最新的 Material 3(M3)強調動態色彩、大規模的 token 化與跨平台一致性,適合想理解「token 如何驅動主題與個人化」的人。
Apple Human Interface Guidelines(HIG) 走的是另一條路線:它更像「準則與哲學」而非現成元件庫,深入談清晰度、一致性、平台慣例與可及性,是理解「規範層」為何重要的最佳教材——它示範了設計系統不只是元件,更是一整套決策原則。
Shopify Polaris 是商家後台導向的系統,亮點在極其完整的內容準則:語氣、用字、甚至錯誤訊息怎麼寫都有明確規範,提醒我們設計系統應涵蓋文字內容,而非只有視覺。
IBM Carbon 是企業級、token 驅動的開源系統,支援 React、Angular、Vue、Svelte 與 Web Components,是框架無關與無障礙嚴謹度的標竿,也很適合學習資料視覺化元件的系統化做法。
觀察這四者你會發現:沒有一套「標準的設計系統長相」。它們的共同點不是元件清單,而是都具備清楚的 token、明確的準則、扎實的文件與可持續的治理。
治理、版本化與採用陷阱
設計系統最難的部分,往往不是建起來,而是讓它活下去且被真正採用。這需要治理(Governance)。
治理回答的是「誰能決定什麼、怎麼決定」:核心團隊維護什麼、產品團隊如何提出新元件或修改需求、貢獻的審核流程、廢棄(deprecation)如何宣告與過渡。沒有治理,設計系統要嘛僵化到沒人想用、要嘛失控到人人各改一套,一致性瓦解。
版本化則讓變更可控:設計系統是產品團隊依賴的依賴項,一個破壞性的 token 或元件 API 變動可能同時弄壞好幾個產品。因此成熟的系統採用語意化版本(SemVer 的概念:破壞性變更升 major、新增功能升 minor、修補升 patch),搭配變更日誌與遷移指引,讓下游能安全地跟上。
常見的採用陷阱要提前避開:其一,只建元件、不寫準則與文件——沒人知道何時用、怎麼用,元件很快被繞過。其二,沒有專責維護者,系統變成無人認領的孤兒,慢慢腐化。其三,一次想做到完美,鋪太大反而遲遲無法上線;更務實的做法是從最常用的 token 與少數高頻元件開始,隨真實需求增量擴充。其四,設計與工程各自為政,token 沒有共享來源,系統再漂亮也只是兩份平行的樣式。記住:設計系統是一個需要持續投資的產品,不是一次性的專案。
🧠 記
- 設計系統 = token + 元件庫 + 規範準則 + 文件治理 四者的總和;只有元件庫,還不算系統。
- Design token 三層:primitive(原始值)→ semantic(語意/用途)→ component(元件專屬),單向引用,改動集中上游、下游自動更新;語意層是解耦「意圖」與「數值」、支撐深色模式與多品牌的關鍵。
- 原子設計(atoms→molecules→organisms→templates→pages)提供由小到大、可組合的 UI 結構模型,與 token 三層(供給值)互補(供給結構)。
- 單一真實來源(SSOT) 是核心前提:設計端與工程端都從同一份 token 衍生,靠標準格式與轉譯管線消弭設計稿與程式碼的數值落差。
- 設計系統是需要治理、版本化與持續維護的產品;最常見的死因是只建元件不寫準則、沒有專責維護者、以及設計與工程沒有共享來源。
✍️ 實踐
- 把既有樣式盤點成三層 token 草稿:拿你手上一個專案,先列出所有用到的顏色與間距值(primitive),再為它們取語意名稱(如
color-action-primary、space-inset-md),最後標出哪些元件屬性該綁到哪個語意 token。光是這一輪盤點,通常就能揪出一堆重複與不一致。 - 為一個高頻元件寫「使用準則」:選按鈕或輸入框,寫下三件事——何時該用、何時不該用(附反例)、以及對應的內容/文案規範(例如錯誤訊息的語氣)。這一步讓你體會「元件」與「設計系統」的差距。
- 逛一套真實設計系統並拆解其結構:打開下方 Polaris 或 Carbon,刻意去找它的 token 頁、元件頁、內容準則頁與版本/變更日誌各在哪,對照今天四層模型,記下它做得好、你能借用的一個具體做法。
🔗 延伸學習
- Design Tokens Community Group(W3C 社群組官網) — token 標準格式的權威來源,2025.10 已發布第一個穩定版規範,理解跨工具 token 交換格式必看。
- Nielsen Norman Group:Design Systems 101 — 對設計系統定義、組成與價值最清楚的入門權威文章。
- Shopify Polaris — 內容準則做得極完整的公開設計系統,學「規範與文案」層次的最佳範本。
- IBM Carbon Design System — 企業級、token 驅動、框架無關的開源系統,學無障礙與治理的標竿。
💬 問 AI
把你手上的專案樣式丟給 AI,請它幫你長出一份 token 三層架構草稿與治理建議:
我正在把一個現有專案整理成設計系統。以下是我目前用到的樣式值(顏色、間距、字級、圓角、陰影):
[貼上你的值,或截圖描述]
請幫我:
1. 把它們整理成 Design Token 三層架構(primitive / semantic / component),並用清楚的命名規範,說明每個語意 token 的用途;指出目前有哪些重複、不一致或缺漏的值。
2. 建議語意層要如何設計,才能同時支援淺色/深色模式與未來可能的多品牌。
3. 針對「按鈕」這個元件,示範它的 component token 該怎麼綁到語意層,並給我一份簡短的使用準則(何時用、何時不用、文案語氣)。
4. 給我一份最小可行(MVP)的導入順序:先做哪幾個 token 與元件,以及基本的版本化與治理該怎麼起步。