設計師必讀！全面理解設計系統的秘密武器 Design token

Design Tokens 在設計系統中，扮演關鍵的角色，它們可以確保設計元素一致、提高協作效率以及簡化跨平台設計和開發之間的溝通。了解如何使用 Design Tokens，了解它們有不同類型以及命名方式，對於建立強大的設計系統來說至關重要。

一、Design Tokens 是什麼

Design tokens 其實是系統內對於重複性的視覺元素的「代稱」，我們給予不同顏色、字型、間距、圓角、等視覺元素，一個工程師和設計師都可以輕易理解的名稱，取代原先的靜態值（如：hex 色碼、數值），而這樣的名稱，可以在程式碼、設計、團隊溝通、平台保持一致性，同時保有擴充性。

二、為什麼需要 Design tokens

跨團隊、跨平台設計風格一致性：使用 Design Token 在設計開發中帶來了許多優點。首先，它確保了設計系統中使用的樣式值（例如顏色、字型、間距等）在不同平台和專案中保持一致，從而創造出統一的視覺風格，提升品牌識別度。同時，Design Token 可在不同專案和平台中應用，確保了跨領域和跨團隊的一致性，減少了不同部門間風格差異。

提升效率與溝通協作：透過使用有意義的名稱來表示設計元素，Design Token 讓團隊成員更容易理解和應用相關的樣式，從而減少誤解和溝通障礙，並促進更好的協作和溝通。

更新與管理便利：開發人員可以直接使用設計元素，從而減少重複的設計和開發工作，節省寶貴的時間和資源。同時，Design Token 讓所有樣式值都能夠集中管理，只需在一處進行修改即可同步應用到各個專案中，減少手動更改的煩惱。

具擴充性和降低風險：隨著產品的成長，Design Token 可輕鬆擴展和套用新的樣式需求，無需重新建立整個設計系統。同時，它支援不同主題或變體的樣式，從而應用於不同的使用情境，增加了客製化的彈性，並減少減少人為錯誤和不一致性。

容易測試與評估：使用 Design Token 讓測試不同樣式變化變得更為容易，同時也能更有效地測量和評估設計系統的效果，從而優化設計。

三、哪些元素可以設為 Design token

顏色、字體（字型、字級、字體粗細、字距、行高、大小寫、裝飾線、對齊）、間距、尺寸、邊角、陰影、邊框粗細、透明度、轉場效果等為常見的視覺元素，皆可以設為 Design token。

然而，在 Figma 當中，目前在 Styles 和 Variables 中支援顏色，Variables 中支援間距、尺寸、邊角，字體和陰影在 Styles 中支援。然而常見的透明度，以及字體底下各種可以分開設定的樣式，皆不支援。

四、Design tokens 階層

當我們在談論 Design tokens 的時候，依過去的經驗，大家沒意識到有不同階層層級，或是因階層的名稱過多，導致大家常常溝通有落差，雞同鴨講。Design token 常見的階層主要有三種階層，包含「 Global tokens」、「Alias tokens」、「Component token」。但是 Figma 官方用語，使用 Primitive tokens 指稱 Global tokens，用 Semantic tokens 指稱 Alias tokens。另外，不同系統有不同用語，例如 Android 則是使用 Reference tokens 和 System tokens。建議和不同平台的工程師合作時，可以使用該平台習慣用語。

第一層：Global tokens

別稱：Primitive tokens、Reference tokens、Core tokens、Root tokens、Base tokens、Basic tokens、Foundation tokens、Choice tokens、Option tokens、Meta tokens

例如：purple-400: #353288、radius-2x: 8px

:root {
–purple-400: #353288;
–radius-2x: 8px;
}

第二層：Alias tokens

別稱：Semantic tokens、System tokens、Application tokens、Purpose tokens、Decision tokens、Applied tokens

例如：background-primary: {purple-400}、radius-sm: {radius-2x}

:root {
–purple-400: #353288;
–radius-2x: 8px;

–background-primary: var(–purple-400);
–radius-sm: var(–radius-2x);
}

第三層：Component tokens （非必要）

