SEE Conf 設計工程化三部曲！探索新環境下「產研協同模式」中的思考與實踐

本文為 SEE Conf 2022 設計場分享《設計工程化三部曲》，整理成稿。

《設計工程化三部曲》將和大家分享我們探索現代化產研協同模式 「C2D2C」 中的思考與實踐。我們將從單點效能、設計前端協作、全流程協同三個維度，層層遞進地介紹實際設計生產消費中多鏈路、多角色“信息流轉效率”的相關案例。

本次我們的主題是「設計工程化三部曲」，主要是想和大家分享我們在探索新環境下“產研協同模式”中的思考，以及通過設計工程化的方式，從點線面維度提升實際生產中多鏈路、多角色“信息流轉效率”的相關實踐。

在去年 SEE Conf 大會中，我們分享過 Ant Design 中早期的設計工程化實踐，如何讓設計體系背后隱形的設計規則可用而不可見。并很高興看到了在語雀/知乎上對該領域的后續探討。

今年的主題叫「設計工程化三部曲」，我們想和大家聊聊在設計工程化視角下新的產研協同模式。我們將從點、線、面的維度，來闡述我們對于提升實際生產中多鏈路、多角色的 “信息流轉效率”的思考。那這也分別對應了是當下、即將和未來，我們的探索方向。

點 | 設計工程化下的低漏損協同

階段一：C2D2C - Code to Design / Design to Code

首先讓我們從點出發，聊聊 C2D2C 能力實現設計研發的低漏損協同。

我們都知道，在現在的產品協作流程中，有設計師和前端工程師兩個相愛相殺的角色。設計前端的協作流程大致包含以下圖中5個環節：

首先把視角聚焦給設計師，設計師常見的工作內容包含 設計組件、使用組件、設計頁面、交付設計。讓我們進入「使用組件」來看下細節：我們會從 Sketch 的 symbol 庫中拖出一個組件，那下面是它的屬性面板，配置項非常混亂、難懂。

這個時候，設計師就會產生困惑：

• 這個組件有沒有設計規范？
• 我可以改成什么樣呢？

如果他沒法一下子找到這個問題的答案，同時他又覺得這個默認效果看起來不太滿意的話，那么大概率就會開始放飛自我，設計出來一個自己覺得很棒的樣式。然后交付給前端開發同學。

那再讓我們再來看看交付設計的環節，前端同學在網頁中查看設計稿時，也會產生困惑：

• 這個設計稿和我平時用的組件怎么不太一樣？
• 我是要自己寫一個，還是能基于組件配置項配出來嗎？

而當開發同學沒法一下子找到這個結果的答案時，那么大概率他就會開始重復造輪子，寫一個自己不會再維護和迭代的一次性組件。

所以，在使用組件和交付設計的兩個環節，都會存在較為嚴重的信息漏損，使得協同鏈路中的信息流轉不暢。

而這個根本原因，則是在實際的產里流程中，設計的工作與前端的工作事實上是在兩個完全割裂的環境中進行的：

• 設計側產出設計組件庫，以 sketch symbol 的形式，給到業務設計師進行消費；
• 開發側產出前端組件庫，以 npm 包的形式，給到業務前端消費；

不「同源」，是混亂之始，漏損之根。

C2D2C的閃念

這個問題怎么解？

眾所周知，在中后臺領域， Ant Design 的組件庫在前端研發中相當成熟，基礎設施非常完善。能極大程度地提升前端的研發效能。但是如此成熟好用的組件庫卻無法被設計師直接使用，實在遺憾。

就在某一個晚上，我們看著 Ant Design 官網文檔邊做設計邊寫代碼的時候，一個念頭突然涌現。這就是 C2D2C 的第一個閃念，那也是后續整個 C2D2C 的核心基石。

C2D：前端代碼轉設計稿

這個念頭背后，是一個亟待開墾的新領域，叫做「前端代碼轉設計稿」，當然，字面意思，簡稱為 C2D，這是我們解決同源問題的核心路徑。

那前端代碼到底該如何轉成設計稿？中間的流程環節到底是怎么樣的？當時的我其實一無所知。所幸的是，C2D的閃念不僅僅只有我們才有。在業界也有一些先行者，做了一些探索性的實踐。

React Sketch App 是由 airbnb 開源的一個前端模塊，它可以讓使用者通過寫代碼的方式來控制 sketch 中界面的渲染。只要通過修改代碼的方式，就可以非?？焖俚赝瓿稍O計稿的變更。他們用了一個很酷的說法，叫做 Painting with Code，簡單翻譯過來就是，「用寫代碼的方式做設計」

