DesignToken 是這兩年非常高頻出現的 B 端設計術語，主要應用于設計規范的交付和前端協作上，是 B 端設計師必須要掌握的基礎知識和概念之一，今天的分享來認識它的基本概念。

一、DesignToken 是什么

了解 DesignToken 就要先要了解 Token 是什么，它是一個開發術語，大多翻譯為 —— 令牌，是程序之間進行數據驗證和通信的相關編碼的統稱。

比如我們在一個應用中完成賬號的登錄，那么服務器就會返回給客戶端一串字符，每次你刷新頁面還是訪問其它模塊時服務器都會驗證這個串字符來確定你的身份。類似于我們進辦公樓前臺拿了一個臨時卡，你就可以用它穿行于樓內的不同區域，如果沒有這個臨時卡就只能被安檢拒之門外。

令牌這個翻譯用在開發場景中非常合適，但直接把 DesignToken 叫設計令牌的話是不太合理的，我更愿意把它稱為 —— 樣式標簽，原因下面就解釋。

在 HTML+CSS 的基礎知識中我們知道，要指定一個元素的樣式就要為它添加對應的 CSS 屬性和值。比如一級標題要設置成品牌紅，那么就要增加這段 CSS 代碼，

“ h1 { color : red } ”（h1 一級標題）

如果鏈接文本也要使用相同的顏色，就要添加相同的屬性和值。

“ a { color : red }”（ a 即鏈接文本）

這個邏輯很容易理解，大多數設計元素都包含顏色，要分別為它們添加顏色屬性并設置色值。這時你就會發現，同一個顏色，往往會應用到很多不同的元素上，比如上面的品牌紅色可以用在用戶名、提示信息、價格、關注按鈕等元素上。

剛開始設置的時候還好，但如果項目開發到一半或在后續的迭代中，品牌色從紅色變成藍色怎么辦？這就需要開發手動去把這些顏色找出來，然后改成新的色值，這種處理方式想想也復雜對不對。

而 DesignToken 的作用，就是在樣式和目標元素中間，再添加一層 “標簽”，用于統一管理。比如上面的品牌色，我們可以賦予它一個 Token 名叫 BrandColor（名字隨意起的不用糾結內容和格式），后續所有用到品牌色的屬性只需要添加這個名字即可，而不用填寫具體的色彩數值，比如標題 h1 修改后的做法如下：

h1 { Color: var( BrandColor ); }

通過定義一個語義化的標簽讓不同設計元素被引用，不僅提高代碼的可讀性和編寫效率，同時可以讓后續的批量修改變得更容易。只要修改它的色值，就可以批量修改所有關聯了這個標簽的元素的顏色。

這個邏輯對于有 UI 設計學習經驗的同學來說都很好理解，那就是在 UI 設計軟件中樣式定義。

通過定義一個樣式并命名，那么后續就可以批量調用和修改這個樣式，它們就是 DesignToken 的實際應用案例之一。

但 DesignToken 并不只是一個簡單樣式名、標簽，它還可以實現更復雜的操作與應用。

以主色舉例，雖然規范中定義主色只有一個，但并不代表在實際應用中它的色值就是“固定”的，還可能會產生各種變體，比如一個填充主色的按鈕，除了默認狀態還包括懸停、點擊、禁用等不同狀態，它們都需要通過顏色區分，所以要設置多個主色變體來應對這些場景。

同理，這些多出來的顏色，也要為它們設置對應的 Token 命名。而除了主色外，其它輔助用色也有同樣的使用需求，且顏色的使用場景不一定只是狀態切換，所以命名往往是在色彩后加數字的方式，比如下方 Arco 的主色和成功色命名案例（變量名）：

雖然到這里我們可以用 Token 定義整個項目的所有色彩了，但還沒結束，就是同一個色彩可以應用的對象很多，比如一個輔助色既可以用在文字，也能用在按鈕，還能用在日歷、選擇器、復選框中。