別稱：Scoped tokens、Override tokens

例如：button-background-primary: {background-primary}、button-radius: {radius-sm}

:root {
–purple-400: #353288;
–radius-2x: 8px;

–background-primary: var(–purple-400);
–radius-sm: var(–radius-2x);

–button-background-primary: var(–background-primary);
–button-radius: var(–radius-sm)
}

另外，其實蠻多人兩階層，也有人使用一階層（有些直接使用 Semantic 或 component token 接原始數值，沒有參照階層），都是可以的。就是看公司產品規模，去決定你要用什麼 token，有些小公司單一產品，想要求快，就可以很單純，而大公司有各種產品線，複雜得多，就會需要比較多擴充性支援。個人建議，至少有兩層，且有參照，會比較有維護和擴充彈性。

使用 Component tokens 的優缺點？

究竟到底要不要使用 Component tokens 呢？以下列出幾項優缺點，大家可以在公司內部斟酌討論，再做決定。

👍 確保產出精準呈現設計原貌：設計系統旨在解決的最大問題之一是溝通落差、設計交接和設計轉化成代碼中的人為失誤，而 Component tokens 基本上就把所有該元件該套用的樣式，清楚表明在 design token 上，設計師和工程師的溝通會非常明確，減少人為套用錯誤的情形。例如：button-color-background-primary-hover，很明確。

👍 更新更有彈性：設計團隊能更有彈性隨著時間調整設計，而不會過度加重工程團隊的工作負擔，工程團隊不用因為要更新這個 token，然後因為這個影響整個原先架構，要再去一個一個更新架構內所有的 token。因為元件更改，可以僅更新 component tokens 即可。

👍 有助自動化提升效率：為了將設計系統工作流程自動化，Component tokens 可視為基礎。當我們完整建立機器可讀的 Component tokens，且包含每個元件屬性和狀態的不同組合，我們就可以拿來用來生成程式碼、進行自動測試，並且能夠檢查我們的程式庫是否正確使用了這些 token。簡單來說，這些 Component token 可以幫助電腦更快速、更聰明地處理一些設計和測試的工作，從而提高效率。

💀 過多細節過於繁複：Component tokens 為了精準呈現設計，所以常常會添加過多的細節，導致名稱過於冗長，整個系統變得龐大，不同的屬性、狀態等等，一堆的排列組合，增加設計師或工程師閱讀、學習和使用的負擔，超過人類認知負荷。

💀 軟體變得臃腫肥大：當我們在設計系統中使用大量的 component tokens 時，每個元件可能都有不同的屬性和狀態變化的排列組合，進而產生大量的 tokens。這些 tokens 到處座落於程式碼中，導致軟體套件的大小增加，且佔用過多系統的記憶體和運算資源，增加資源消耗，使系統運行變得緩慢或不穩定。

五、Design token 命名方式

Token 樣式

跟工程師溝通，挑選他們習慣使用的程式碼樣式即可。以下出分為三種常見樣式。

1. 蛇形式 (snake case、pothole case)：將每個單字以底線 (_) 分隔的命名風格。使用蛇形式時，所有字母都需要小寫。名稱易讀，適合用來建立檔案名稱，也成用來建立變數，常見於 Python。另外可以使用全大寫，稱作大底線式（screaming snake case）。snake_case_aka_pothole_case
SCREAMING_SNAKE_CASE

2. 串燒式 (kebab case)：將每個單字以連接線 (-) 分隔的命名風格。又可因大小寫，細分為小串燒式（spinal case、param case、Lisp case）、大串燒式（train case、cobol case），常見於 css 網頁語言和網址。kebab-case-aka-spinal-case-aka-param-case-aka-lisp-case
TRAIN-CASE-AKA-COBOL-CASE

3. 駝峰式 (camel case)：單字之間不以空格、底線、連接線格開，用大小寫變化去隔開單字。又可分為小駝峰式 (camel case、lower camel case)，第一個單字的首字母小寫，其餘單字首字母大寫。大駝峰式 (Pascal case、upper camel case)。所有單字首字母皆大寫。常見於 Java、Kotlin、JavaScript、 iOS Swift 程式碼中。lowerCamelCase
UpperCamelCaseAkaPascalCase

