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，包含以下幾類屬性：

1. Background Color
2. Text Color
3. Border Color
4. Font
5. Font Size
6. Opacity
7. Line Height
8. Spacing
9. Radius
10. Sizing
11. Shadow
12. Time
13. Media Query
14. Z-index

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

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

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

一般狀況下，不少人會爲每一種「卡片」進行完整的樣式設定。這種逐個處理的方式一般的結果就是隨着業務複雜度的增長會越變越多。

就像下圖同樣剛開始可能只須要一種卡片（card01），設計師在某個項目中想要作一些風格差別，因而出現了 card0二、03。

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

via: www.lightningdesignsystem.com/design-toke…

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

via:www.lightningdesignsystem.com/design-toke…

看到這裏你們可能會發現一個問題，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 往期回顧：

1. 什麼是 Design System
2. 什麼是 Design Principles
3. Components 與 Patterns 究竟有什麼區別
4. 你該爲產品設計怎樣的氣質