如何定義組件庫

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

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

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

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

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

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

也可以看看這篇總結：

閱讀文章 >>

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

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

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

2. 組件庫vs設計規範

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

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

△ 摘自「自如」設計規範

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

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

基本在滴滴的時候因為 CDX 的組件和規範沉澱的時間久遠，改版的頻率又十分之低，不同設計團隊溝通基本憑着一套出行的 UI KIT 就無師自通高效輸出了。現在到了新的團隊，也是優先搭建可以馬上使用出活的組件庫，畢竟項目拼的是效率和時間。

組件庫的部署與落地同步

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

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 賬戶會周期性退出登錄，所以我們還是需要時常檢查一下自己的 cloud 賬戶是否還在線，以免錯過更新。

3. 組件庫的監察機制與管理

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

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

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

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

基礎層：標準化規範符合度

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

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

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

數據層：數據驗證

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

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

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

總結

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

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

未经-摩登3注册-摩登3测速官网-允许不得转载：摩登3注册-摩登3测速官网 » 無極五娛樂怎麼樣?_如何零基礎高效建立組件庫？來看大廠設計師的總結！