Token 命名原則

在設計系統中，為了確保設計師和工程師都能輕鬆地使用這些 Token，以下是幾項重要的命名原則。

簡短而有意義：使用清晰、簡潔的名稱來描述每個 Token 的屬性，讓設計師和工程師能夠迅速理解其含義。

容易理解：避免使用過於專業或抽象的術語，而是採用大家都能理解的常用詞彙，以確保 Token 的含義不會讓人感到困惑。

分類模組化：將 Token 分組並按照相關的主題或屬性進行命名，可以使整個命名結構更有組織性，同時也更容易尋找和應用特定的 Token。

保持一致性：在整個設計系統中使用統一的命名慣例，確保不同的 Token 能夠保持一致的風格和命名模式。這有助於避免混淆和錯誤，同時也提升了整個系統的協調性。

Token 命名架構

可以分成三大部分，大架構、主基石、細修飾。三個大分類底下還有細項，會再一一作說明，但請注意，但在做 design token 命名時，其實不會每一細項都使用到，這邊只是列出所有可能的架構順序。

大架構：命名空間基本上就是針對設計系統名稱、明暗或是其他品牌主題、哪種 Token 類型，去做標示。這個是最不用動腦的部分，而小公司，也多半不會用到這個部分，其實可以省略。

主基石：包含元件，例如：按鈕、文字輸入、單選、多選、分頁等等，但如果你沒有做 component token，這個可以省略。類別則包含顏色、字體、尺寸、間距、陰影等，概念包含資料視覺化、動作、回饋等，關於顏色的元素則是背景、填色、文字、框線，關於字體的元素就有大小、粗細、行高、字距等。

細修飾：角色包含主要、次要、再次要等，錯誤、警示、成功、中性、資訊等，或是其他跟資料視覺化底下有關的項目。變體可以再作進一步的細調，因為有些狀況，可能需要額外的樣式。狀態包含預設、滑鼠懸停、點擊、無作用等，這個會和元件共用，所以如果你沒有做 component token，這部分也是可以忽略。另外縮放，可能會用 1, 2, 3 或是 50, 100, 300，比較常用在 Global token，T-shirt size（如 extra-small, small, medium, largem extra-large）則有可能會用在 Alias token。

以下是一些排列組合的範例

Global token

color-purple-300
color-red-300

font-size-12
font-line-height-20

Alias token

font-headline-md = font-size-36 + font-line-height-44
font-body-lg = font-size-12 + font-line-height-20

color-feedback-text-warning = color-orange-300
color-feedback-background-warning = color-orange-800

color-dataviz-fill-equities = color-purple-300
color-action-text-error = color-red-300

Component token

button-radius = radius-md
button-color-background-primary-hover = color-purple-400
button-color-border-primary-hover = color-purple-500
button-text = font-body-md

總結

Design tokens 在設計系統中扮演著關鍵的角色，為設計師和工程師帶來了許多幫助。Design tokens 確保視覺風格的一致性、跨平台一致性，為產品帶來統一的視覺設計。使用 tokens 讓我們不僅能夠提升效率，降低繁雜的重複性工作，還能夠更輕鬆地管理和更新設計元素。同時，design tokens 的模組化特性使其具有高度的可擴充性，能夠輕鬆地應對產品的成長和變化。此外，design tokens 也有助於測試不同風格的變化，並更有效地評估整個設計系統的效果。最重要的是，使用有意義且易於理解的命名，確保了不同團隊成員能夠更輕鬆地理解和應用相關的設計元素，降低了人為錯誤和風險。總之，使用 Design Tokens 為設計系統的基礎，並在開發過程中，增進團隊協作和效率，確保了最終的實作成果與設計一致。

參考資料：

Component-level Design Tokens: are they worth it?
There are lots of resources for learning what design tokens are, how to use them, and their benefits to design systems…medium.com

Naming Tokens in Design Systems
Terms, Types, and Taxonomy to Describe Visual Stylemedium.com