探索 Design Token
前言—
近幾年中臺化業務興起,各個業務團隊為了能快速響應業務需求,提升研發效能,引入「設計系統」來解決模組化和規模化的問題。
回顧一下什麼是設計系統,設計系統是由設計語言和模式庫構成,在設計原則的指導下,通過統一的協作語言和科學的管理方法組織起來,並建立體驗一致的使用者介面的系統。
-
設計語言:設計系統的基礎,與品牌識別和情感有關,包含顏色、字型、圖示等基礎設計原子; -
模式庫:一系列由設計原子組成的可複用的元件、模板等;
作為「設計系統」執行方的設計師與前端工程師,日常工作分別是在兩個差異化較大的工作流中進行的。常規流程是設計師在設計工具(Sketch、Figma)中完成頁面設計後,前端再參照繪製好的原型稿和標註稿,在程式碼環境中還原視覺稿 UI/UX。但在這個過程中時常會遇到以下問題:
-
前端如何高效的獲取上游設計的更新? -
視覺稿中可複用的設計系統原子,如何準確地傳達給下游? -
視覺還原工作還能提效嗎?
前端如何高效的獲取上游設計的更新?
設想這麼一個場景,在產研交付的過程中,設計師在視覺稿中做的每次修改,都希望能快速響應到最終的產品中,儘可能做到敏捷。而實際工作中,設計上游變更後會告知前端(存在少數變更不告知的情況),前端再開啟包含標註資訊的設計工具和程式碼編輯工具完成需求修改。在這個場景中,設計師會通過口頭或文字羅列視覺變更點,存在一定的溝通成本和資訊丟失問題。在最終產品交付上線前,還會經過一輪「設計走查」環節(敏捷開發中經常忽略的一環),可能又會產生新的設計上游變更,如此反覆。
視覺稿中可複用的設計系統原子,如何傳達給下游?
一個成熟的專案,往往會有自己的設計系統,設計原子作為系統中可複用程度較高的模組,已深度整合到設計工作流中。但由於設計和前端領域的概念不互通,導致可複用的資訊不能有效傳達。雖然設計師會整理包含字號層級,品牌色板,卡片陰影等資訊的設計規範檔案,但這些資訊往往不能在視覺交付稿中很好的展現。要理解視覺稿中的設計原子,前端需要了解設計工具中的概念,如 Sketch 的圖層樣式、Symbols,Figma 的 Variants 等等。設計師是最瞭解頁面樣式複用邏輯的,但真正實現頁面樣式的卻是前端工程師,這不可避免產生視覺還原誤差。
視覺還原工作還能提效嗎?
設計師在繪製好頁面視覺稿後,前端需要將視覺稿還原成可互動的頁面,按古早的分工,這裡需要三種角色參與,分別是視覺設計師、頁面重構工程師(負責 HTML + CSS 等 UI/UX 邏輯)和前端工程師(負責資料渲染等邏輯)。本質上,視覺還原就是將設計工具中的視覺稿描述轉換為 Web 能理解的資料描述,即 HTML + CSS。而這一塊的資訊轉換工作正是團隊近一年來嘗試攻克的點,團隊立項的「Deco 智慧程式碼專案」通過設計工具外掛從視覺稿原始資訊中提取結構化的資料描述(D2C Schema),然後結合規則系統、計算機視覺、智慧佈局、深度學習等技術對 D2C Schema 進行處理,轉換為佈局合理且語義化的 D2C Schema JSON 資料,最後再借助 DSL 解析器轉換為多端程式碼。
智慧程式碼解決了視覺還原工作整體的效能問題,但具體怎麼讓設計系統完美銜接研發工作流,降低設計研發協作成本,提升最終產出程式碼的可維護度,正是 DesignToken 可以發揮作用的地方。
什麼是 Design Token?—
Design Token
是一種以平臺無關的方式來表達設計決策的方法,以便在不同領域、工具和技術之間共享。在設計系統中的, Design Token
代表了構成視覺風格的,可複用的設計屬性,例如顏色、間距、字型大小等等。Token
被賦予一個特定的名稱(color.brand
),該名稱對應於某個設計決策定義的值(#3271FE
)。
但有別於設計變數(Design Variables), Design Token
是一個具有平臺無關性的抽象層,該抽象層的命名約定為設計屬性建立了一種通用語言,可支援跨應用,跨平臺,跨框架使用。
使用 Design Token
的工作流程圖如下所示:
Design Token 相關術語
按照 W3C Design Token 興趣組最新擬定的草案,裡面提到以下術語:
1. 令牌(Token)
與 Token
關聯的資訊,至少是一個鍵值對,如:
color-text-primary: #000000;
font-size-heading-level-1: 44px;
2. 設計工具(Design Tool)
Figma, Sketch, AdobeXD 等。
3. 翻譯工具(Translation Tool)
翻譯工具是將 Design Token 從一種格式轉換為另一種格式的工具,如:JSON to CSS
-
Theo [1], Salesforce -
Style Dictionary [2], by Amazon -
Diez [3], by Haiku -
Specify [4]
4. 分類(Type)
應用於 Token 的預定義分類,如設計系統中的樣式屬性分類:
-
Color -
Size -
Typeface -
Border Style 示例如下:
{
"color": {
"acid green": {
"value": "#00ff66"
},
"hot pink": {
"value": "#dd22cc"
}
},
"typeface": {
"primary": {
"value": "Comic Sans MS"
},
"secondary": {
"value": "Times New Roman"
}
}
}
5. 集合(Groups)
指代特定類別的 Tokens 集合,例如 Brand, Component 等等
{
"brand": {
"color": {
"acid green": {
"value": "#00ff66"
},
"hot pink": {
"value": "#dd22cc"
}
},
"typeface": {
"primary": {
"value": "Comic Sans MS"
},
"secondary": {
"value": "Times New Roman"
}
}
}
}
通過 Style Dictionary
翻譯工具,可將上述標記檔案轉換為以下 Sass 變數:
$brand-color-acid-green: #00ff66;
$brand-color-hot-pink: #dd22cc;
$brand-typeface-primary: 'Comic Sans MS';
$brand-typeface-secondary: 'Times New Roman';
6. 別名 / 引用(Alias / References)
Token 可以是別的 Tokens 的別名,而不是明確的值,這樣帶來的好處是:
-
有利於表達設計決策; -
消除重複的 Token Values;
7. 複合(Composite)
前面提到,Token 對應的值至少是一個鍵值對,也可以由多個鍵值對組成的複合型別。一個典型的例子是 Sketch 設計工具中的文字樣式和圖層樣式:
-
文字樣式:由表達文字樣式的字型名稱、文字粗細、顏色組合; -
圖層樣式:由邊框樣式、顏色、容器背景色和陰影組合;
Design Token 的優勢—
Design Token
作為設計規範在工程化中的承接方式,為設計系統的迭代、維護和落地提供了很大的幫助。另外 Design Token 在設計師和工程師之間起到了協議規範的作用,而 Token 正是這套協議中的編碼語言。
-
單一事實來源:設計和研發雙方如果嚴格按協議內容使用進行設計和編碼,是能夠讓設計系統擁有單一的事實來源,即最終的產品視覺呈現以上游設計師輸出的 Token 為準。同時也提供了一種用於記錄和跟蹤設計決策變更的儲存庫,也就是說上游設計師的視覺變更是可追溯的。 -
產品一致性:當使用 Tokens 進行設計和實現時,樣式變更可以更快地在整個產品套件中得到一致化的更新。 -
上下文驅動:由於 Tokens 是可複用,可自由組合的,因此它們可以根據上下文和主題進行區域性範圍內的更新。例如頁面背景色可根據系統主題進行顏色取值,如下圖:
Design Token 實踐—
在「Deco 智慧程式碼」專案中,研發可以給專案關聯特定的設計系統(DSM),如「京東 APP 設計系統」,其中包含文字樣式,圖層樣式,調色盤等設計原子。Deco 在做佈局樣式還原時,會優先使用設計系統中已有的 Design Tokens 並進行替換,並會標記設計系統中暫未錄入的設計變數,例如不在設計規範中的色值,字型大小等。
Design Token 的引入除了可以給佈局還原的程式碼做樣式精簡外,還能為視覺走查提供便利。因為 D2C(DesignToCode)的技術方案中,產出的程式碼視覺還原度可以達到將近 100%,設計師可以更多地關注自身視覺稿的設計系統覆蓋度,藉助上述流程中被標記的「設計變數」列表,可以十分方便的確認設計誤差,例如設計規範中規定的背景色為 $brand-color-bg: F7F7F7
,但程式碼還原後的背景色未被替換為 $brand-color-bg
,而是 #F6F6F6
。
總結—
Design Token 作為一種比較新型的設計決策表達方案,目前主流的設計工具如 Figma、Sketch、AdobeXD 已支援給設計屬性做變數標記或引用共享值,再借助第三方的翻譯工具如 Theo,將 Tokens 轉換為開發人員直接使用的特定平臺的程式碼。
雖說 Design Token 應用的並不廣泛,但隨著公司業務的擴張,必定會需要一套完善的設計系統,以一致的設計語言和視覺風格,幫助使用者形成連續、統一的體驗認知。到時候,Design Token 作為設計系統落地的承接方式,定會得到更廣泛的使用。Figma 將前端工程化的思想(如:Variants)帶入設計領域,我們未嘗不能繼續探索 Design Token 的可能性呢。
參考資料—
Theo: http://github.com/salesforce-ux/theo
[2]Style Dictionary: http://amzn.github.io/style-dictionary/#/
[3]Diez: http://diez.org/
[4]Specify: http://specifyapp.com/
[5]DTCG Glossary: http://www.designtokens.org/glossary/
[6]Material Design Tokens: http://m3.material.io/foundations/design-tokens/overview
[7]Building better products with a design token pipeline: http://uxdesign.cc/building-better-products-with-the-design-token-pipeline-faa86aa068e8
[8]A guide to design tokens: http://www.invisionapp.com/inside-design/design-tokens/
[9]本文分享自微信公眾號 - 凹凸實驗室(AOTULabs)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。
- Taro 3.5 beta 編譯提速,支援 Webpack5、React 18...
- 3D 沙盒遊戲之人物的點選行走移動
- 3D 沙盒遊戲之人物的點選行走移動
- 3D 沙盒遊戲之地面網格設計
- 3D 沙盒遊戲之地面網格設計
- 元宇宙探索之路
- 3D 沙盒遊戲之避障踩坑和實現之旅
- WebGL 的 Hello World
- 不懂物理的前端不是好的遊戲開發者(二)—— 物理引擎的學習之路
- Web3D 從入門到跑路 · 3D 初體驗
- Taro 在多端浪潮下的選擇與挑戰
- Taro 在多端浪潮下的選擇與挑戰
- Taro 3 與原生小程式混合開發實踐
- 聚類演算法在 D2C 佈局中的應用
- Taro 3 與原生小程式混合開發實踐
- Taro 正式釋出 3.4 版本: 全面支援 Preact & Vue 3.2
- 探索 Design Token
- 淺談智慧程式碼佈局演算法
- 低程式碼行業現狀簡析
- 探索 Design Token