React Sketchapp 是第一個真正實現了 C2D 能力的實踐?？梢哉f是打開了 C2D 這個領域的大門。甚至 Ant Design 中也有一個 antd-sketchapp 參考了這個模式，在早期的 kitchen 中進行了測試。當然，它又有很明顯的局限性，最明顯的一點就是，設計師不會寫代碼。那從第一步就阻塞了所有流程。當然，還有第二個小問題，就是前端同學需要為設計師定制專門的組件庫。無法直接復用已有的代碼。而這，更是使得它無法推廣開來。

那看完這一個先行者，我們來看下一位 —— html-sketchapp。

html sketchapp 是將任何一個網頁轉成 sketch 的模塊。用戶通過命令行的方式，輸入一個網址，就可以拿到這個網站可編輯的 sketch 內容。因此它自稱為「網頁轉為 Sketch 通用方案」。

那作為通用方案，它可以實現任何前端代碼都能轉為設計稿。但它并沒有解決設計師如何使用的問題。它的使用流程過于晦澀，轉換后的設計稿無法拿來直接使用。還原細節也不夠精致。

總結一下，現在的C2D方案，都無法真正給到設計師可以直接消費的設計組件。都需要用「工程師」的方式來完成生成或轉換。這也是理想與現實的鴻溝。

究其根源，還是因為這樣的方案完全站在工程師的視角，沒有考慮設計師的使用訴求。而我們兼具設計與前端開發的雙重視角，站在設計與工程的十字路口，我們的探索思路與純工程師的視角完全不同。

在我們看來，讓 C2D 真正為設計師可用，還缺少一個核心的物件。那就是一個可視化面板。那這正需要 Kitchen 這個設計工具來承載。

在過去一年的探索中，我們從去年開始做了很多探索，例如網頁組件轉成sketch設計稿、前端組件轉sketch的symbol、可視化面板的形態探索等等。

那這就是我們探索后的成果， Kitchen C2D。它包含結合了 Kitchen 的組件面板，和 Ant Design 中的 C2D組件。

在 Kitchen 組件面板的每一個配置項背后，都對應了一個前端組件的API，例如操作意圖，就對應了 danger，類型對應了 type等等。而每一個 API，都一定會存在相應的API的類型，比如字符串、布爾值、枚舉值等等。而每一個類型，我們都可以用一個統一的屬性可視化配置器來承載。

隨著組件類型的增多，前端組件API數量也會增多。但任意一個前端組件的 API，都是基礎 API 類型的組合。而前端組件 API 的基礎類型只有七八個左右。只要我們完成這幾個基礎類型的可視化配置器，并提供類型的組合與切換能力，便能用有限個數的屬性配置器，承接所有前端組件的可視化配置。

所以利用這樣的思路，我們就可以用一套設計方案，實現所有 antd 組件的可視化配置面板。

根據我們的計劃，我們將在2022年中旬實現 Ant Design 組件庫初步的全覆蓋。

D2C：設計「意圖」 轉前端「代碼」

好的，回過來，我們再來看看這個屬性面板。不知道懂前端的同學有沒有發現。當我們的屬性面板完整記錄下來前端組件的 API 時，我們是不是就完全可以基于這幾個 API的屬性，直接生成前端代碼？

而這個又是我們的第二個關鍵領域，叫做設計稿轉前端代碼，簡稱為 D2C。

D2C在業界已經有很多實踐，但大部的代碼生成都是如下圖所示。在我們看來，現在的D2C，只做到了樣式的轉譯。但對于交互設計來說，真正重要的是設計意圖。比如為什么采用實色填充的按鈕，為什么采用無邊框的警告提示。

除了「美感」以外，設計更應該關注向用戶傳遞怎么樣的「設計意圖」。而單純的像素級樣式還原，最終生成的代碼始終是一次性代碼，缺少可維護性。

而下面這種代碼，才是前端工程師在日常代碼書寫中的代碼，它可以更加精準地表征設計意圖。

我們認為，真正的 D2C，不應該是「設計樣式」轉代碼，而是「設計意圖」轉代碼。樣式只是「皮」，而設計意圖才是「骨」。缺少了骨架的皮囊，一拉就散，一戳就破。

C2D 組件的價值，除了在設計階段為設計師提供配置項，提升設計效率以外，更重要的一點，則是還在于設計交付時提供幾乎零損耗的「設計意圖」。

