設計系統的建設者如果想有效地規劃設計資產，提升組件的應用率，可以怎么做？這篇文章里，作者結合實際案例，分享了建設成熟的設計系統的經驗策略，即“通過場景演繹的方法重構資產，為其建立秩序，提升內在一致性”。一起來看看，或許會對你有所啟發。

前言

伴隨行業發展，越來越多企業在復雜業務場景中引入設計系統，對于建設一套成熟的設計系統，需要考慮三大模塊：生產、消費、監測。本文結合百度搜索設計系統近期針對【生產和消費】環節的升級改版，分享其中的經驗總結，即：通過場景化重構資產，為其建立秩序，提升內在一致性，并提升資產消費體驗。

文中介紹的方法，不僅可以幫助設計系統的建設者有效規劃設計資產，同時可幫助業務設計師在日常項目中對組件高效應用和合理創新。

一、項目背景

百度搜索在移動時代到來初期，通過劃分垂類團隊，深耕垂類特性，以極致體驗滿足不同垂類下用戶對內容精細化消費的訴求。這一階段設計資產的特點為：

1. 組件資產與業務強綁定，業務獨立維護。
2. 業務創新頻繁，組件樣式新增多、合并少。
3. 設計系統內在邏輯不健全，主要為各業務組件的快速錄入封裝。

這種設計系統建設方式是一種樣式歸納性思維：通過在初期快速歸納收集，滿足業務高速發展的需要。

但伴隨業務發展成熟，各垂類團隊橫向協作愈加頻繁，對組件復用提效與保持產品體驗一致性的訴求越發明顯，這種建設思維便會暴露出它的劣勢。

• 資產通用性不足，體驗難打平：業務各自維護資產，橫向場景兼顧不全面，資產橫向復用的標準不明確，體驗差異難抹除。
• 資產冗余且龐大，維護成本高：設計系統中存在很多樣式略有不同，體驗又無差異的組件，在業務升級和設計改版時成本高且容易出現遺漏。
• 資產缺乏邏輯性，約束性不足：資產與設計意圖的映射關系模糊，在相似的用戶需求和場景設計中，給設計師的設計指導力度不足。

而這些最終的結果會導致設計系統越來越不規范，易用性大大降低，不匹配業務成熟期的訴求。

因此在設計系統建設上，需要更高效的建設邏輯，以提高資產的易維護性與可拓展性，保證在業務成熟期可以更高效賦能團隊協作，增強產品體驗一致性。

二、項目方案

1. 明確目標

基于百度搜索設計系統現狀，其核心問題是資產規范性不足，而資產主要由“組件”和“規范”兩部分組成，設計師和工程師通過調用組件或閱讀規范，實現對設計系統的消費。因此我們理解一個業務級的設計系統，能夠賦能業務的方式需滿足：

1. 具有完備的設計資產：規范定義明確，組件變體健全。
2. 提供高效的消費體驗：消費途徑豐富，消費路徑簡短。
3. 具有良性的迭代模型：中臺與業務同頻，業務組件優化可實現資產的沉淀回流。

其中能夠實現業務賦能最大化的前提，是有完備的資產作為基礎。因此將設計系統的迭代發展，劃分了三個階段：

1. 統一化：夯實基礎，重構設計資產底層建設邏輯，明確資產適用場景，提升可拓展性與易維護性。
2. 工程化：整合資產代碼，提升資產消費效率，并在設計中臺與業務之間建立資產迭代的良性循環。
3. 工具化：探索設計系統工具化的形態，及AI大模型結合的機會，豐富消費途徑，實現在業務交付的不同階段下全方位提效。

那么在“統一化”階段，我們給出了目標：提升資產的規范性與易用性。

2. 目標拆解

面對設計交付鏈路上，遇到諸多雜亂的問題，應當如何去給出合理的解決方案呢？

首先可以基于現狀，從“資產生產 → 資產消費” 的鏈路出發對目標進行拆解。

三、設計動作

1. 重構底層邏輯，轉變視角

先來看一個設計系統工作中常遇到的問題，以下幾個組件從樣式上非常接近，那么在組件歸類上是否應該歸為同一個組件呢？

那以下兩個組件從形態上差異明顯，那他們又是否為一個組件呢？

1）過往：樣式歸納思維

在回答上面的兩個問題之前，不妨先來看看如果按之前的“樣式歸納”的視角進行分析，在資產建設中會發生什么？

我們發現樣式歸納性思維，是通過對已知的組件資產，進行共性和差異性羅列，然后求同存異，將共性較多的設計稿歸納為某一類組件；并分別定義其組件能力和使用場景。

