Design System 中的 Design Token

在過去的兩期周刊中，我們分別介紹了 Components 與 Pattern 的差別，同時也介紹了 Pattern 中非常重要的一個概念 - Perceptual Pattern（氣質模式）。

對於整個 Design System ，Components 和 Pattern 除了為產品開發效率、一致性、設計指導提供幫助之外，它還肩負著另一個重要使命：

通過它們來表達我們在 Design System 中創建的設計原則並參與到產品的建設中，從而為產品打造賦有情感的品牌認知。

我們在前面的 Principles 部分曾提到，設計規則創建與執行同樣都很重要。從目標達成的角度來說，我們期望參與產品的每一個角色都應該能記住這些原則，結合 Perceptual Pattern 「腦補」出這些界面展示在用戶面前的樣子。這也就需要我們有一套控制性強且拓展的方法來維繫產品的風格系統，也就是我們今天將要討論的 Design Token。

什麼是 Design Token

在真實的產品過程中，這個環節在開發過程中是完全斷掉的。我們通常看到的 style 代碼（如下）都是一些幾乎沒有體感的參數，難以腦補出它「裝飾」出的界面會是一個什麼樣子。如果產品複雜，時間一久想要全局迭代維護也會是件痛苦的事情。

但如果我們將這些參數封裝起來用語義化的方式來進行描述，整個界面的「畫面感」就會清晰很多。這些在系統中定義出的」font-size-level03」、」border-distinguish-background」 就是從不同思考邏輯出發定義出的 Design Token。

當然，文字的語義化功能是有限的，也只是 Design Token 最終的一個呈現。想要真正增強「畫面感」，讓大家能讀、能理解還需要我們在 Design System 中建立一整套對應的系統，並讓大家對它們有著清晰的記憶。這裡我們將繼續以 Salesforce 的 Lightning Design System 為例，來給大家進行 Design Token 的詳細分析。

Lightning Design System 的 Design Token

Token 原本的意思是令牌，在工程邏輯中用於用戶身份與伺服器端進行驗證操作。而在 Design System 的領域中，Design Token 的定義更像是設計變數。對設計變數名稱的合理定義可以讓屬性參數更容易理解，也更便於對產品風格的控制。

Salesforce 在文檔中也對他們的定義作出了一段解釋，簡單來說就是：

Design Token 是設計系統中的視覺設計原子。它們是一組有著統一命名規則的實體，用於存儲視覺設計部分的具體參數，比如 HEX 色值、間距、尺寸的像素等。使用它可以有幫助為 UI 開發工作維護一套具備可擴展性、一致性的視覺體系。

舉個例子，在背景色部分 Lightning 定義了（節選） notification、badge hover、error dark 等 token，並在建立樣式體系的過程中為其定義了具體的色值。於是在開發的過程中，大家所看到的將是更為語義化的描述。如果需要調整產品的整體風格，只要這套體系的搭建足夠的健壯，整個實施過程將變得更加的高效且安全。

Lightning 定義了一整套 Token，包含如下幾類屬性：

• Background Color
• Text Color
• Border Color
• Font
• Font Size
• Opacity
• Line Height
• Spacing
• Radius
• Sizing
• Shadow
• Time
• Media Query
• Z-index

這套規則的抽象的主線邏輯是元素中 Style 的屬性值加上少許的自有業務定製。這也是最安全的做法，畢竟這已經在 CSS 語法這個領域經過長久的驗證，比起你自己組合一套來做的穩定性和拓展性一定會更好。

我們再找兩個例子往深走一步，看看它每個屬性裡面是怎麼來定義和運作的。

Radius（圓角半徑）與 Shadow（陰影）

通常情況下，很多人會為每一種「卡片」進行完整的樣式設定。這種逐個處理的方式通常的結果就是隨著業務複雜度的增加會越變越多。

就像下圖一樣剛開始可能只需要一種卡片（card01），設計師在某個項目中想要做一些風格差異，於是出現了 card02、03。

接著隨著卡片在更多場景下的使用，右側這些不同尺寸、不同圓角的 card 就出現了。到最後沒人能夠搞清楚究竟有多少圓角矩形，也沒人知道究竟該如何使用。

