做了幾年 UI 設計之後，我發現一個殘酷的事實：沒有設計系統的團隊，永遠在重複造輪子。

按鈕顏色這邊一個版本、那邊一個版本，間距到底是 8px 還是 12px 沒人記得清楚，工程師問你「這個灰是哪個灰」的時候，你也只能尷尬地說「就⋯⋯那個灰」。聽起來很熟悉對吧？

設計系統就是解決這些混亂的答案，而 Design Tokens 是設計系統的地基。今天這篇設計系統 Design Tokens 教學，我會從最基礎的概念講起，帶你走完整個建立流程。

什麼是 Design Tokens？為什麼你該在意

簡單來說，Design Tokens 就是把設計決策變成資料。

你決定品牌主色是 #3B82F6，按鈕圓角是 8px，內文字體大小是 16px——這些都是設計決策。傳統做法是寫在 Figma 的 Style 裡面，然後工程師再手動抄到 CSS。問題是什麼？只要有「手動」這兩個字，就一定會出錯。

Design Tokens 把這些值抽出來，用結構化的格式儲存（通常是 JSON），讓設計工具和程式碼可以共用同一份資料來源。改一個地方，所有平台同步更新。這就是所謂的 Single Source of Truth。

三層 Token 架構：Primitive → Semantic → Component

Token 不是隨便取名就好，業界公認最有效的做法是三層架構。老實說一開始我也覺得搞這麼多層很麻煩，但用過之後就回不去了。

第一層：Primitive Tokens（原始層）

就是最原始的值，不帶任何語義。純粹定義「我們有哪些值可以用」：

{
  "color": {
    "blue": {
      "50": { "$value": "#EFF6FF" },
      "100": { "$value": "#DBEAFE" },
      "500": { "$value": "#3B82F6" },
      "700": { "$value": "#1D4ED8" },
      "900": { "$value": "#1E3A8A" }
    },
    "gray": {
      "100": { "$value": "#F3F4F6" },
      "500": { "$value": "#6B7280" },
      "900": { "$value": "#111827" }
    }
  },
  "spacing": {
    "xs": { "$value": "4px" },
    "sm": { "$value": "8px" },
    "md": { "$value": "16px" },
    "lg": { "$value": "24px" },
    "xl": { "$value": "32px" }
  }
}

第二層：Semantic Tokens（語義層）

這層告訴你「這個值是拿來幹嘛的」，透過引用 Primitive Tokens 來賦予意義：

{
  "color": {
    "brand": {
      "primary": { "$value": "{color.blue.500}" },
      "secondary": { "$value": "{color.blue.700}" }
    },
    "text": {
      "default": { "$value": "{color.gray.900}" },
      "muted": { "$value": "{color.gray.500}" }
    },
    "bg": {
      "default": { "$value": "#FFFFFF" },
      "subtle": { "$value": "{color.gray.100}" }
    }
  }
}

為什麼這層很重要？因為有了語義層，切換 Dark Mode 就只需要把語義層的引用換一組，不用改任何元件。這招真的省超多事。

第三層：Component Tokens（元件層）

直接對應到具體元件的設計規格：

{
  "button": {
    "primary": {
      "bg": { "$value": "{color.brand.primary}" },
      "text": { "$value": "#FFFFFF" },
      "border-radius": { "$value": "{spacing.sm}" },
      "padding-x": { "$value": "{spacing.md}" },
      "padding-y": { "$value": "{spacing.sm}" }
    }
  }
}

這三層是一層引用一層的，改最底層的 Primitive，整條鏈上面的值全部跟著動。這就是 Design Tokens 真正強大的地方。

W3C DTCG 標準：別再自己發明格式了

以前每間公司的 Token 格式都長不一樣，非常混亂。好消息是 W3C 的 Design Tokens Community Group（DTCG）已經制定了標準格式。2026 年的新專案，我強烈建議直接用 DTCG 規範。

DTCG 的幾個核心概念：

用 $value 表示值（不是 value）
用 $type 宣告類型（color、dimension、fontFamily 等）
用 {} 語法做引用（alias）
支援 $description 加上說明文件

遵循標準的好處就是工具都支援，你用 Style Dictionary、Tokens Studio、甚至自己寫 parser 都不會有問題。

工具鏈：從 Figma 到程式碼的自動化流程

光有概念不夠，你需要一套可以跑起來的工具鏈。以下是我自己在用的流程，也是目前社群最主流的做法：

Step 1：在 Figma 定義 Tokens