這種建設方式可以在上圖直觀感受到，在初期的確可以幫助業務線快速建設出設計系統，實現單一業務內的復用，但當各業務均發展成熟時，這種設計系統卻無法滿足跨業務復用的情況，且缺乏內在邏輯的歸納思維，也無法對持續發散的業務創新形成有效收攏，這時便需要我們轉變視角。

2）轉變：場景化演繹思維

在業務變化快的情況下，歸納性思維的核心缺陷在于資產源頭不穩固。因此需探索一種源頭相對穩定的設計發起點，這可以通過追溯用戶行為進行解決。

人類發展至今，環境和媒介不斷變化，但是人類可實施的行為動作并沒有太多變化。同時在日常產出時，我們的設計意圖基本是圍繞如何讓用戶在某場景下用某種行為達成目標來開展的，之后這些產出物又被封裝為可復用的組件。由此可以倒推，將組件的本質抽煉為：幫助用戶在特定行為場景下，通過某個組件，以某種方式，達成目的。

而組件交互與樣式的變化，底層所承載的設計意圖都是為了在這個特定的場景下，優化用戶的行為，提升場景體驗。

這里所提到的行為場景，可幫助我們跳脫出業務場景，將設計資產剝離業務影響因素，回歸到簡單直接的行為動作之中。

當了解組件的本質，便可以將復雜多樣的組件，映射到自己產品、業務線的幾個宏觀用戶行為場景之中，再以此“場景”為基礎，層層延展，從“更好的達成用戶目標” 出發來演繹不同組件的變體。

我們可以試試以這種思維去重新思考本章節開頭提出的兩個問題：

很清楚的理解，這些不同業務中的組件，是為了服務于用戶的哪一種行為場景，而他們從樣式上來說是否相似，僅僅是服務于業務場景的表現形式。由此便可以將各類資產劃分到不同的組件類型中，并得到MVP版的設計資產及其延伸變體。

這種“場景演繹”的視角是一種根本思維，由內向外發散，通過本質推導組件可以滿足用戶什么場景的訴求。這種場景視角，可幫我們在建設設計系統時，提升通用性，降低維護成本。

2. 演繹推理變體，建立秩序

在上一小節，講解了什么是場景演繹思維，那么在實際工作中，還會思考兩個問題：

1. 應當依照何種原則和方法去推理變體？
2. 每一個組件理論上可以衍生各種變體，那么在構建設計系統時，應當滿足到何種程度？

1）推理變體的方法

如上文講到，我們拆解行為場景的目標，是為了滿足子場景下更好的體驗，建設合理的組件變體。此處以Tab組件的部分場景拆解為例，通過三步，來講解組件場景演繹的方法。

第一步：先明確最基礎的行為場景，以及達成目標的最基礎方式；例如當了解Tab組件的本質是為了幫助用戶達成“切換內容”的場景目標時，就可以通過細化主行為場景，演繹在各細分場景下，如何以更好的體驗優化用戶的行為，從而得到相應的變體。

第二步：演繹變體，衍生行為場景，優化達成方式；可以從對象、空間、時間等維度分別去細化行為發生的場景，然后從提操作體驗、提認知體驗、提情感化體驗等維度去優化達成方式。

第三步：獲得變體與適用場景，秩序建立：通過這樣的場景拆解與演繹，一個完整的組件便建立完成，對每一種變體的適用場景，也有了清晰的認知。由此可以通過抽象業務場景的特征，然后給各業務開發者與設計師，提供合理的使用建議。

同時，以這種演繹的方式建設組件后，每一類組件的能力定位更加明確，資產的建設會變得更加精簡，不易冗余。而我們對每類組件在搜索場域下可具備的能力與發展方向，也可以有一個脈絡清晰的預判。

不同的組件在場景拆解的維度上也會有所差異，但維度上需秉持從寬泛到具體、從廣義到具象的層層遞進式拆解，拆解越詳細，所得變體也會越全面。

當我們將所有設計資產中，都按這種方式進行重構歸類后，便可以得到一張有秩序有建議的設計系統全局場景演繹規劃圖。它可幫助清晰地預判設計系統的缺失，從而更好地規劃設計工作。

由以上方式可獲得任何一個資產的建設發展圖，那么關于此資產在當前階段需要滿足到哪種程度，則可以從業務需要與建設成本去綜合考慮，從而保持設計系統在不同階段，都可以資源利用最大化。

3. 貼合消費場景，提升易用

在重構資產的同時，也需要考慮消費場景的易用性，而規范文檔是現階段消費資產的主要方式之一。因此也對文檔的內容做了優化整合，并為設計系統后續內容工程化打下基礎。

