成功建立有效的設計系統并持續維護已經是業內一個組織是否在創新文化方面成功/及格的標志。本文作者從自身工作經驗出發，結合實際案例，對設計系統的意義、具體設計方法和注意要點進行了總結，希望對你有用。

Design System是不可能一篇講完的，實際上根本不可能講完。因為design system相關技術、建設方法、對應要求等都在一直變化，各位看官容小弟在這里淺談一下算了。

一、什么是design system（設計系統）?

相信今天從事互聯網產品設計的朋友們聽說過，尤其是UI設計師、前端工程師。不過如果你打算舉手并交出你的sketch控件庫?，那么可能還是需要進修一下。成功建立有效的設計系統并持續維護之已經是業內一個組織是否在創新文化方面成功/及格的標志。在不同的產品屬性、生命周期導致的不同語境之下，設計系統的定義可以非常不一樣，我以能夠對產品團隊輸出實際價值的角度去定義設計系統的關鍵組成的話，它至少應該起到以下作用：

1. 對于統一的、不斷補充、豐富甚至修正的設計語言有完整的描述
2. 保證高質量產出的前提下，能夠為設計流程、代碼落地過程提速
3. 把設計樣式和代碼對應到一起的系統結構

二、制作design system的意義何在?

從2017年開始接觸并且在一家全球五百里面瞎弄過些（對~不止一個所以是“些”）設計系統。因為有吐槽嫌疑就不明言了，畢竟學習、試錯過程誰都可以有，個人也罷部門也罷公司也罷。之前在微軟也參與過Bing的new branding refresh，不過如果用現在的設計系統標準看，那僅僅是設計層面的設計語言總結、控件規范的那一部分，再強調一次，這些還不算是設計系統，去面試的時候別拿一套控件庫出來就瞎比比，專業領域里面有術語的變化肯定是有原因的，而且那個原因極少是“逼格更高”，認清這一點才算有了持續進步的門票。

相信很多團隊對于設計系統都經歷過因為“人有我有”的根本原因而發起過甚至建成了形形色色的設計系統，有個內容豐富的網站，滿滿的小字號文案、分門別類的控件庫、頁面模板以及不管用不用反正這里有的對應代碼。對了，還需要有個trendy的名字。

沒有實際意義的設計系統一般有特征如下：建立完成了之后，一直就歲月靜好地躺著，沒有更新；流量不大，展示時會被打開一下，但是鮮有設計師點開（可能剛到崗下載完控件庫文件就沒有然后），團隊里面的前端工程師更甚可能連網址都記不住。好了吐槽完畢，以下凈說好話。

其實設計系統的意義從一開始被提出概念時就已經非常明確。整體設計有所沉淀之后，設計樣式抽象出復用性、前端根據所用框架制作可復用（并真實被一直復用）代碼，達到省卻設計、前端重復用力，從最終落地效果去保證設計一致性。理論基礎是atomic design，出色例子有air BnB的馳名國內外設計系統、salesfoce的Lightning Design System，當然還有國粹Ant Design，這些你都知道了。

至于行業環境基礎，我自己的總結是任何一個在某垂直做大做精的產品，都會有許許多多類似但是又有那么丁丁點點的必要差異化需要照顧，參照一下中臺功能帶來的變革就是為了避免重復造輪糟蹋人力一樣，難道作為設計師/前端工程師的你真希望人力在無盡的歲月里頭，把精力耗在“改個字段”、“加個輸入框”之類的需求當中？你樂意養老，公司還不愿意養會用sketch的流水線工人。

所以致親愛的領導們，如果你的百人團隊做出來的產品，怎么老會出現類似同是一個確認鍵但是在這和在那總是有點什么不一樣，然后明明人已經那么多了還是天天要加班，設計師/前端工程師還天天黑眼圈臉泛黃一副欲求不滿的鬼樣，估計是設計系統沒有做好也沒有用起來。

設計系統真做起來了之后怎么辦？多出來的人力怎么辦，難道裁掉嗎？在這一步之前，還有很多讓員工如沐春風朝氣蓬勃并且對產品有大裨益的事可以做的，例如多出來的設計人力做用戶調研，前端技術日新月異隨時掌握了個降維打擊的新展現層技術讓你的產品鶴立雞群也不是沒可能。

但是設計系統不是一個解決了有和無就完事兒了的組織層面任務，如果不因地制宜去做肯定是無用功。我保證牢騷發到這一行字為止。

這幾年新的UI設計技術手段，我自己的總結都是在兩方面發展與用力：做出比真產品還要真（這是個笑話，當然）的prototype變得越來越容易；設計協同（設計師 與 設計師、設計師 與 開發工程師）越來越科學理性與流程化。而設計協同方面，各大工具作出的一個個努力（或者說一些讓你覺得一定要買買買的feature們）最終沉淀下來都必將指向一套真正有效的design system。不管你是否有意識而為之。

三、一個設計系統包含了什么

