如何定義組件庫

UI 設計組件庫（UI KIT），直譯過來就是用戶界面成套元件。我們日常工作中所構建的組件庫，一般是把所有界面設計中的控件以及控件組合匯總分類，形成一個對內對外都能起到提高效能與控制標準化的工具庫。

1. 辯證地看待原子設計理論

為了方便組件庫在實際應用中的實用度以及迭代拓展，我們通常需要對組件模塊進行分析解構。

大家應該都熟悉著名的原子設計理論在組件庫中的應用（原子設計：將頁面顆粒度分為原子、分子、組織、模板、頁面的超細維度，進行組件和組件的層層嵌套）。

所以是否我們就應該將原子理論不加辯證地應用到所有組件的構建中呢？我覺得這其中的顆粒度選擇還是需要根據(jù)組件的分類進行有區(qū)別的抉擇的。

△ 不熟悉原子設計理論的，推薦可以看看這位原子鼻祖寫的這本書

也可以看看這篇總結：

在商業(yè)設計中我們通常把組件庫分為「基礎型」和「業(yè)務型」兩大類，前者主要是以系統(tǒng)組件（導航/tab/鍵盤等）、頁面固定組件（圖標/按鈕等）等高頻使用的組件為主，后者則是直接關聯(lián)業(yè)務更加復雜多變的組件模塊。

如果說前者我們應用原子概念進行設計，我覺得是沒有太大毛病，包括在后期 library 的輸出上原子理論確實也會顯得比較嚴謹。

但「業(yè)務型」組件因為本身屬于復雜多變的模塊組件，使用過細的顆粒度不但容易影響整體動態(tài)化拼裝的效率，也可能因為顆粒度過細導致在變化過程中的體驗一致性變異。所以針對「業(yè)務型」組件，我們更需要對它進行交互解構。用結構化替代窮舉提效的同時保障整體的交互體驗一致性，確保這個模塊無論怎么變換，它還是不脫離整體的設計系統(tǒng)規(guī)則。

2. 組件庫vs設計規(guī)范

在討論完組件庫的顆粒度之后，有一些同學還是糾結這個 UI?KIT 到底需不需要和設計規(guī)范做結合，具體需要展示哪些內容更貼合現(xiàn)在主流的做法。

個人理解這兩者應該是相輔相成、相對獨立且呈包含關系的 2 個東西，如果 UI 設計規(guī)范類比一紙詳細的產品生產說明，組件庫則更像是一個線上工具零件庫+簡易工作使用說明書。再通俗一些來說，就是我們的組件庫依附于當前的設計規(guī)范，同時未來我們也將依據(jù)設計規(guī)范來產出新的符合規(guī)范的組件。

△ 摘自「自如」設計規(guī)范

△ 摘自「滴滴出行」uikit畫布展示說明

但實際上因為大廠 UED 規(guī)模及理念差異，大家對組件庫和視覺規(guī)范的輸出也各不相同。

基本在滴滴的時候因為 CDX 的組件和規(guī)范沉淀的時間久遠，改版的頻率又十分之低，不同設計團隊溝通基本憑著一套出行的?UI KIT 就無師自通高效輸出了?，F(xiàn)在到了新的團隊，也是優(yōu)先搭建可以馬上使用出活的組件庫，畢竟項目拼的是效率和時間。

組件庫的部署與落地同步

接下來我們來說說在實際工作中我們最為實用的部分，有關如何實現(xiàn)組件庫的完美應用，讓你的日常工作再也離不開它。

1. symbol化的設計布局思路

相信 sketch 的 symbol 化原子設計原理大家應該都很熟悉（不熟悉的話也可以百度搜到很多相關使用 symbol 的攻略），我就簡單再舉個彈窗的例子來補充一些小細節(jié)：

對于對話框組件的解構我們可以分為圖片區(qū)、標題區(qū)、正文區(qū)、操作區(qū)四個部分，所以我們要做的是把這個彈窗做成一個「無限可能」的對話框，即對話框的每一個區(qū)域（從圖片到操作按鈕）都是可以替換的。

這里我們需要單獨 symbol 化的嵌套部分就是圖片、操作按鈕及背景遮罩，這樣我們就可以得到一個基本可以直接適配使用的圖文對話框。

△ 有對symbol化操作過程有疑問的可以留言或者私我

按照如上思路我們就可以基本 0 失誤地完成 sketch 組件庫的初步搭建，接下來給大家分享一個常用的組件庫搭建目錄 list：

除了業(yè)務組件視不同產品業(yè)務線而定之外，基礎組件和傳達組件都相對固定可以相對大面積地復用。其中傳達組件大家可能接觸的相對少一些，對 UX 和UE 設計師來說是可以直接在做流程交互梳理時，拖拖拽拽完成設計的非常好用的工具組件。