第一步：資產層級扁平化；將組件從行為場景上，按更細的顆粒度進行分組呈現，同時建立目錄導覽頁，平鋪所有組件的跳轉鏈接，以更加扁平的姿態提升組件觸達效率。

第二步：文檔結構統一化；考慮之前的文檔由不同設計師撰寫，在撰寫習慣與表達用語上有所差異，會增加開發者閱讀時的理解成本。因此我們將組件文檔結構與話術進行了統一，將組件按變體類型，進行統一分類，再分別講解其對應的交互與樣式參數，從而進一步提升消費時組件變體的觸達效率，以及減少不相關信息的干擾。

第三步：內容場景化；將文檔按組件變體分類完成后，同時在文檔開篇，以及每個變體下，建議了適用場景，以提升開發者的使用準確率

四、項目結果

在今年上半年，通過轉變設計思維，運用本文行為場景演繹的方式，使設計系統變得：

1. 每類設計資產邊界清晰、適用場景明確，重復冗余概率低。
2. 設計系統內在邏輯統一，易維護，具備可拓展性與易規劃性。
3. 設計系統可變得更加具有確定性，減少業務的動態易變所帶來的影響。
4. 保證服務的產品的體驗一致性，降低用戶使用成本。

同時通過優化消費場景，幫助開發者更易理解，提高資產生成與資產消費的匹配程度。從整體度量效果上來看，組件變體的在保證可覆蓋歷史場景的情況下，實現了精簡化；通過演繹變體，優化文檔結構，也提升了開發者對于設計系統消費的整體滿意度以及對規范合理性的感知。

另外為提升設計系統對業務的實用性和可用性，我們配合多次的團隊宣貫，幫助開發者建立共識，保證后續協作效率。

五、實踐方法總結

本文著重介紹的場景演繹方法本質是一種場景化的設計思維，其核心在于抽象場景特征，通過抽象的場景特征實現設計資產與業務場景之間的關聯匹配。

其中對于資產建設者而言，是正向通過拆解行為場景獲得場景特征，從而更好匹配業務場景；而對于資產消費者，是逆向通過提煉業務場景，進而匹配行為場景，發現資產變體的不足，從而完善設計系統。

由此可見這種方法，不僅適用于系統級組件級的推演，也可以用于日常業務需求的創新與業務組件提煉中。

由于每個組件的本質是服務于單一的行為場景，因此在日常需求中，需要設計師先對用戶流程進行梳理。

在需求的若干個業務場景中，對每一個業務場景，做最優的行為路徑設計，再通過提煉每個行為路徑下，涉及到的行為場景及其場景特征，去匹配現有設計資產：

1. 如改版需求，可以判斷已應用的組件變體是否很好的幫助用戶達成了目標，從而依托業務場景思考更適用的組件變體。
2. 如新需求，可以判斷現有的場景特征，是否可以匹配已有的設計資產，以及已有的設計資產是否可以被進一步優化。

六、設計系統后續展望

本文分享了如何通過【場景演繹】的方法重構資產，為其建立秩序，提升內在一致性；當然從整個設計系統的長期建設層面來看，當前對資產的系統化重構與文檔結構化的建設只是開始，絕非終點，在真實的協作流程中仍然會面臨兩大問題：

1. 設計中臺與業務沉淀如何保持同頻

業務設計師在真正的資產消費鏈路中往往具有很強業務訴求，需要對部分資產基于業務進行定制，甚至需要建立獨立品牌風格。這些不可避免的會導致業務設計師需要獨立維護一套子級設計資產，同時下游的前端也需要基于業務對資產進行二次開發。

這容易導致業務場景的變更無法及時同步設計中臺；同時通用資產的迭代更新也無法快速覆蓋到業務場景中，導致對業務賦能效果打折扣，這些長期而言不利于設計系統健康迭代。

2. 原有資產消費路徑不便捷

雖然在本次升級中優化了規范文檔的閱讀體驗，但其實它僅僅是整個資產消費鏈路中的一小部分。整體看設計師仍然需要在規范文檔、Sketch組件UIkit與需求設計稿之前反復橫跳切換；同時在交付過程中，也無法將設計資產同前端開發者建立共同語言的鏈接，從而不利于設計系統對業務落地的深度提效。

要解決這兩個問題，需要推動設計系統工程化、提升資產消費鏈路靈活性，這其中的關鍵則是：

1. 在上游建立中臺與業務之間同源可擴展的Design Token。
2. 在下游提供可串聯設計與研發資產消費的工具分發平臺，及提升協作溝通效率的信息中轉站。

近期已經按照以上思路開始了“設計系統工程化與工具化”的升級改造，這部分內容后續有機會也會和大家見面分享。