design token 是什麼？Figma 建立與交付實作重點

Design Token 是什麼？先用一句話理解

Design Token 是可命名、可重用、可交付給工程使用的設計決策資料。例如按鈕主色不只是一組色碼，而是「主要行動按鈕背景色」這個決策，能在 Figma、設計系統與程式碼中共用。

如果團隊只記住 #2563EB，下一次品牌色調整時，每個畫面、元件與程式碼都要人工追。若改成 color.brand.primary 或 button.primary.background.default，團隊討論的就不再只是數值，而是用途與情境。

Design Token 不是單純的變數

變數可以存任何值，Design Token 則要承載設計決策。我的判斷是：如果一個值沒有明確用途、沒有命名規則、沒有被重複使用，它還只是暫存值，不算成熟的 token。

變數存數值，token 存設計決策

項目	只看變數	作為 Design Token
顏色	#1D4ED8	color.action.primary
字體大小	16px	font.size.body.md
間距	24px	space.section.md

最簡單的例子：color.brand.primary

color.brand.primary 可以代表品牌主色，值可能是 #2563EB。但真正重要的是它被用在哪裡：主按鈕、重點連結、選取狀態，還是品牌識別區塊。用途不同，命名就不應該混在一起。

名稱、值、用途三者要一起看

Token 名稱	值	用途
color.brand.primary	#2563EB	品牌主色
color.text.primary	#111827	主要文字
button.primary.background.default	{color.brand.primary}	主要按鈕預設背景

為什麼設計系統需要 Design Token？

設計系統需要 Design Token，是因為 token 能讓顏色、字體、間距、圓角與狀態樣式有共同語言，降低設計稿與前端程式碼不同步的維護成本。

設計系統不只是一份漂亮的元件庫。真正難維護的是長期一致性：同一種錯誤訊息在不同頁面有不同紅色、同一種卡片間距被寫成 20px、24px、28px，這些差異最後都會變成產品品質問題。延伸的設計系統觀念可參考 Design System 完整指南。

沒有 token 時，樣式會怎麼失控

問題	沒有 token	有 token
品牌色調整	逐頁搜尋色碼	更新來源 token 後同步
錯誤狀態	設計師各自選紅色	統一使用 color.feedback.error
前端交付	設計稿註記容易漏	工程可讀取結構化資料

有 token 後，設計與工程共用同一套語言

當設計師說「這裡用主要文字色」，工程師不需要猜是哪個黑色，而是對應到 color.text.primary。這種共同語言，比單純在交付文件貼色碼可靠得多。

什麼團隊最需要先導入 token

如果產品有多位設計師、多位前端工程師、跨平台介面、深色模式或品牌改版需求，就應該開始導入 Design Token。小團隊可以先從 color token 與 typography token 做起，不必一次建立完整系統。

Design Token 的常見類型：顏色、字體、間距、圓角與陰影

Design Token 可以描述顏色、字體、間距、圓角、陰影、邊框、透明度與介面狀態。不要只把 token 理解成 color token，因為介面一致性通常來自整套樣式規則。

Color Token

Color Token 管理品牌色、文字色、背景色、邊框色與狀態色。建議分開處理品牌色與用途色，例如 color.brand.primary 不應直接取代 color.text.link。

Typography Token

Typography Token 可包含字體家族、字重、字級、行高與字距。台灣產品常見問題是標題與內文看起來各自合理，但放進同一頁後層級混亂，這通常需要透過 font.size.heading.lg、font.lineheight.body.md 這類 token 修正。

Spacing / Radius / Shadow Token

Spacing Token 管理間距節奏，Radius Token 管理圓角，Shadow Token 管理陰影層級。這些 token 看起來細，但會直接影響介面是否穩定。若每張卡片都微調 1 到 2px，設計系統很快會失去一致性。

State Token：hover、focus、disabled、error

類型	範例 token	適用情境
Hover	button.primary.background.hover	滑鼠移入按鈕
Focus	color.focus.ring	鍵盤操作焦點
Disabled	color.action.disabled	不可操作狀態
Error	color.feedback.error	表單錯誤與警示

Design Token 的三層架構：constant、semantic、contextual

Design Token 可以分成 constant、semantic、contextual 三層。constant 保存底層值，semantic 描述用途，contextual 描述元件或特定情境，這樣命名才不會越長越亂。