△ 摘自「滴滴出行」uikit傳達組件-流程圖部分

2. sketch cloud的同步協(xié)作

制作完組件庫的 sketch 部署之后我們就需要把它真正地應用起來了。

我們可以通過 sketch/首選項/添加組件庫的方式將我們剛剛部署完的 sketch（命名為：組件庫 library_zmn_20191118）導入。之后就可以在 sketch/置入/組件中找到對應的「組件庫 library_zmn_20191118」組件庫直接進行拖拽元素使用。

這個步驟很多同學都很熟悉，但是在實際工作中我們常常會遇到一個問題就是，一旦這個組件庫發(fā)生變更該如何進行組內同步呢？如果只改變本地的組件庫源文件再更替上傳，其他設計同學的 library 并不會發(fā)生變化，所以如何做到大家同步更新呢？

首先我們需要做的是登錄 sketch cloud 賬戶（sketch 右上角的小云云）

登錄 sketch cloud 賬戶之后，我們需要將組件庫源文件上傳成為 cloud 文檔（sketch>文件>打開 cloud 文檔>新 cloud 文檔）。

這里我們還可以點擊已上傳的 cloud 組件庫文檔進行編輯和更新，之后記得在 sketch cloud 里添加你的組內設計同學哦。

這樣一來所有組內設計的同學就都可以在 sketch 里更新下載新的組件庫直接拖拽使用（一般 cloud 組件云更新后 sketch 的右上角都有「紅色通知提示」，是可以直接點開更新下載的）。

這樣一來實現(xiàn)了多人同步本地更新組件庫的高效操作，非常之實用。唯一美中不足的就是 sketch cloud 賬戶會周期性退出登錄，所以我們還是需要時常檢查一下自己的 cloud 賬戶是否還在線，以免錯過更新。

3. 組件庫的監(jiān)察機制與管理

去年面試的時候從快看到淘寶，感覺最高頻出現(xiàn)的就是有關組件庫的問題，感覺大家都很關注有關組件庫的定義與入庫標準。尤其在大廠的 UED，一般都有一套專屬的組件庫監(jiān)察滾動機制適用于多地多團隊合作，對于之后的組件庫更新迭代，新組件封裝入庫有自己的標準。

對于監(jiān)察機制我們就不多說了，因為并不一定適配于大家的情況，我們這邊主要談談組件庫管理。

因為組件庫從搭建完成之后我們會不停滾動更新，那是否需要將所有更新出現(xiàn)的新組件都納入組件庫里呢？顯然是不科學的，我們需要合理管理和控制組件庫的容量，及時調整和翻新組件庫里的組件，確保組件庫里的內容都是最新最好用的。

那么如何來判定組件的入庫與剔除標準呢？我們可以從 4 個維度進行細致的分析，這里提供一個參考。

基礎層：標準化規(guī)范符合度

對于組件的考察最基礎的應該就是標準化和一致性，組件是否符合視覺規(guī)范直接影響整體的體驗傳達。

體驗層：視覺層次/感官體驗是否良好

每個組件都應該適配合理的手勢交互熱區(qū)尺寸、一目了然的操作點功能分區(qū)以及極致舒適美學的感官體驗

數(shù)據(jù)層：數(shù)據(jù)驗證

一部分組件是可以通過埋點+單一變量的 A/B test 的方式測試出不同的點擊轉化率。這里我們舉個例子：例如電商的搶購按鈕，我們在不改變其他產品信息與視覺交互的情況下，通過測試 2 種不同文案以及視覺表達的按鈕的點擊率差異就可以用數(shù)據(jù)測試出 2 個組件的優(yōu)勝劣汰。

實用層：兼容性/復用率/拓展性

因為組件庫的容量有限，所以我們不能夠把所有出現(xiàn)過的，覺得不錯的組件都封裝納入組件庫，所以最后一條是組件入庫的決定性因素。只有組件復用足夠高頻且具有良好的拓展性，我們才能最終把它定格成組件庫的一員。

總結

咱們在 0-1 構建組件庫時，要清晰它的定義與作用，之后進行分類與 list 規(guī)劃，最后再在 sketch 中完成部署與落地，最后形成一套完成的組件庫同步協(xié)作的管理機制與新組件入庫的標準制定。更遠一點來說還可以與開發(fā)形成協(xié)作，共同開發(fā)線上組件庫資源，實現(xiàn)從橫向的業(yè)務賦能。

歡迎關注作者的微信公眾號：「Nana的設計錦囊」