只要在 Kitchen 中打開「D2C」面板（需要在設置中開啟「開發者模式」），選中 C2D 組件，該組件相關的代碼信息就會完整地展示出來。

如果你是用 Kitchen 的交付工具，在本地預覽時也可以查看到組件庫信息和組件代碼，進而幫助前端同學完美還原設計意圖。只要選中配置好的 C2D 組件，該組件相關的代碼信息就會完整地展示出來。

小結

再讓我們回過來看一下之前遇到的問題，信息漏損的兩大難題，我們分別使用 C2D 和 D2C 的兩種思路有效解決。

最后，用一張大圖來回顧整個第一趴的內容，那這就是我們在Kitchen中實現的 C2D2C 設計工程化。

線 | 同源讓設計中臺走出孤島

第二階段：ODS - Original Design System Workflow

中臺 孤島

現在讓我們引入真實業務場景。實際業務中，完全使用原始 Ant Design 業務只占據一部分，常常需要對系統進行定制，比如圓角、顏色等。

在設計工具中，一個覆蓋所有使用場景的按鈕，可能最多需要 1000 多個相關的狀態。 由此可見， 0-1 創建業務設計系統成本很高，做到完善難度更大，隨之而來的是產生大量 “換皮” 但在組件層面高重合度的影子系統。這將為業務設計團隊帶來極低 ROI 的重復建設和維護成本。

然而，業務發展迫在眉睫，視覺訴求百花齊放。于是設計系統一個接一個的涌現，甚至成為妝點業務和設計團隊門面的 “必需品”。

在我們內部的資產管理中心，目前服務了 200 多個設計系統，沉淀了近 20000 多個組件。

可以說，這是一個設計系統 Big-Bang 的時代。

但是如此繁榮的表象下，設計中臺卻逐漸變成一個只出不進的孤島。

實際業務中，就算改一個顏色和圓角，設計師都得從頭開始維護一套自己的設計組件，同時下游的前端也得基于 antd 組件庫二次開發，并很可能導致分叉，停留在一個早起的歷史版本，無法做到業務組件增量更新和沉淀回流。逐漸的中臺就變成了一座只出不進的“孤島”。

在理想狀態下，業務設計系統能夠持續的跟隨中臺版本升級，享受到中臺能力升級帶來的技術升級與體驗升級。但階段一的 C2D2C 其實并無法解決上游的生產者從 0 搭建業務系統的問題。

那我們該怎么辦？

走出「孤島」的最后一塊拼圖

C2D2C可以從根本上解決同源問題，但是并無法滿足業務設計師從 0 搭建業務系統的訴求，我們缺少了最后一塊拼圖。那就是 Design Token。

Token不是個新名詞。但是 它作為歷史的孤兒，設計師和前端的“假笑”鏈接，相信已經不需要再做描述，實際生產中的體驗大家應該深有體會，antd 幾千行的 less 配置文件，誰用誰知道，除了恐怖的數量級，關系不清、功能抽象度不夠的命名問題也寫滿了勸退。

Make Token Great Again

結合設計工程化相關探索，我們希望讓 Design Token 再次偉大。

其實不難發現，傳統的 Token 應用有這么幾方面的問題：

• 通用性與規范：如何保障寫出讓人看懂、甚至能讓機器看懂的 Token？
• 定義與維護：如何讓任何一名業務設計師都可以快速創建業務專屬的設計系統？
• 保障后續使用：如何保障在業務消費環節，可以保障 token 規范消費？

經過長時間的探索，我們定制出一套可計算可生長的 Token System。目前這套體系目前正在專利審核期，后續將會逐漸向外披露。

在這套 Token 體系上，我們將會建立基于 Ant Design 的通用主題編輯器，業務設計師能方便的通過可視化配置的方式，對 Ant Design 進行主題定制。

如圖所示，在 C2D2C 的產研鏈路中，設計師在資產平臺上通過主題配置工具，可以快速定義出自己業務域的設計資產，此時將自動生成并托管一份 Token 配置包，通過 C2D 的能力可以直接得到同源的設計資產和前端資產，告別從 0 起步，只需要聚焦于后續的增量更新。同時源于皮膚層的剝離，業務組件可以更方便的沉淀回流，保障健康生態；同時前端開發可以忽視樣式層面的反復構建，專注于功能邏輯，解決和設計職能重疊。

那我們解決了方便定制與維護的問題，但是如何保證 token 的后續使用呢？我們都知道，傳統 Token 另一個痛點是制定出來后很難在未來的設計研發中嚴格使用，意味的極高的成本，用過 Sketch Text Style 的設計師應該知道，找一個字體樣式如同大海撈針，Token 的角色也從提效變成了降效。因此人肉的規范是不可行的。