Constant Token：保存底層值

Constant Token 負責保存原始設計值，例如色階、尺寸階層、字級階層。它比較接近設計材料，不建議直接大量用在產品畫面上。

例：color.blue.500

color.blue.500 表示藍色色階中的某個值。它告訴你「這是一個藍色」，但沒有告訴你「這個藍色要用在哪裡」。

Semantic Token：描述用途

Semantic Token 描述用途，例如主要文字、次要背景、錯誤提示。實務上，semantic token 是大多數產品介面最該優先建立的一層。

例：color.text.primary

color.text.primary 可以在 light mode 對應深色文字，在 dark mode 對應淺色文字。名稱保持不變，實際值依模式切換，這就是 semantic token 的價值。

Contextual Token：描述元件或情境

Contextual Token 用在更具體的元件或情境，例如按鈕、輸入框、導覽列。我的建議是不要太早建立大量 component token，先等元件穩定且重複出現後再抽出來。

例：button.primary.background.default

button.primary.background.default 指向主要按鈕的預設背景。它可能引用 color.action.primary，而不是直接綁死某個色碼。

層級	命名範例	用途
Constant	color.blue.500	保存底層值
Semantic	color.text.primary	描述產品用途
Contextual	button.primary.background.default	描述元件情境

如何在 Figma 中實作 Design Token？

在 Figma 中實作 Design Token，可以用 Figma Variables 承載 token，先建立 Variable Collection，再用 Modes 管理主題，最後把 token 套用到元件與樣式上。

Figma Variables 是 Figma 用來管理可重用值的功能，可以承載顏色、數字、文字與布林值等設定。它很適合做 Figma design token 的設計端來源，但團隊仍要另外定義命名、版本與工程交付方式。Figma 入門操作可搭配 Figma 教學指南 一起看。

Step 1：盤點現有顏色、字體與間距

先從現有設計稿抓出重複出現的顏色、字級、間距與圓角。不要一開始就把所有數值 token 化，先找出真正重複、真正影響一致性的值。

Step 2：建立 Variable Collection

建議至少分成 Color、Typography、Spacing、Radius 等 Collection。若團隊還小，可以先從 Color 與 Spacing 開始，避免一開始管理成本過高。

Step 3：先做 base token，再做 semantic token

先建立 color.blue.500、space.400 這類 base token，再建立 color.text.primary、space.card.padding。產品畫面應優先使用 semantic token，避免直接綁死底層值。

color.blue.500
color.gray.900
color.text.primary
color.text.secondary
color.surface.default
button.primary.background.default

Step 4：把 token 套用到元件與樣式

Token 建好後，要回到按鈕、表單、卡片、導覽列等核心元件中套用。沒有套用到元件的 token，只是整理過的清單，不會真正改善協作。

Step 5：用 Modes 支援 light / dark mode

Modes 可以讓同一個 token 在不同模式下對應不同值。例如 color.surface.default 在 light mode 是白色，在 dark mode 是深灰色。這種做法比另外複製一整套深色版元件穩定。

Design Token 如何交付給工程？

Design Token 交付給工程時，通常會整理成 JSON、CSS variables 或平台樣式檔，讓設計決策成為可讀取、可轉換、可版本控制的 single source of truth。

工程交付的核心不是把 Figma 截圖丟給前端，而是讓 token 變成結構化資料。設計端、文件端與程式碼端必須知道同一個 token 的名稱、值、用途與變更紀錄。設計與開發流程也可延伸閱讀 從原型到製作的交付流程。

Single Source of Truth：誰才是 token 的來源？

團隊要先決定 token 的來源：是 Figma、Git repository、token 管理工具，還是設計系統網站。我的建議是不要讓 Figma 與程式碼各自維護一套同名 token，因為最麻煩的錯誤通常不是沒有文件，而是兩份文件都看起來像真的。

用 JSON 表達 token

{
  "color": {
    "text": {
      "primary": {
        "value": "#111827",
        "type": "color",
        "description": "主要文字顏色"
      }
    },
    "action": {
      "primary": {
        "value": "#2563EB",
        "type": "color",
        "description": "主要行動色"
      }
    }
  }
}

轉成 CSS variables 給前端使用