而多個顏色，且每個顏色應用到的對象是數十種時，開發的混亂就開始了。比如定義一個新的彈出窗口內的新標簽時，邊框應該用 Red1 還是 Green2 還是 Blue3？

前端實現設計稿的過程之一，就是實現成百上千的設計元素屬性和值的正確配對，設計師在可視化的設計軟件中操作很簡單，但前端工程師完全靠這些基礎 Token 命名做定義是很困難的。

于是騷操作就出現了，那就是對 Token 進行 “套娃”。即針對色彩更具體的應用場景進行定義，創建更細分更有可讀性的 Token 進行命名，然后關聯基礎的色彩 Token 為它們賦值。

比如一個登錄按鈕的背景色可以命名 Token 為 Login-Button-Bg，一個輸入框的邊框可以命名為 Form-Input-Border，它們可以使用上面定義過的 BrandColor 作為值，也就是用上同一個顏色，如下面案例：

Login-Button-Bg: var ( BrandColor-1 );

Form-Input-Border:var ( BrandColor-1 );

有了這樣的聯系，那么修改了 BrandColor 的顏色，關聯它的更下級的 Token，自然也會被修改。

而在這一步很多人無法理解的就是既然前端開發是組件化的，在組件定義過程中配置好基礎 Token 不就可以了，何必要再套一層，違背不樣套娃的祖訓？

恭喜你發現了華點。

對于部分的基礎的項目而言，在組件化開發過程中直接使用基礎 Token 完全沒有問題。而在一些復雜的項目中，同一類組件會包含大量的變體，這些變體同樣需要單獨設置屬性和值，這時候套娃的作用才能真正發揮出來。不理解這個邏輯沒關系，只要知道，套娃的層數不是越多越好即可。

如果使用了 B 端的開源框架，那么色彩 Token 就會額外疊加一層。因為 B 端開源框架制定過豐富的色卡，而顏色上面的英文，就是它對應的 Token。這些 Token 并沒有實際的意義，而項目中要定義品牌色、成功色的話，就需要用這些系統內置的 Token 進行賦值……

介紹到這里，我們全都圍著色彩轉，如果 DesignToken 只定義顏色，那不管怎么套娃都改變不了它雞肋的命運。

真正讓 DesignToken 發揮價值的地方，在于它還可以定義其它設計屬性。包括尺寸、字體、透明度、圓角、投影、模糊、動效等要素，即我們在設計規范中定義的大多數樣式內容。

通過這些 DesignToken 的定義和應用，就可以讓前端在開發過程中大幅度提升效率，以及提高頁面還原度和最終交付質量。

最后總結一遍，DesignToken 的應用就是以前端技術驅動的樣式開發工作流，通過對樣式參數添加可讀性更高的命名來提升開發效率。

二、DesignToken 的使用方法

了解了 DesignToken 是什么，那么接下來就要了解項目中應該如何制定 DesignToken，我們先從獨立設計和開發的項目說起。

DesignToken 是設計規范的延續，需要先完成 B 端設計規范，也就是在項目流程的規范定義和后續頁面設計之間展開。因為 DesignToken 必然會影響設計軟件內樣式定義的規則，所以越早確定越好。

DesignToken 可以覆蓋規范中的大多數樣式，所以首先要根據規范中整理的樣式做分類，比如下面這些：

每個項目的規范內容都有差異，所以除了色彩和字體外還包含什么內容是無法固定的，下面是不同設計規范制定的 DesignToken 類目：

然后我們就要定義 DesignToken 的基本命名標準，因為 DesignToken 本身是可以套娃的，所以每一層的命名形式都要做出區分，我們把 Token 簡單劃分成兩個層：

1. 基礎樣式層
2. 組件應用層

基礎樣式層就是上面提到的分類，它的命名形式可以用 "分類 - 場景 - 狀態" 這個模式來定義，而 Token 畢竟是代碼，所以只能用英文，不用考慮大小寫，用橫線來進行內容的分段。應用的案例如下：

基礎顏色 Token：