如何通過設計工程化的方式，讓這些復雜的 Token 可用而不可見，得益于約定式 Token，工具將可以在設計師交付環節將對應的數值替換成 Token，即使有漏網之魚，在前端研發環節也將通過 Lint 和智能提示的方式實現 Token 的便捷引入。

小結

以上便是我們在「源系統工作流」中的探索，這將是我們今年（2022）的重點攻堅方向，而相應的能力也會伴隨著 Ant Design 5.0 的升級一并對外。

面 | 分布式產研協同高速公路

第三階段：DCM - Distributed Collaboration Model

現代業務協作困局

在更加復雜的商業項目中，往往還存在更多的角色，設計除了與前端的協同外，我們還會有與產品的協同，與運營的協同，還有后端、測試、PM、法務合規等等角色。

例如在我們的內部業務中，一個關于業務狀態機的case，產品和運營一起協同維護了一張表，并要求設計側完全同步維護一份對應狀態機的設計稿，輸出給前端。

每次業務迭代，PD和運營又分別要對文檔做一次維護，設計再做一次維護，前端、后端再對應改一次。任何一次訂單狀態機的小小改動，都要從源頭開始瀑布式地往下輪動變更。

造成這樣多方角色的協作困局，根本原因在于瀑布式研發模式造成的職能錯配和重疊，多個工種之間的只能深度耦合，互相牽制，重疊的部分帶來了大量的重復勞動與溝通成本。

一站式 vs 分布式

在過去的經歷中，其實也有很多種嘗試，比如教 PD或運營同學 用Sketch、研發想開發出 PD、設計都能用的一站式 lowcode 平臺，但大家都懂的，這些嘗試的結果都一言難盡。

為什么呢？在現代的產研場景中，不同角色都有專屬的協作平臺，業務使用語雀維護產品文檔，設計師使用Sketch完成設計，前端使用代碼倉庫，這些平臺在各自的領域，針對各自領域提供了高效的工具和能力，做到了足夠的高效。但是這些高效的工具和能力針對另外一個領域可能就是巨大的阻礙。

因此我們不能在如此宏觀的協作層面寄希望于一站式的解決方案。

分布式產研協同高速公路

在我們看來，專業工作交給專業工具，讓用戶專注于自己的領域，分布式顯然是更敏捷的選擇。

一方面可控的學習成本可以讓用戶專注于自己的領域，PD 不需要去了解Sketch、低代碼平臺怎么用，而只需要專注與語雀上的產品文檔。另一方面，足夠靈活的接入成本，可以讓各個產物可以嵌入產研中的各種環節，如 PRD、設計稿、交付文檔、研發測試流程 。

但在實際的業務場景中，只有研發才能接觸到最終的產品源代碼。

所以，在分布式產研模式的理念下，我們需要一個信息連接器，來溝通多方角色，讓其可以直接溝通產品源碼。

因此，我們不造輪子，而是造一條連接多方角色的「產研高速公路」。

以常見的表格編輯為例，在我們構想的場景下：

• 產品：產品同學可以在語雀上上快速完成表格的初步繪制，例如我們會提供一鍵復制表格的功能，讓 PD 快速完成表格的初步設計；
• 設計：在產品完成表格字段的確認后，設計師可以在 Kitchen 中一鍵同步ADS 上的項目，并基于此配置項完成設計側的加工。并基于 C2D 置入到自己的設計稿中；
• 開發：當設計師完成表格的設計后，便可將配置導出給前端同學。此時前端同學只需將此表格快速關聯到后端接口，并綁定數據源，我們就會將表格的前端代碼自動生成出來。然后前端同學可以選擇采用自己習慣的方式，將代碼置入到研發的項目中。

小結

以上便是我們在「分布式協同模式」中的思考，在我們看來，這是指引設計工程化發展的關鍵思路。這樣的產品應該長什么樣，用戶具體該如何使用，我們目前也沒有一個明確的結論。但這也將在我們探索和前進的過程中，逐步得到答案。

總結

同源與無形

設計工程化是一條晦澀且未知的道路，但我們相信只要把握住兩個關鍵詞，就能讓我們的探索朝著正確的方向前行，這便是同源與無形。

最后，我們想用兩句話結束今天關于設計工程化相關的分享：

同源共流，尚可百花齊放
無形無印，方能變化萬千