:root {
  --color-text-primary: #111827;
  --color-action-primary: #2563EB;
  --space-card-padding: 24px;
}
.button-primary {
color: var(—color-text-primary);
background: var(—color-action-primary);
}

跨平台輸出：Web、iOS、Android

同一份 Design Token 可以轉成 Web 的 CSS variables，也可以轉成 iOS 與 Android 可用的樣式資料。這裡不需要一開始就建立完整工具鏈，但命名與資料結構要先想清楚，否則跨平台時會被迫重做。

從 hardcoded value 遷移到 Design Token 的流程

從 hardcoded value 遷移到 Design Token，應先盤點重複值，再合併相近樣式，建立 base 與 semantic 對應表，最後從核心元件導入並標記舊值。

Step 1：盤點重複樣式值

先找出產品中重複出現的色碼、字級、間距與圓角。設計稿與程式碼都要看，因為兩邊常常已經不同步。

Step 2：合併相近值，不要一開始全都 token 化

如果畫面上有 23px、24px、25px 三種卡片間距，通常不需要三個 token。先判斷是否能收斂成一個標準值，這比照單全收更重要。

Step 3：建立 base token 與 semantic token 對應表

用表格列出底層值與用途名稱，例如 color.gray.900 對應 color.text.primary。這張表是設計與工程溝通的核心文件。

Step 4：先從核心元件導入

優先處理按鈕、表單、卡片、導覽列這些高頻元件。核心元件穩定後，再擴展到低頻畫面，比一次改完整個產品可靠。

Step 5：標記舊值 deprecated

Deprecated 是指舊值不再建議使用，但可能暫時保留以維持既有畫面。要清楚標記替代 token，例如舊的 #1E40AF 改用 color.action.primary。

Step 6：驗證畫面一致性與可讀性

遷移後要檢查畫面是否保持可讀、狀態是否清楚、互動是否符合預期。尤其是表單錯誤、disabled 狀態與 focus ring，不能只看靜態畫面。

Design Token 的治理：什麼情況不該新增 token？

不是所有新樣式都應該新增 Design Token。一次性例外、尚未驗證的視覺微調、只服務單一頁面的值，通常應先留在元件或頁面層觀察。

不要為一次性例外新增 token

如果某個間距只出現在一個活動頁，且未來不會重用，就不適合立刻變成全域 token。token 一旦進入系統，就會增加命名、文件、測試與維護成本。

不要把品牌色直接當語意色使用

品牌色是品牌識別，語意色是介面用途。錯誤訊息、成功提示、連結、主要行動按鈕都可能需要不同語意，不應全部指向 color.brand.primary。

誰可以新增、修改、棄用 token

至少要有一個負責人審核 token 命名、用途與影響範圍。設計師可以提出需求，工程師可以檢查輸出格式，Design System Owner 或 PM 則要判斷是否符合產品長期方向。UI 與 UX 分工可參考 UI UX 設計指南。

版本控制與變更紀錄

每次修改 token 都要留下變更紀錄：改了什麼、為什麼改、會影響哪些元件、舊 token 是否棄用。沒有版本控制的 token 系統，最後會變成另一種手動同步負擔。

新增 token 前要問	判斷方式
是否會重複使用	至少會用在多個元件或多個情境
是否有明確用途	能用一句話說明用途
是否已有相近 token	先合併或調整既有 token
是否需要工程同步	會影響程式碼時必須記錄版本

Design Token 與 accessibility、dark mode、多品牌主題的關係

Design Token 能支援 accessibility、dark mode 與多品牌主題，關鍵是把用途與實際值分開，讓同一個 semantic token 在不同情境中對應不同樣式。

用語意 token 支援 dark mode

深色模式不應只是把白底黑字反轉。比較好的做法是保留 color.text.primary、color.surface.default 這些語意名稱，再用 Modes 指向不同值。

focus、error、disabled 不應只是顏色變淡

Accessibility 不是最後補一個提醒。focus ring 要讓鍵盤使用者看得出位置，error 狀態要能被辨識，disabled 狀態要降低強度但仍可理解。這些都應該有明確 token，而不是每個設計師自行調透明度。

多品牌主題為什麼需要 token 分層

多品牌產品若直接在元件裡寫品牌色，換品牌時會非常痛苦。用 constant、semantic、contextual 分層後，同一個按鈕元件可以依品牌主題切換底層值，元件本身不必重建。