網上找來的絕世武功的目錄。所謂該有不該有都有了。每一個具體的話題你都可以無止境地深挖，而且每一個類別認真做的話都有無窮盡可以做的事。但是我們實際要做的結合自己產品、組織之中的實際需要，再參考別人的總表去規劃自己的設計系統邊界是什么。

規劃設計系統范圍的重點是：保持關鍵無贅肉。我始終認為判定一個設計系統成功與否的關鍵是，它是不是真的最終能夠成為設計師、前端的工作工具，是不是真的簡化了他們的工作流程，他們是不是真的喜歡用這個工具。

很多時候出于組織原因要去匯報，對標行業標桿設計系統的完整目錄去依葫蘆畫瓢無可厚非。但是除非真的像ant design那樣具有對外輸出企業價值的產品使命的話，真沒必要。

四、Design System可能牽涉到的工具

那我就獻丑也說說最近也許和建立設計系統有關的工具的理解。真的很不喜歡提及工具，因為太多設計師都是盲目的工具控了，喜歡不停去“知道”新工具而非真正把工具當成成就自己的手段，還會時不時在別人提起xxx新工具的時候跳出來說那個yyy也可以云云。

Any way。Abstract，用于管理設計文件的版本、并讓設計文件上云而馳名，但我最喜歡的還是shared libraries，至少設計層面內部真正統一了設計語言。嗯我知道藍湖也有這個功能，當時看到藍湖發布此功能也是佩服反應之快。如果會從零開始新項目的話我會嘗試用figma，雖然是browser based但是性能出色，還真正做到了高度協同（那個高度是至少十層樓高）而且前端工程師可以無縫接棒，真正映射了互聯網公司的設計流程而生的設計工具（某類）。

當然真正有用的設計系統還少不了像Stencil這種建立web element控件庫的工具，才算完整。還有一直關注謎一樣的終極殺器阿里出品Fusion Design。工具不重要，搞清楚需要什么工具才重要。不知道自己手頭的活兒意義何在就會落得連工具都可以牽著你鼻子走了。

五、規劃設計系統時需要考慮哪些點

1. 你的設計系統打算支持那些設計軟件?

Sketch、Figma、XD，估計再偏門一點的就難以在討論范圍內了。是的，除了sketch還有人在用別的工具的。理論上團隊已經在用的工具有哪幾個就要做那幾套的控件庫。但是不得不考慮成本與成效的問題，因為這里所說的成本并不是一次性成本，設計系統是需要維護的，每一次維護成本的倍數都是你今天選擇支持的軟件個數。

個人意見是：其實三者實際操作概念大同小異，轉換工具對于設計師個體成本不見得就十分大。而且買軟件公司也是要錢的啊，為什么不統一就用一個工具，然后為此而開發組件庫呢？Figma原生就是一個比較合適建立設計系統、團隊協同，習慣了的話基本就是一個跨團隊型的全流程工具。XD也是很強也許因為貴族基因吧，基本上每個月都有讓人驚喜的更新。Sketch就不用說了，但是在2020的今天，不靠插件強大不起來的它是不是顯得有點落后？

不是。請見what Sketch has planned for 2020。teams功能、字體優化、智能layout等等這些（雖然好像在XD早就見過了）明顯是不耐煩想出王炸了。雖然工具只是工具，但是我始終認為對于一個團隊甚至企業而言，工具映射了也引導著團隊工作方式進而影響著文化（TMD又出金句了），所以建議好好比較差異，選一個最合適你團隊的工具。這和統一度量衡是差不多偉大的事兒~

2. 應該支持什么代碼技術？

對于前端技術，我連略懂都算不上，不過這幾年因為需要推動事情落地也稍稍有了些認知。網頁端主流框架React、Angular、Vue，移動端主流框架Swift、Java和React Native，實際使用起來對于設計的妥協程度要求都差不多。最理想當然是建立能夠支持所有框架的控件代碼庫，但是同樣由于開發成本與持續維護成本，明顯這是不實在的。

最詭異的是在一些大團隊里面，可能前端框架都不只只有一款，導致設計系統沒有辦法統一，或者說導致到同時“存在”了不止一套設計系統。據我了解這其實也算是不少團隊的情況與歷史原因，即便是不少國內外大廠也是有過這樣的狀態，要不就一直這么茍且下去，要么還是咬咬牙同一個了框架與控件庫代碼。

由于面對過不少這一類的問題，之前也花過些時間研究過網頁端解決方案：運用像Stencil這樣的工具就可以建立支持絕大多數市面上的主流瀏覽器的Web components，兼容不同的現存框架，節省重復開發工作。

3. 利用好開源資源

從零開始建立一切是瑪麗蘇電視劇劇情，尤其是你如果同時還對設計系統里面每個元素的可用性有比較高的要求。加上無論組織大小，公司希望能夠盡快落地產品，團隊、部門希望在使用了有效資源的前提下盡快作出有效輸出。作為設計師的成長，一般都會有過糾結“我不想抄作業”的心情。但是理性應用現成資源、著力于差異點，平衡成本與產出，這些才是走向專業的標志。