1. 品牌默認主色：color-brand-defult
2. 品牌主色懸浮：color-brand-hover
3. 錯誤顏色禁用：color-error-disabled

文字字號 Token：

1. 一級標題字號：fontsize-head-big
2. 一般正文字號：fontsize-text-defult
3. 醒目價格字號：fontsize-price-big

陰影等級 Token

1. 較低的陰影：shadow-low
2. 較高的陰影：shadow-high

這個命名的方法不是完全固定的，需要在團隊內部協商，尤其是需要讓相關前端開發人員檢查。除了命名的格式外，還包括一些英文用詞的統一。

接著需要創建出對應的表格，來記錄所有 Token 的明細，表格的屬性包括 Token 名、中文名、值、應用場景等，比如下面的色彩 Token 案例：

完成基礎樣式層的定義以后，就可以進行組件應用層的 Token 制定。但這一步，就不是由設計師來主導，而是讓前端工程師自己定了。

基礎樣式層的 Token，在設計軟件中就是樣式的命名，對設計過程有直接的影響，但是組件應用層，則完全作用于前端開發的使用場景，對設計師而言是毫無必要的。所以項目如果還需要定這一層，就要由前端工程師自己判斷使用的需要，制作一個新的 Token 列表出來。

而在組件應用層的 Token，則會使用新的命名規則，網上常見的做法就是類別+元素+屬性+等級+狀態，比如下面這個普及度最廣的案例：

光命名還不夠，同樣需要使用表格的方式進行記錄，而它和基礎樣式中唯一不同點，就是數值是基礎樣式的 Token 名而不是實際屬性值。比如下面案例：

相信你們立馬就能感覺出來這個命名實在是太復雜了，不是單詞寫的越多、越生僻效果就越好，而是沒有必要的情況下有經驗的前端是絕對不會使用這么復雜的命名，不僅編寫起來麻煩，而且可讀性也極差，只會反向降低自己的效率。

所以任何成熟項目的 DesignToken 命名，都是盡可能精簡命名的段數和單詞長度，提高利用率。只要明白這個道理即可，而不用盯著前端或自作主張做出看起來非常專業但實則臃腫雞肋的命名文檔。

具體可以參考成熟的案例，如 SEMI、TDesign 的 Toekn 命名規則：

1. https://semi.design/zh-CN/basic/tokens
2. https://github.com/Tencent/tdesign-common/blob/develop/style/web/theme/_light.less

掌握以上的認識，制定項目基礎規范的 DesignToken 就沒有問題了。但是，上一篇分享中提到的深色模式，就是在基礎規范之上制定一套額外的深色規范，同樣要被考慮進去。

而 DesignToken 實現深色模式的切換有兩種做法，一種是在 Token 命名中增加模式的前綴，比如 Arco 在深色模式添加了 Dark 的前綴用于區分。

還有一種做法，就是命名沒有任何變化，只是創建一個新的樣式表，替換里面的顏色，比如在 Semi Design 中的淺色和深色模式命名沒有區別，只是 HTML 會調用 Light 或者 Dark。

無論使用哪一種，都要記住在基礎規范中定義的所有 Token，在深色模式下都要羅列出來，即使它們已經合并成相同的顏色，這樣才便于維護。

不管 DesignToken 這個概念看起來多高效還是先進，都一定要充分結合實際情況展開實踐，再總結相關的經驗做優化。并且并不建議設計師投入太多的時間到這個部分的工作中去，因為常規項目的迭代很快，我們很難預知項目半年以后會長什么樣子，所以 DesignToken 的應用要把持靈活、高效、簡潔的核心價值觀。

下面是 Arco 和 Semi 的 Token 命名文檔案例，給大家作為參考：

結尾

以上就是 DesignToken 的認識和定義的全部知識點，至于如何結合設計軟件實現，如果看的人多，點贊轉發也多，就有空再更新。

我們下篇再賤~

歡迎關注作者的微信公眾號：「超人的電話亭」