場景	建議 token	判斷重點
Dark mode	color.surface.default	同名 token 對應不同模式值
Focus	color.focus.ring	鍵盤操作時清楚可見
Error	color.feedback.error	不只依賴顏色，也要搭配文字或圖示
Multi-brand	color.action.primary	用途固定，品牌值可切換

常見錯誤：Design Token 導入失敗通常卡在哪裡？

Design Token 導入失敗，常見原因是命名混亂、設計與工程不同步、過早建立大量 component token，以及缺少棄用機制。

命名太抽象，看不出用途

像 color.main、color.special 這類名稱很快會失效，因為它沒有描述用途。修正方式是改成 color.text.primary、color.action.primary、color.feedback.error。

設計 token 和工程 token 不同步

如果 Figma 裡的 color.action.primary 和程式碼裡的 --color-action-primary 指向不同值，團隊會失去信任。這比沒有 token 更麻煩，因為每個人都以為自己用的是標準值。

太早建立大量 component token

Component token 很有用，但太早建立會讓系統被早期元件形狀綁死。按鈕、輸入框、卡片穩定後再建立 contextual token，通常比一開始就大量命名更好。

沒有棄用機制

舊 token 如果不標記、不說明替代方案，就會繼續被使用。棄用機制至少要包含狀態、原因、替代 token 與預計移除時間。

錯誤	後果	修正方式
命名太抽象	設計師與工程師解讀不同	改用用途命名
兩邊不同步	設計稿與產品畫面不一致	建立單一來源與版本紀錄
過早元件化	token 數量快速膨脹	先穩定 semantic token
沒有棄用規則	舊樣式持續擴散	標記 deprecated 與替代值

Design Token 是什麼？

Design Token 是可命名、可重用的設計決策資料，例如 color.text.primary、font.size.body.md、space.card.padding。它可以讓設計稿、設計系統與程式碼使用同一套樣式語言。

Design Token 和 Figma Variables 是一樣的嗎？

不完全一樣。Figma Variables 是 Figma 中管理可重用值的功能，可以用來承載 Design Token；但 Design Token 是跨設計與工程的資料規則，不等於單一工具功能。

Design Token 和 CSS variables 有什麼不同？

CSS variables 是前端實作形式之一，例如 --color-text-primary。Design Token 則是上游來源資料，可以被轉換成 CSS variables、JSON 或不同平台使用的樣式檔。

Design Token 和 Design System 有什麼關係？

Design Token 是 design system 的底層樣式語言。元件、版型、互動狀態與文件規範，都可以建立在 token 上。沒有 token 的設計系統，常會變成只靠人工維護的一組元件截圖。延伸閱讀可看 UI Design System 指南。

Design Token 和 Atomic Design 有什麼不同？

Atomic Design 描述元件如何由小到大組成，例如 atoms、molecules、organisms。Design Token 描述的是顏色、字體、間距、狀態等視覺決策資料。兩者可以搭配使用，但解決的問題不同。

小團隊需要 Design Token 嗎？

小團隊不一定需要完整 token 系統，但可以先建立少量 color token、typography token 與 spacing token。如果產品只有單一頁面且樣式很少變動，先用清楚的 Figma Styles 也可以；一旦多人協作或產品線變多，就該開始 token 化。

Design Token 命名應該用顏色名稱還是用途？

底層 constant token 可以用顏色名稱，例如 color.blue.500；產品介面應使用用途命名，例如 color.text.primary、color.surface.default。用途命名比較能支援 dark mode、多品牌與後續維護。

Design Token 可以支援 dark mode 嗎？

可以。關鍵是讓同一個 semantic token 在不同 mode 對應不同值。例如 color.surface.default 在 light mode 是白色，在 dark mode 是深灰色，元件仍使用同一個 token 名稱。

Design Token 要怎麼交給工程師？

常見方式是整理成 JSON、CSS variables 或 token package，並提供 token 名稱、值、用途、版本與變更紀錄。工程師需要的不只是色碼，而是穩定、可追蹤、可轉換的來源資料。

什麼情況不該新增 Design Token？

一次性例外、尚未驗證的樣式、只為單一頁面微調的值，不應立刻新增 Design Token。新增前要確認它是否會重複使用、是否有明確用途、是否已有相近 token，以及是否需要工程同步。