回到 Token 的思路上來，無論是尺寸還是圓角半徑它們都是一個卡片眾多屬性之一，同時它可能也被使用到表格、圖片上。於是圓角半徑（Radius）作為一種通用屬性被提取了出來。

via: https://www.lightningdesignsystem.com/design-tokens/#category-radius

陰影部分也一樣，Lightning 為不同的業務場景定義了好多不同種狀態。比如 focus 在按鈕上的陰影、拖拽時陰影的變化、圖片的陰影。

via:https://www.lightningdesignsystem.com/design-tokens/#category-shadow

看到這裡大家可能會發現一個問題，Lightning 的層級定義方式似乎與我們常見的方式不同。我們經常看到的是類似下方（Carbon）這樣由小到大一級級遞增上來的。

而 Lightning 則是更多根據場景來進行定義，也就是我們前面看到的表格圓角、卡片圓角、按鈕圓角等。不過我相信它們也肯定是有按照層級定義的一套 guide，只不過是「藏」了起來。

對於 Salesforce 生態中的開發者們來說，他們更需要的是更直接的指導，確定某個場景下的組件具體的樣子。Lightning 這麼做也正是因為由於它們業務的自身特性而決定的，所以這裡我還是想再提一下。我們所看到的每一個 System 思路和工作方式可能都不一樣，因為它的主要目的是更有效的服務與業務。所以我們可以借鑒的思考方式，但無法全部照搬。

Design Token 的作用僅此而已？

答案顯然是否定的。PinDesign 早期在關於移動端設計方面給大家提出過一個「跨多終端設計統一」的概念，而 Design Token 在跨多端設計統一中則有著非常大的價值。

絕大多數的產品，我們可能都至少要考慮在 Web、iOS、Android 上的設計，每當要增加或更新功能的時候設計上多會有多倍的時間消耗。

但如果從一個系統的角度來考慮這顯然不是一件科學的事情。如果接下來產品要拓展到更多的端，設計的資源消耗則會更多，而且可控性也會越來越差。

這個時候我們就需要再次請出 Design Token 了。在跨多端的設計中它不僅僅是一個存儲樣式的變數，更是一套用於在各操作系統間進行「翻譯」的「口令」。

如果我們將產品當做一個「人」來看待，那麼 Design Token 則可以用來進行不同語言的翻譯。同樣都是 shadow，我們可以根據不同語言（系統）的要求去設定好翻譯過的內容（具體參數）。

只要產品的設計框架足夠健壯，我們在不同系統中所消耗的設計資源將會大幅降低，開發的效率和一致性也能得到更好的保障。更重要的是，設計師可以將更多的精力放在對產品的邏輯、流程設計上，而這也是設計師真正該做的事情。

以上是 Design System 系列的第五期的節選內容，在餘下的全文內容中（付費部分）我將重點關注動手部分，和大家聊聊如何為自己的產品創建 Design Token，以及在創建的過程中的重點關注。

加入 PinDesign 會員，獲取本期主題「Design System 中的 Design Token」的全文內容及本系列前三期周刊的贈送。

Design System 是 PinDesign 周刊的一個新系列，基於「Design Systems」這本書結構框架的讀書筆記和經驗總結。希望將自己的感受和經驗分享給大家，輔助大家的閱讀。

點擊領取 PinDesign 會員計劃 50 元優惠券

Design System 系列已更新：

5key：什麼是 Design Systemzhuanlan.zhihu.com5key：Design Systems 02 - 什麼是 Design Principleszhuanlan.zhihu.com5key：Components 與 Patterns 究竟有什麼區別zhuanlan.zhihu.com5key：你該為產品設計怎樣的氣質zhuanlan.zhihu.com5key：Design System 中的 Design Tokenzhuanlan.zhihu.com5key：Design Pattern 實例 - 用戶通知與中斷zhuanlan.zhihu.com5key：Design Pattern 組合實例 - 列表頁設計思考zhuanlan.zhihu.com

點擊下方鏈接，了解 PinDesign 會員計劃詳細信息：

PinDesign 互聯網產品設計周刊

推薦閱讀：