@C7210?：上篇文章說到了《像做產品一樣對Design System進行前期規劃》，包括目標、原則、范圍與架構，這四個方面。本周在最關鍵的部分深入推進一步，聊聊「架構」當中的一些問題。

需要再次說明，這些內容多數來自于我日常的工作日志，更像隨筆，且僅代表我個人在面對特定的產品/項目/團隊時所用到的工作思路和方法；事情只有特定的最優解，而非唯一答案；希望為各位帶來一定的參考價值。

一、組件庫與設計規范

記得之前看到一篇文章，比喻得非常漂亮——僅就相對狹義的、以組件庫與設計規范為主要組成部分的 Design System 而言，你可以將其想象成宜家家具，組件庫是以零件形態呈現的家具產品，而設計規范便是指導你完成組裝的說明手冊。

兩者的功用及關聯性就是這樣一目了然；兩者的架構設計在很大程度上具有共通性。大體上，組件庫與設計規范的架構體系在顆粒度較小的層面通常可以做到一致；但設計規范也會有其特定的目標及作用范圍，當涉及到「設計模式」等層面，顆粒度往往會超過組件庫所能承擔的范圍，此時也無需追求全面一致。

二、「原子化設計」不錯

有過相關經驗的朋友或許都知道，組件庫初期的架構設計工作是最消耗時間與心力的過程，特別是對于大中型「成熟」產品而言，太多的功能流程及相應的組成頁面，太多的不一致性問題。以怎樣的規則去梳理可復用的組件，以怎樣的顆粒度去劃分組件層級，怎樣確保劃分方式具有足夠的靈活性與實用性。推進過程往往是慎之又慎、舉步維艱的，每一個步驟都嚴格以上一個步驟為基礎。

對于組件的顆粒度劃分，目前最經典的理論是「原子化設計（Atomic Design）」，我們之前在一些文章當中也有介紹；可大致理解為：

• 原子：最基礎的、不可分割的設計要素，宜家家具的零件單元，一塊樂高積木，等等。通常包括顏色、文字、柵格體系等樣式風格要素，以及圖標、按鈕、文本輸入框、切換等功能性的界面基礎要素。
• 分子：由原子組成的、具備獨立功能性的最小可復用單元，例如一個包含了文本輸入框、占位符文字及按鈕等元素的搜索欄，或是一個包含了用戶頭像、用戶名、用戶評論內容及點贊按鈕的列表單元（Table View Cell）等等。
• 有機體：由單一/多種類型的分子組成的信息/功能性模塊。

至于「模板」和「頁面」，個人看來對于組件庫架構設計的意義不大；或可從「視圖」的角度理解「模板」，這個再議。

三、會出現很多問題

然而在很多時候，當你準備以原子化設計的思路規劃整個組件庫的架構時，往往會發現實際狀況絕非如此層次分明、符合邏輯；原子級別的要素大體還好，一旦進行到「分子」和「有機體」的層面，時常感到難以判斷和區分。

梳理架構的第一步通常是 UI清查，這是一項枯燥和冗長的工作，你需要將現有的典型頁面（截圖或設計源文件）整合在一起，提煉出各類典型元素，進行相對松散的歸類，判斷組件庫的大致架構。期間可能遇到的典型問題包括：

• 對于一些模棱兩可的元素，應該按照相似的樣式進行歸類，還是按照功能做區分？譬如樣式上均屬于「標簽（Tag）」的元素，從功能角度，某些是真正意義上的屬性標簽，某些則是選項列表的組成部分；這時是否應該將它們歸為一類？
• 多數涉及「內容」的產品，內容類的「分子」或「有機體」占據著很大的組成部分，且自身的組成元素往往會根據不同的頁面環境而有著大大小小的不同，包括商戶、商品、評論、內容Feed 等。對于這些內容，是否有必要封裝成可復用的組件，封裝之后是否反而會影響實際設計時的靈活性？它們與其他「功能性」的組件在邏輯上有怎樣的不同？
• 除了主色盤及基本樣式以外，產品當中往往會四處出現用途比較單一或邊緣的配色、文字及圖形樣式，這些樣式是否有必要進行嚴格的定義？如果定義，如何避免樣式庫與組件庫的過度復雜；如果不定義，如何確保這些「非主流」元素在未來設計過程中的一致性？

