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

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

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

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

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

點 | 設(shè)計工程化下的低漏損協(xié)同

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

首先讓我們從點出發(fā)，聊聊 C2D2C 能力實現(xiàn)設(shè)計研發(fā)的低漏損協(xié)同。

我們都知道，在現(xiàn)在的產(chǎn)品協(xié)作流程中，有設(shè)計師和前端工程師兩個相愛相殺的角色。設(shè)計前端的協(xié)作流程大致包含以下圖中5個環(huán)節(jié)：

首先把視角聚焦給設(shè)計師，設(shè)計師常見的工作內(nèi)容包含 設(shè)計組件、使用組件、設(shè)計頁面、交付設(shè)計。讓我們進(jìn)入「使用組件」來看下細(xì)節(jié)：我們會從 Sketch 的 symbol 庫中拖出一個組件，那下面是它的屬性面板，配置項非?；靵y、難懂。

這個時候，設(shè)計師就會產(chǎn)生困惑：

• 這個組件有沒有設(shè)計規(guī)范？
• 我可以改成什么樣呢？

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

那再讓我們再來看看交付設(shè)計的環(huán)節(jié)，前端同學(xué)在網(wǎng)頁中查看設(shè)計稿時，也會產(chǎn)生困惑：

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

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

所以，在使用組件和交付設(shè)計的兩個環(huán)節(jié)，都會存在較為嚴(yán)重的信息漏損，使得協(xié)同鏈路中的信息流轉(zhuǎn)不暢。

而這個根本原因，則是在實際的產(chǎn)里流程中，設(shè)計的工作與前端的工作事實上是在兩個完全割裂的環(huán)境中進(jìn)行的：

• 設(shè)計側(cè)產(chǎn)出設(shè)計組件庫，以 sketch symbol 的形式，給到業(yè)務(wù)設(shè)計師進(jìn)行消費；
• 開發(fā)側(cè)產(chǎn)出前端組件庫，以 npm 包的形式，給到業(yè)務(wù)前端消費；

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

C2D2C的閃念

這個問題怎么解？

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

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

C2D：前端代碼轉(zhuǎn)設(shè)計稿

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

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

React Sketch App 是由 airbnb 開源的一個前端模塊，它可以讓使用者通過寫代碼的方式來控制 sketch 中界面的渲染。只要通過修改代碼的方式，就可以非常快速地完成設(shè)計稿的變更。他們用了一個很酷的說法，叫做 Painting with Code，簡單翻譯過來就是，「用寫代碼的方式做設(shè)計」

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

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

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

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

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

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

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

在過去一年的探索中，我們從去年開始做了很多探索，例如網(wǎng)頁組件轉(zhuǎn)成sketch設(shè)計稿、前端組件轉(zhuǎn)sketch的symbol、可視化面板的形態(tài)探索等等。

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

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

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

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

根據(jù)我們的計劃，我們將在2022年中旬實現(xiàn) Ant Design 組件庫初步的全覆蓋。

D2C：設(shè)計「意圖」 轉(zhuǎn)前端「代碼」

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

而這個又是我們的第二個關(guān)鍵領(lǐng)域，叫做設(shè)計稿轉(zhuǎn)前端代碼，簡稱為 D2C。

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

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

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

我們認(rèn)為，真正的 D2C，不應(yīng)該是「設(shè)計樣式」轉(zhuǎn)代碼，而是「設(shè)計意圖」轉(zhuǎn)代碼。樣式只是「皮」，而設(shè)計意圖才是「骨」。缺少了骨架的皮囊，一拉就散，一戳就破。

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

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

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

小結(jié)

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

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

線 | 同源讓設(shè)計中臺走出孤島

第二階段：ODS - Original Design System Workflow

中臺 孤島

現(xiàn)在讓我們引入真實業(yè)務(wù)場景。實際業(yè)務(wù)中，完全使用原始 Ant Design 業(yè)務(wù)只占據(jù)一部分，常常需要對系統(tǒng)進(jìn)行定制，比如圓角、顏色等。

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

然而，業(yè)務(wù)發(fā)展迫在眉睫，視覺訴求百花齊放。于是設(shè)計系統(tǒng)一個接一個的涌現(xiàn)，甚至成為妝點業(yè)務(wù)和設(shè)計團隊門面的 “必需品”。

在我們內(nèi)部的資產(chǎn)管理中心，目前服務(wù)了 200 多個設(shè)計系統(tǒng)，沉淀了近 20000 多個組件。

可以說，這是一個設(shè)計系統(tǒng) Big-Bang 的時代。

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

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

在理想狀態(tài)下，業(yè)務(wù)設(shè)計系統(tǒng)能夠持續(xù)的跟隨中臺版本升級，享受到中臺能力升級帶來的技術(shù)升級與體驗升級。但階段一的 C2D2C 其實并無法解決上游的生產(chǎn)者從 0 搭建業(yè)務(wù)系統(tǒng)的問題。

那我們該怎么辦？

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

C2D2C可以從根本上解決同源問題，但是并無法滿足業(yè)務(wù)設(shè)計師從 0 搭建業(yè)務(wù)系統(tǒng)的訴求，我們?nèi)鄙倭俗詈笠粔K拼圖。那就是 Design Token。

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

Make Token Great Again

結(jié)合設(shè)計工程化相關(guān)探索，我們希望讓 Design Token 再次偉大。

其實不難發(fā)現(xiàn)，傳統(tǒng)的 Token 應(yīng)用有這么幾方面的問題：

• 通用性與規(guī)范：如何保障寫出讓人看懂、甚至能讓機器看懂的 Token？
• 定義與維護：如何讓任何一名業(yè)務(wù)設(shè)計師都可以快速創(chuàng)建業(yè)務(wù)專屬的設(shè)計系統(tǒng)？
• 保障后續(xù)使用：如何保障在業(yè)務(wù)消費環(huán)節(jié)，可以保障 token 規(guī)范消費？

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

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

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

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

如何通過設(shè)計工程化的方式，讓這些復(fù)雜的 Token 可用而不可見，得益于約定式 Token，工具將可以在設(shè)計師交付環(huán)節(jié)將對應(yīng)的數(shù)值替換成 Token，即使有漏網(wǎng)之魚，在前端研發(fā)環(huán)節(jié)也將通過 Lint 和智能提示的方式實現(xiàn) Token 的便捷引入。

小結(jié)

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

面 | 分布式產(chǎn)研協(xié)同高速公路

第三階段：DCM - Distributed Collaboration Model

現(xiàn)代業(yè)務(wù)協(xié)作困局

在更加復(fù)雜的商業(yè)項目中，往往還存在更多的角色，設(shè)計除了與前端的協(xié)同外，我們還會有與產(chǎn)品的協(xié)同，與運營的協(xié)同，還有后端、測試、PM、法務(wù)合規(guī)等等角色。

例如在我們的內(nèi)部業(yè)務(wù)中，一個關(guān)于業(yè)務(wù)狀態(tài)機的case，產(chǎn)品和運營一起協(xié)同維護了一張表，并要求設(shè)計側(cè)完全同步維護一份對應(yīng)狀態(tài)機的設(shè)計稿，輸出給前端。

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

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

一站式 vs 分布式

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

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

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

分布式產(chǎn)研協(xié)同高速公路

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

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

但在實際的業(yè)務(wù)場景中，只有研發(fā)才能接觸到最終的產(chǎn)品源代碼。

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

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

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

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

小結(jié)

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

總結(jié)

同源與無形

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

最后，我們想用兩句話結(jié)束今天關(guān)于設(shè)計工程化相關(guān)的分享：

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