近幾年圍繞業務中臺化的場景，湧現出了許多低代碼平臺。面對多組件、多頁面、跨平臺的複雜場景，如何保證整體的用戶體驗一致性，減少用戶認知和負擔，提升用戶使用效率，便成爲業務迫切需要解決的問題。本文從組件化角度聊聊設計工程化是如何解決模塊化與規模化的問題。
近幾年圍繞業務中臺化的場景，湧現出了許多低代碼平臺。面對多組件、多頁面、跨平臺的複雜場景，如何保證整體的用戶體驗一致性，減少用戶認知和負擔，提升用戶使用效率，便成爲業務迫切需要解決的問題。從傳統軟件工程的思路出發，組件化是解決複雜模塊的抽象、複用及統一的常用解決方案。那麼對於中臺設計來說，是否也能借鑑軟件工程學的思路來解決設計遇到的模塊化與規模化的問題呢？這便是近幾年設計工程化所討論並嘗試解決的問題。
設計工程化源於 2013 年 Brad Forst 提出的原子設計理論（Atomic Design），理論使用一種有條理創建模式庫的方法，結合軟件開發的組件化思想，從最原始的原子出發，逐層構築更高級別的組織，以解決設計模塊化的問題，這就是設計系統的前身。
設計系統
設計系統的定義
設計系統是由設計語言和模式庫構成，在設計原則的指導下，通過統一的協作語言和科學的管理方法組織起來，並創建體驗一致的用戶界面的系統。其目的是用於提高設計師和研發人員溝通效率，協作效率的實用工具，也能夠更爲客觀的反映用戶的需求。建立有效的設計系統，不僅能提高設計決策和協作的效率，也能減少系統出錯的可能性。
設計系統的優勢
- 溝通效率：以往由於雙方專業知識領域的差異而不好理解的概念，變得清晰了許多，例如在討論組件的視覺呈現和交互邏輯時，往往需要不少的溝通和反覆調整的成本，如今也因爲規則的約定而順暢了許多；
- 一致性：產品在跨項目、跨平臺的場景下，藉助設計系統約定的規則，使用一致的設計語言來避免產品快速迭代中，可能遇到的視覺，交互，體驗不一致問題；
- 文檔化：將設計語言、設計規則、模式庫文檔化，詳細說明組件的外觀，交互，適用場景等，可避免設計研發無根可循；
- 模塊化：組件化使用有限的規則來指導設計和研發，這樣可實現設計研發關注點分離；並且利用原子化設計理論，逐層構築模塊、模板、頁面等；
- 可維護性：原子化的應用增強了模塊的獨立性，使得設計和研發的迭代更新變得高效，當一個模塊需要更新時，使用這個模塊的更高階模塊也能夠同步更新；
- 協作效率：設計系統的引入解決了設計和研發兩種角色在產品迭代鏈路中，信息丟失和同步問題，大部分未遵循設計規則的組件模塊，能夠被及時發現並拋出；
設計系統存在的問題
自 Google 推出 Material Design 以來，各個大小公司的設計團隊都花費了大量時間整理併發布自家產品的設計規範。用百家齊放來形容並不爲過，並連續三年佔據設計領域的熱度榜。甚至有些規模不超過10人的小團隊，也都投身到設計系統的整理中，似乎變成了每個設計團隊的 KPI。
經過各個團隊的驗證，目前設計系統存在以下需要好好思考的問題：
- 整理耗時：定義所有的設計規則和約束，以及基礎和業務組件的整理，都需要經過大量的討論，不僅僅涉及設計團隊內部的溝通，也涉及各個業務線研發團隊的外部溝通。
- 維護成本：設計系統是需要不斷維護並迭代的，並非一勞永逸；
- 缺乏創造力：業務迭代受限於設計系統的規則和約束，創作的空間少了，但也帶來了產品體驗的一致性；
- 複雜度高：模塊化可降低系統的維護成本，但相反地會提高模塊之間的耦合度，使得產品創新性難以提升；
如果從長遠的角度看，一個好的設計系統不僅僅要能支持當前階段的設計和研發工作，也要能支持一個團隊的整體協同工作，更要能支持從規範本身出發，不斷地進行演進和創新。
設計工程化
設計系統的流行推動了設計工程化的發展，下面對設計工程化的討論主要分爲兩個部分：第一部分是以設計師視角出發的設計系統探索，第二部分是以工程師視角的設計系統落地實踐。
設計系統探索
以產品生產鏈路來看，設計稿作爲生產的上游輸入源，資源的生產方式和管理方式，直接影響下游（如：研發生產）的交付效率。設計系統的引入，對於設計師來說，必然得主導系統的落地運行，以保證設計資產的質量與流通順暢。
但設計系統的落地強依賴於生產工具的能力，傳統的 Photoshop，AI 等設計工具，缺乏資源管理維度的能力。在現代設計工具（如 Sketch，Figma）出現以前，設計系統往往需要藉助第三方平臺提供的插件，並按插件規範命名圖層，組織設計資源，才能生成設計系統文檔。設計規則和約束依舊無法很好的融入設計工作流，於是在 UI 設計工具領域出現了 Figma, Sketch 等新寵，嘗試將前端工程化的思想帶入設計領域。
設計師在完成樣式設計後，研發工程師需要按設備的尺寸，還原設計的排版佈局意圖。這造成了 UI/UX 和工程師之間的職能錯配和重疊問題，工程師似乎承擔了不少設計層面的實現任務。Figma 將組件化思想融入設計工具的同時，還引入了 Variants 等概念。讓組件的響應式設計任務迴歸設計師，由設計師把控組件交互的各個形態。同時也因爲顏色變量、文本樣式、圖層樣式等運用複用思想的特地引入，設計系統的運行與維護，設計資產的流通，也順利進入設計師的日常工作流中。
設計系統落地實踐
作爲「設計系統」執行方的設計師與前端工程師，日常工作分別是在兩個差異化較大的工作流中進行的。常規流程是設計師在設計工具（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 tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development. -- Jina Anne
用上述 Design Token 之母的一段話，我們可以這麼理解 Design Token。Design Token 是一種以平臺無關的方式來表達設計決策的方法，以便在不同領域、工具和技術之間共享。在設計系統中的，Design Token 代表了構成視覺風格的，可複用的設計屬性，例如顏色、間距、字體大小等等。Token 被賦予一個特定的名稱（color.brand），該名稱對應於某個設計決策定義的值（#3271FE）。
但有別於設計變量（Design Variables），Design Token 是一個具有平臺無關性的抽象層，該抽象層的命名約定爲設計屬性創建了一種通用語言，可支持跨應用，跨平臺，跨框架使用。
Design Token 的工作流程如下：
按照 W3C Design Token 興趣組最新擬定的草案，Design Token 主要涉及三個部分：
-
令牌（Token）
![]()
-
設計工具（Design Tool）
設計工具如 Figma、Sketch、AdobeXD 等，負責生產並維護設計系統中的 Tokens。
- 翻譯工具（Translation Tool）
翻譯工具是將 Design Token 從一種格式轉換爲另外一種格式的工具，如 JSON to CSS。
Design Token 實踐
在「Deco 智能代碼」項目中，研發可以給項目關聯特定的設計系統（DSM），如「京東 APP 設計系統」，其中包含文本樣式，圖層樣式，調色板等設計原子。Deco 在做佈局樣式還原時，會優先使用設計系統中已有的 Design Tokens 並進行替換，並會標記設計系統中暫未錄入的設計變量，例如不在設計規範中的色值，字體大小等。
Design Token 的引入除了可以給佈局還原的代碼做樣式精簡外，還能爲視覺走查提供便利。因爲 D2C（DesignToCode）的技術方案中，產出的代碼視覺還原度可以達到將近 100%，設計師可以更多地關注自身視覺稿的設計系統覆蓋度，藉助上述流程中被標記的「設計變量」列表，可以十分方便的確認設計誤差，例如設計規範中規定的背景色爲，但代碼還原後的背景色未被替換爲 $brand-color-bg，而是 #F6F6F6。
設計工程化理想方案構想
設計工程化解決的是規模化，效率化的問題。首先從角色分工上，按職責劃分任務，涉及視覺呈現層面（元素邊距，字體顏色大小等）的工作交由設計師負責，研發只負責業務邏輯的功能開發。而設計稿到產品的視覺還原功能，可結合 D2C（Design To Code）和 Design Tokens 來實現。D2C 負責頁面視覺和響應式設計的自動化還原工作，Design Tokens 負責把設計決策產生的設計因子整合到開發工作流，從而完成設計系統在設計和研發產研鏈路中的落地串聯。
通過上述方案，我們可以初步實現設計稿靜態頁面還原 + 響應式設計的工程化。即解決了 UI 到研發的鏈路打通問題。那對於設計系統中的交互邏輯的部分（即 UX），該如何實現工程化呢？
以往的組件交互邏輯，如按鈕的點擊交互，下拉菜單的展開動畫，大多是由設計師口頭或簡單地畫組件的分鏡狀態來跟研發進行協作的。缺乏交互規範，即使設計系統文檔中有明確的交互設計規則，研發之間也會存在實現方案的差異，無法保持交互統一性和可維護性。
Figma 給出的解決方案是在視覺稿中直接繪製組件交互原型，再借助 A2C （Animation To Code）插件轉換爲動畫描述文件（Animation JSON Schema），最終通過動畫解釋器（Animation Parser）完成 UX 鏈路的轉換工作。
以上便是現階段設計工程化落地的解決方案。
展望
設計工程化探討的不僅是產品設計系統的搭建過程，也是設計和研發兩種角色的分工轉變，及協作效率提升的過程。設計系統是一個具有包容性且充滿生命力的東西，包含從組件庫到設計語言的結構化體系以及應對不斷變化的創新迭代過程。Design Token 恰好是打通設計研發工作鏈路的一把鑰匙，但不應該只有一把。
好的設計系統可以在產品的一致性和品牌的創造性表達之間取得平衡，好的組件化思路也應該能最大化運用設計系統的價值。在未來，隨着技術的推陳出新，比如 AI 畫圖嘗試通過機器學習的方式生產藝術畫，設計工程化也會有更多可探索的方向。