四、問題的根源

個人認為，通過原子化設計的思路進行 UI清查和架構設計時遇到的一系列問題，其根本原因在于，「原子化設計」本身更像是一種開發思路，它是事物構成的基本規律與方式，但未必適于「認知」和「使用」層面的心智模型。

你可以遵循嚴格意義上的原子化設計思路去到 Sketch 當中逐層進行樣式定義與 Symbols 嵌套，但最終的產出未必是對設計師實際有用的組件庫。

如前所述的一系列問題、矛盾，本質上是用戶（設計師）的心智模型與產品（組件庫）的實現邏輯之間的沖突。當你自身是設計師，同時又是組件庫/設計體系的制作人員時，你會不經意間在「設計師」與「產品開發人員」這兩個角色之間交織互換而不自知。

五、一些原則

對于組件庫/設計體系這樣復雜的事物而言，任何單一的邏輯與標準都未必行得通；最終還是要從我們在上一篇當中聊過的「目標」和「原則」出發，結合用戶的認知模型與產品自身的實現邏輯，找到相對折中的方式進行推進。

對于實際「用戶」，即設計師而言，組件庫/設計體系的目標在于解決表現層面設計工作中的痛點，提高執行效率與產出的標準化。圍繞著這樣的目標，我給自己制定了幾點原則；每當在組件庫架構規劃中遇到問題和矛盾時，通常可以參考這些原則，以實際結果為導向進行判斷，避免陷入邏輯陷阱：

原則一

對于組件庫架構設計與庫文件的制作方式，在大方向上要符合原子化設計思路，即顆粒度從小到大，從簡單到復雜；特別是在 Sketch Library 文件的實際制作過程中，從技術角度嚴格遵守層級思路是必需而非 better to have。原子化設計的思維方向無錯，解決問題的關鍵在于結合使用者的心智模型，即原則二。

原則二

難以確定組件顆粒度/復用性/在架構中所處的類別時，避免陷入過于嚴格的邏輯思維模式，而要考慮設計師的實際所需，考慮設計師在組裝界面時的直覺與思維模式，考慮設計師在典型的需求中預期得到哪些零件，他們/我們對這些零件通常是如何歸類的，哪些屬性是他們/我們需要頻繁訂制的，哪些是很少/不會觸及到的。對于使用 Sketch 進行界面設計的團隊，組件庫最終的產出將體現在一個個 Symbol 和 Shared Style 當中，而非設計規范中描述的設計模式或是開發側的代碼包；這些Symbol和樣式能否被設計師快速發現、理解和調用，才是最重要的，無論它們在實現邏輯上是否符合這樣或那樣的設計思想理論；其他都是浮云，實踐是檢驗真理的唯一標準。

原則三

充分分析和參考現有的任何設計規范/標準，運用你的基礎開發常識（如有）去理解開發側的代碼組件架構；所有這些文檔都能在一定程度上映射出產品的信息與功能架構。此外，相比于埋頭在繁冗的 UI清查工作當中難以自拔、糾結邏輯，不如多花些時間與一線設計師進行溝通，了解他們/我們當前是否有著組件化的、非正規但有效的解決方案。將所有這些「現有」的應對方案進行匯總，再沿著原子化設計的大方向，結合自己的UI清查，逐漸梳理出一套即在一定程度上符合邏輯，又充分適用于實際需求的組件庫架構框架。

圖片素材作者：sandeep virk

「組件化設計」

• 《為什么我們都應該學會組件化設計思維？》
• 《這篇8000字長文，能幫你學會組件化設計與開發的思維方式》
• 《進階必讀！可能是最全面的組件化開發與設計指南》
• 《設計實戰：教育產品組件化交互設計的實踐與思考》