設計系統是為了實現產品的目的而組織起來的一套相互關聯的模式和共享實踐。設計系統需要承認價值觀和公司文化的沖突，擁有共享詞匯表和設計系統的管理與協作方法等。不過目前存在設計與開發協作的斷層，設計工具無法很好地向工程師傳達設計邏輯，設計師和工程師的工作環境也存在脫節現象。這些問題，讓我們看看作者是怎么看待及解決的吧~

一、什么是設計系統

設計系統（也有人稱之為設計體系）是為了實現產品的目的而組織起來的一套相互關聯的模式和共享實踐。用于解決團隊協作、業務拓展、設計與開發規?；桓兜葐栴}。

按照目前主流的認知，設計系統主要包含以下部分：

1. 樣式指南；
2. 組件庫；
3. 設計原則與協作流程。

1. 樣式指南

通常包含顏色、排版、商標、字體等，重點放在品牌層面。

在 web社區，可能還會包含交互、動畫、語氣和文案等，這在《Design Systems》（Alla Kholmatova著）中被統稱為感知性模式。

早期的樣式指南規范可以追溯到 NASA 圖形標準手冊，其中已經提供了非?，F代化的視覺示例、顏色配對指南等。

2. 組件庫

包含預置的、可復用的 UI 元素，包含組件名稱、描述、屬性、狀態等，工程化的組件還需要代碼片段，用于更直觀地表達交互和響應式。某些設計系統甚至會提供沙盒環境來嘗試不同的組件定制方案。

與組件庫類似的，還有模式庫（pattern library）這一概念。

設計模式最早在建筑領域被提出，指代反復出現的特定問題及其解決方案。

在后面出現的數字產品領域，也有過不少經典的書籍，如《Designing Interfaces》中總結了大量的設計模式，作為一本入門讀物非常合適。

3. 設計原則和協作流程

主流認知中的設計系統通常還會包含設計原則（design principles）。比如尼爾森可用性原則、格式塔、錨定效應等，這在設計界已經被熟知。在構建界面、設計走查時通常也將這些原則作為參考。

但正是因為這些原則過于“通用且正確”，即使被納入設計系統，它們也難以提供有效的設計決策。而設計價值觀（Design Philosophy）則可以更好地在設計系統中找到自己的定位。

在設計系統中需要承認價值觀的沖突：

• 更多使用嚴肅的說明文字還是有趣的插圖？
• 從一開始就防止用戶犯錯，還是當用戶犯錯后進行糾正？
• 系統復雜度守恒又必須增加功能時，將復雜度轉移至其他功能、用戶或是開發？

設計價值觀作為設計系統的核心，可以很好地為設計提供指導，形成可復用的設計決策，為后續的設計評審提供統一的判斷標準。

還有一些內容可能在各系統中散落在不同章節，但又確實是設計系統不可分割的一部分，以下列舉部分：

1. 共享詞匯表幫助團隊內部建立統一的設計語言，畢竟誰也不想同時聽到“蒙層、蒙板、浮層、遮罩層”這些五花八門的稱呼；
2. 建立設計系統的管理與協作方法，安排專人負責設計系統的維護？還是所有設計師都有編輯權限？若是后者，還需要建立相應的評審機制，否則設計系統將會變得越來越臃腫且難以維護和使用；
3. 設計資產如何維護，產生的更新如何通知到工作流的上下游，版本的管理如何進行…

二、設計與開發協作的斷層

當團隊建立一套設計系統后，大部分設計交付都可以用設計系統中的樣式、組件、模板進行拼接。

例如色板中的基礎色號、全局的登錄組件、列表頁的篩選器等，這也是設計系統最直接的價值所在。

然而當進行設計交付時，設計師與前端工程師的協作方式對設計系統的支持并不夠友好。

首當其沖，設計工具無法很好地向工程師傳達設計邏輯。

Sketch、Figma這樣的圖形化工具都支持樣式和組件的綁定與調用，這是復用思想的體現。甚至有插件或第三方標注工具幫助展示元素代碼，這樣看起來工程師似乎只需要復制粘貼代碼即可。

然而實際情況卻是，設計稿無法體現出這種設計邏輯，比如頁面元素的響應方案、多設備切換、視圖滾動和元素間的依賴關系等。

另一方面，設計師與工程師的工作環境完全脫節。

設計師在畫板中對元素進行拖拉拽，而不是真正對組件進行設計。這導致設計師需要花費很大的努力才能遍歷組件的所有狀態。

即使所有的狀態都被考慮到，也不得不為此展示大量相似的頁面或冗長的設計說明，這對前端工程師的工作體驗非常不友好。

工程化的設計系統由設計師和工程師共同構建，而到了設計執行階段，現有的工作流程又將設計和開發拆開，這看來是非?；恼Q的。

綜合前面提到的兩個問題，設想一個這樣的資源倉庫，組件接口暴露給開發，由開發負責功能邏輯的實現，搭建組件的骨架，設計師只需要考慮組件的樣式和設計邏輯。

在這樣的平臺中，由設計師賦予設計變量，比如圓角、尺寸與間距、顏色、定位等（實際上設計師已經在Figma中做了這些努力，但是無法很高效地傳達給開發）。將這些變量提交后，所有使用了這一變量的套件都將被同步更新。

一些低代碼平臺已經在進行這方面的嘗試，這似乎可以填平設計和開發之間的鴻溝，成為一種新的協作模式。

三、設計模式的建立與維護

大部分設計系統的組件庫只會覆蓋到原子層級，各個設計系統對于這些基礎組件的定義大同小異，而只有設計模式（或者說業務組件）才蘊含了團隊對業務的思考。

以“地圖模式”為例——打車軟件和導航軟件都會使用到“地圖”這一模式，其中包含了“地圖、起點終點錄入、重新定位按鈕”等組件。但由于業務重點不同，打車軟件會直接顯示“起始地與目的地”等為打車流程服務的元素，而導航軟件則在首頁僅展示“目的地錄入”。

當地圖業務發生變化，理想情況下不再需要設計與開發資源的介入，只需要負責設計模式的設計師（或業務）進行修改。

舉個例子，當業務側需要對“首頁是否展示目的地錄入”進行調整，如果在后臺有這樣的接口暴露，便可以非常敏捷地進行測試。

然而，這種抽象在前期是非常困難且無法預期（甚至無法枚舉）的，需要綜合考量其兼容性、拓展性與成本，以及以何種顆粒度進行封裝。當這種困難可以被設計系統優雅解決時，設計系統的落地想必更具實際意義。

四、設計系統在細分領域的定制化

設計系統因為要兼容盡可能多的業務領域，這決定了它們的組件、模式必須要有足夠強的適應性，但也導致了它們的平庸。

在特定領域，可能需要對組件和模式進行定制才能滿足需求，比如找房類產品的篩選器中可能會包含“公司輻射范圍內幾公里”這樣的接口，對比一下 Fusion的“業務組件、區塊”和 NutUI的“特色組件”章節就可以很直觀地看到這種區別。

再進一步地，當智慧大屏、車機、虛擬現實這樣的場景需要設計系統的指導時，可能需要連帶著設計價值觀一起全部推翻重建，在各自的細分領域產出適應各自需求的設計系統。

當設計系統足夠健壯時，新的業務需求可以直接從模式庫中找到解決方案，進而將設計師從“接需求-畫稿子-接需求”的困境中解脫出來，轉而真正地去思考業務。