在上文《UX設計0到1的全方案思考與呈現》里，我們已經嘮了嘮：0-1設計方案如何思考，有哪些要點值得出現在你的作品集里。今天我們就著最后一個要點：組件庫的定義，詳細聊聊如何從0到1搭建組件庫，以及組件庫如何高效的對內外應用。

一、如何定義組件庫

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

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

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

大家應該都熟悉著名的原子設計理論在組件庫的中瘋狂應用（原子設計：將頁面顆粒度分為原子、分子、組織、模板、頁面的超細維度，進行組件和組件的層層嵌套）。所以是否我們就應該將原子理論不加辯證的應用到所有組件的構建中呢？

我覺得這其中的顆粒度選擇還是需要根據組件的分類進行有區別的抉擇的。

（不熟悉原子設計理論的推薦可以康康這本原子鼻祖寫的這本書…）

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

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

但“業務型”組件因為本身屬于復雜多變的模塊組件，使用過細的顆粒度不但容易影響整體動態化拼裝的效率，也可能因為顆粒度過細導致在變化過程中的體驗一致性變異。

所以針對“業務型”組件，我們更需要對它進行交互解構。用結構化替代窮舉提效的同時保障整體的交互體驗一致性，確保這個模塊無論怎么變換，它還是不脫離整體的設計系統規則。

2. 組件庫vs設計規范

在討論完組件庫的顆粒度之后，有一些童鞋還是糾結這個UI kit到底需不需要和設計規范做結合，具體需要展示哪些內容更貼合現在主流的做法。

個人理解這兩者應該是相輔相成、相對獨立且呈包含關系的2個東西，如果UI設計規范類比一紙詳細的產品生產說明，組件庫則更類比一個線上工具零件庫+簡易工作使用說明書。

再通俗一些來說，就是我們的組件庫依附于當前的設計規范，同時未來我們也將依據設計規范來產出新的符合規范的組件。

（摘自“自如”設計規范）

（摘自“滴滴出行”UIkit畫布展示說明）

但實際上因為廠子UED規模及理念差異，大家對組件庫和視覺規范的輸出也各不相同?；驹诘蔚蔚臅r候因為CDX的組件和規范沉淀的時間久遠，改版的頻率又十分之低，不同設計團隊溝通基本憑著一套出行的UI kit的就無師自通高效輸出了?，F在到了新的團隊，也是優先搭建可以馬上使用出活的組件庫，畢竟項目拼的是效率和時間。

二、組件庫的部署與落地同步

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

1. symbol化的設計布局思路

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

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

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

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

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

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

（摘自“滴滴出行”UIkit傳達組件-流程圖部分）

2. sketch cloud的同步協作

制作完組件庫的sketch部署之后我們就需要把它真正的應用起來了。我們可以通過sketch/首選項/添加組件庫的方式將我們剛剛部署完的sketch（命名為：組件庫library_zmn_20191118)導入。之后就可以在sketch/置入/組件中找到對應的“組件庫library_zmn_20191118”組件庫直接進行拖拽元素使用。

這個步驟很多童鞋都很熟悉，但是在實際工作中我們常常會遇到一個問題就是，一旦這個組件庫發生變更該如何進行組內同步呢？

如果只改變本地的組件庫源文件再更替上傳，其他設計同學的library并不會發生變化，所以如何做到大家同步更新呢？

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

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

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

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

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

三、組件庫的監察機制與管理

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

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

因為組件庫從搭建完成之后我們會不停滾動更新，那是否需要將所有更新出現的新組件都納入組件庫里呢？

顯然是不科學的，我們需要合理管理和控制組件庫的容量，及時調整和翻新組件庫里的組件，確保組件庫里的內容都是最新最好用的。

那么如何來判定組件的入庫與剔除標準呢？

我們可以從4個維度進行細致的分析，這里提供一個參考：

1. 基礎層：標準化規范符合度

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

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

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

3. 數據層：數據驗證

一部分組件是可以通過埋點+單一變量的A/B test的方式測試出不同的點擊轉化率。

這里我們舉個栗子：例如電商的搶購按鈕，我們在不改變其他產品信息與視覺交互的情況下，通過測試2種不同文案以及視覺表達的按鈕的點擊率差異就可以用數據測試出2個組件的優勝劣汰。

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

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

最后總結一下

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

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

題圖來自Unsplash，基于CC0協議