Figma Variables 是 Figma 原生支援的 Token 功能，支援 Color、Number、String、Boolean 四種類型，而且可以建立 Collection 來分層管理。如果你想要更強大的功能，可以搭配 Tokens Studio 插件，它支援完整的 DTCG 格式和更多 Token 類型。

想學更多 Figma 的進階功能，推薦看看 Figma Auto Layout 教學，搭配 Design Tokens 使用會更順手。

Step 2：同步到 GitHub

Tokens Studio 可以直接連結 GitHub Repo，每次在 Figma 修改 Token，就會自動 push 一個 JSON 檔案到指定的 branch。設計師改完值，工程師那邊自動收到 PR，review 完就合併。不需要再開 Slack 問「這個顏色改了嗎」。

Step 3：用 Style Dictionary 產生程式碼

Style Dictionary 是 Amazon 開源的 Token 轉換工具。它把 JSON Token 檔案轉成各種格式：CSS Variables、SCSS、Swift、Kotlin⋯⋯你想得到的都有。

// style-dictionary.config.json
{
  "source": ["tokens/**/*.json"],
  "platforms": {
    "css": {
      "transformGroup": "css",
      "buildPath": "dist/css/",
      "files": [{
        "destination": "variables.css",
        "format": "css/variables"
      }]
    },
    "js": {
      "transformGroup": "js",
      "buildPath": "dist/js/",
      "files": [{
        "destination": "tokens.js",
        "format": "javascript/es6"
      }]
    }
  }
}

設定好之後，每次 JSON Token 更新就跑一次 build，程式碼自動產生。搭配 CI/CD，整個過程完全不需要人工介入。

如果你的設計系統最終要落地成網站，也可以參考 Figma Sites 教學：設計稿直接變網站，了解 Figma 如何直接輸出成品。

Token 命名規範：別小看名字的力量

Token 命名是最容易被忽略、但影響最大的事。命名爛了，三個月後你自己都看不懂。

幾個原則分享給你：

用 kebab-case：color-brand-primary，不要用 camelCase
語義優先：用 color-text-default 而不是 color-gray-900
結構一致：[category]-[property]-[variant]-[state]
避免用數字表示語義：font-size-body 比 font-size-16 好

舉個例子，一個好的命名結構：

/* 推薦 ✓ */
--color-bg-default
--color-bg-subtle
--color-bg-inverse
--color-text-default
--color-text-muted
--color-text-on-primary

/* 不推薦 ✗ */
--gray-100
--blue-text
--bg1
--bg2

元件規範：從 Token 到可用的 UI 元件

有了 Token，下一步就是用它們來建立元件規範。每個元件文件至少要包含：

使用的 Tokens：列出所有引用到的 Token 名稱
變體（Variants）：Primary、Secondary、Ghost 等
狀態（States）：Default、Hover、Active、Disabled、Focus
響應式規則：不同斷點下的行為
無障礙要求：對比度、鍵盤操作、ARIA 標籤

把這些寫清楚之後，工程師不用猜，設計師也不用一直回答問題。整個團隊的溝通成本會大幅降低。

2026 年設計系統趨勢：AI 與空間運算的新挑戰

最後聊聊趨勢。2026 年設計系統有兩個很明確的方向：

第一，AI 輔助 Token 生成。已經有工具可以根據品牌色自動展開整個色彩系統，產生語義 Token，甚至建議間距和字級的 scale。雖然不能完全取代設計師的判斷，但起碼能把 60% 的基礎工作自動化。

第二，AR/VR 空間 Token。隨著 Apple Vision Pro 和 Meta Quest 的普及，設計系統需要新增 spatial tokens——深度（z-depth）、光源方向、材質透明度、甚至手勢互動的範圍。這是全新的領域，目前還沒有標準，但如果你的產品有空間運算的需求，現在開始研究不嫌早。

總結：你的設計系統下一步

設計系統不是大公司的專利。就算只有兩三個人的小團隊，建一套基本的 Design Token 系統也能省下大量溝通和修改的時間。

我建議的起步順序：

先用 Figma Variables 把現有的顏色和間距整理成 Token
建立三層架構，至少做到 Primitive 和 Semantic 兩層
導入 Tokens Studio，連結 GitHub 做版本控制
設定 Style Dictionary，自動產生 CSS Variables
逐步補上元件規範文件

不用一步到位，先跑起來再慢慢優化。有系統的設計，永遠比沒系統的天才更可靠。

設計系統建立教學：Design Tokens 與元件規範完整指南