如果你和以前的我一樣對吃現有點排斥的內心戲，我建議好好平常心仔細學習一下吃現者最愛的Ant Design，尤其在新版（現在是4.x）的補充下很多里面的設計思路，雖然滿滿的通用性導向設計，但是邏輯、實施層面的周密與整全，儼然就是企業系統交互設計的教科書了。

另外同樣具有教育屬性的還有Material Design最近的升級。嗯嗯嗯我知道這些你知道，但是細讀過了嗎？暗暗告訴你，很多面試中的“必答題”，有正確答案的那些，都是就那幾個題庫里面來的。

在建立設計系統時，平衡好吃現的吃相與妥協的程度，最終保證產出有你的產品特色不是一件容易的事。我建議盡量使用開源資源讓你能夠保證帶給公司與團隊的價值最大化。差異化產品特色，來自于你通過調研與產品規劃，不是你的設計（又有金句了）；可行性落地性？來自于你和前端工程師的溝通與合作程度。

六、建立好維護與修改機制

維護、修改機制比起設計庫與代碼庫本身更加重要，甚至在建立好設計系統之后，維護、擴展，讓設計系統活起來應該由專門的人員（設計+前端）共同負責，作為整個設計團隊的核心工作，保證這套系統在產品開發過程中順暢的使用而非給產品落地帶來阻力。

這樣的話就牽涉到這套系統需要有管理機制與負責人（組織）。設計系統的維護說來容易做來難，參考多少公司希望借鑒阿里巴巴建立強大的中臺系統最后都落得只有假把式。殊不知阿里的中臺系統背后是組織的上下變革的結果，能夠讓設計系統活起來其實也是要求能夠在系統建立之后，一套落實到開發管理流程里面去的強管控機制。在為設計系統設定落地機制與流程之前，可以從搞清楚以下幾個問題為起點：

1. 這是一套中心化管理的設計系統還是分布到各部組獨自管理比較合適？
2. 里面的設計規范哪些是需要嚴守的、哪些是有寬容度的？
3. 設計系統不同部分的維護責任落在誰身上？
4. 設計師/前端工程師找不到需要的組件時，是否有快速先解決版本落地的機制？
5. 當需要增加組件甚至修改規范，審核機制如何？個人建議如果希望設計系統越有主導權，修改機制越應該嚴密。
6. 最后也是最重要，驗收機制是如何落實的？

和世界上任何系統一樣，實施機制比內容本身重要得多了。如果管理不恰當、同步做得不夠好、統一調用不嚴格的話，哪天需要進行設計改版，那天就是你的設計系統的停用紀念日。

1. 設計系統的網站

是拿來干什么的？把設計系統當成是一個產品，那么它的用戶就是設計師、前端工程師、系統維護組、新員工。當然如果這個產品還有更高一層的文化輸出的產品任務，那這個討論范圍就更廣了。

仔細分析這些關鍵用戶的value proposition，你就發現其實這些“用戶”與設計系統的interface大多不一定是設計系統的網站，設計師也許是平臺上的shared libraries，工程師也許是github倉庫。但是一個網站對于設計系統依然十分必要，是因為：一，那些“你懂的”的組織原因；二，任何人尤其是新人來了之后快速上手的中樞環節；三，設計系統的路標、建設環節的宣布渠道，包含使用說明、規則發布。

2. 高度自動化……目前好像還沒有辦法

聰明如你，肯定會發現，設計系統包含了那么多具體設計層面、代碼層面的細節，而且應用角色有那么多，自動化與高度同步是很重要的。

坦率講……本人目前沒有任何明確方向完美解決這一個問題。但是有個提示是可以密切留意阿里出品的Fusion Design套裝。當然，如果你用Figma的話，你會發現Figma‘s Embed至少是解決了同步控件至各端包括設計系統的宣講網站。所以說Figma是為設計系統、協同而生真不是蓋的。

所以……沒了

本來想總結一下這幾年建立或參與設計系統的一些些經驗寫這篇文章，寫的時候也有借鑒一些最新的方法與技術手段，希望如果對需要接著做這件事的你能夠多多少少起些幫助。

總的來講，這依然是個在不停變化的行業，所以沒有哪一套方法是能夠算是被固化下來的：競爭環境的變化導致內部需求的變化，做事的方式就會由規整變得凌亂起來，然后時間又會慢慢沉淀出新規律。設計也罷設計管理也罷，本來就是需要永遠解決新問題，而且會一直把認為自己已經懂了一切的人淘汰掉出圈。

設計的outcome也許會變得越來越無趣。但是讓它繼續有意思的應該是需要被解決的問題竟然具有越挖越復雜的被動屬性。

作者：HaoH，公眾號：haohuanggongzhonghao；個人網站：http://haosgoing.cn/

本文由 @HaoH 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議