編者按：組件庫該如何構建？本文總結了組件庫的設定，需要用到的工具和同步方法，幫大家快速上手組件庫設計。

隨著公司業務的不斷增長，組件化除了為業務帶來一致的設計語言和工作效率提升外，也為設計團隊的產出和協作方式帶來了影響和變化。Gtech UED 團隊在進行需求設計的同時，也逐步沉淀出一套適用于多平臺、多業務的組件庫，以此來提升設計和協同效率，并最終實現專業價值和商業價值的平衡。本系列文章中，我會分享自己在整理與維護 Gtech UI Kit（Mob）過程中一些思考與方法。今天我們先聊聊如何邁出組件庫設計的「第一步」。

一、關于組件庫

1. 組件的本質是一種規則

從某種程度上講，設計體系 (Design System) 便是這樣一種「規則」 – 諸如配色、文本、組件等一系列設計要素共同構成了標準化的體系，為設計師提供決策指引。而組件庫作為設計體系的一部分，通過對典型樣式的歸納和常用組件的封裝，幫助設計師快速實現中/高保真原型的設計。

遵循這樣的「規則」，除了能讓設計流程得到有效加速，設計模式的復用性與一致性也將得到提升，使產品設計方案整體更具擴展性，更易于維護。

2. 持續維護的意義

組件庫項目實際上并不是埋頭苦干一個周期之后交付的產品，而是通過長時間的業務需求迭代后，持續沉淀的一個產物。就像跑馬拉松，從起點邁出第一步很簡單，困難的是持之以恒地跑下去，并最終抵達終點。通常業務迭代和組件維護的 Timeline 并不會交錯，每一個業務迭代周期都會調用當下版本的組件庫作為基礎模板；同樣，每結束一個迭代周期，也會將期間復用性較高組件或樣式定義更新到庫中。久而久之對于日常工作項目當中的諸多需求，便可以通過輕松拖拽或少量改動快速搭建頁面。

要實現快速搭建頁面，組件庫本身需要滿足「合理性」，包括合理的結構、命名等等，而這些都需要在整理和維護的過程中不斷思考和糾正。在實際的過程中，往往會在某一組件整理到中期時，才發覺似乎以另一種結構進行封裝更合理，那么之前的成果可能都需要推翻或者修改；同時，組件庫還應滿足可復用、易用的要求，以滿足日常業務的需要。設計師除了要學習通過使用組件來提高工作效率，更需要嘗試了解封裝、命名甚至維護的方式和流程，這樣才能對組件的使用更加得心應手。

二、必要設定

1. 基礎樣式

組件庫是由組件所構成。而樣式則是組件設計的基礎，通過層級自下而上逐級的搭建。制作組件、模板、頁面的過程中首當其沖便是全面、精細的對基礎樣式進行定義和維護，包括顏色、容器、字體、圖層等…

以“字體”為例，文字是構成界面信息與內容的基礎元素之一，無論是在高保真設計階段，或者對于交互設計師在制作的線稿、低保真原型階段。通過不同的色彩、字號、字重等參數來構建界面整體與局部的信息展示，確保界面內容的層次和呼吸感，幫助用戶更好的獲取界面信息。

針對系統級產品的通用場景，Gtech UI Kit (Mob) 針對單一文本提供了 360 種通用樣式，其中樣式的命名規則是基于文字的顯性屬性決定的，即「字體重量/字號/對齊方式/顏色」，譬如「Regular/14/1_Left/Grey 6」，所代表的就是常規字重、14 號、左對齊、顏色定義為「Grey6」的文字。

當然，所有這些文字樣式中，可能高頻使用的并不多，但我們還是更希望在前期花費足夠多的時間成本去定義一套統一的、足以應對絕大多數使用場景的樣式表，增加后期維護組件庫的容錯，滿足組件庫的易用性。

2. 組件結構

「結構清晰」作為組件定義的要求，也是考量組件庫易用性的因素之一。如果組件庫的最終目標是對外開源，那么在最初的整理和之后的維護中需要考慮的問題之一就是「普適性」,即探索一種對大多數團隊、個人都能很好的適應和理解且便于索引和調用的組件歸類方式。經過調研和內部討論我們最終選擇基于使用場景出發，將組件庫劃分為 6 個模塊，并將每種典型組件分頁進行展示，具體展示結構如下：

當然，基于組件屬性的分類也是一種常見的組織結構，Apple iOS UI 或 Google Material Design 等系統級組件都是按照組件屬性來劃分，一切都是為了更方便的索引和調用。在設計上，只要能達到目的，通往目標的方法只要選擇最合適的即可。

3. 命名規則

關于命名方式與規則，同樣是整理和維護組件庫過程中重要的環節之一。無論對于顏色、圖層、文本樣式的定義，還是組件、圖標、典型界面的整理與組織，統一、通用、靈活的命名規則都是貫穿始終的基線。

正如前文提到的，組件會基于使用場景進行劃分，其中每一類包含若干組件，譬如「展示」場景當中的單元格、標簽、徽標等，而每一個組件又是由若干狀態、參數等所構成。

層次分明的結構對于組件的命名有著一定的要求，一方面需要使維護過程更加井然有序、條理清晰，一方面要確保最終產出的組件便于索引和調用。通常為了體現結構層次，我們在組件命名當中使用「/」符號來分隔類別場景、組件、狀態或其它參數等 (Sketch 可以自動識別「/」符號，并以此作為類別分隔標志來逐層組織，最終形成完整的目錄結構) ，譬如下圖「展示 / 標簽 / 圓形標簽 / 小標簽」等等。只要使用者在調用時知道自己需要怎樣的組件，便能很輕松的逐層索引。

與組件結構一樣，關于命名并沒有一套所謂「最正確」的規則。最正確的規則就在團隊進行充分討論且符合大多數人的使用習慣并最終達成共識。

三、工具與同步

1. 插件推薦

「工欲善其事，必先利其器」隨著工作內容的不斷豐富，很多操作靠設計師手動實現往往難度較大，且較為繁瑣；在 Sketch 的社區內不僅有眾多的設計師，而且也還有活躍的開發者社群。開發者們提供了許多優秀的插件，從不同的角度完善了 Sketch 的功能，提高了設計師的工作效率。在進行組件的整理和維護時，我通常使用以下兩個插件：

Find and Replace Text 用于對選中的圖層、畫板、頁面設置整個 Sketch 文件內的文本內容進行查找并批量替換-無論是圖層內實際的文本內容或者是圖層列表當中的文本名稱均可；在嘗試命名規則的過程中，我們會通過這款插件批量修改基礎樣式定義中所呈現的文字風格名稱。

Styles Generator 用于批量且自動化定義文本、圖層樣式。在確定了命名規則，并完成了初始的樣式或字體屬性設置后，選中所有范例對象，執行「Generate Shared Styles」，Sketch 便能根據你所選中的對象的圖層名稱來自動生成對應的 Styles，無需任何手動命名的過程。

2. 協同方案

前面說到，組件庫的整理和維護是一個隨著業務需求不斷迭代更新的工作，及時迭代優化才能讓組件更好地滿足當下項目的需要。在內部，我們通過對存在的問題進行思考并嘗試尋找一種最優的方式，讓團隊輕松地做到高效協同。

最終，我們決定將組件維護的工作流程「上云」，即在云端進行設計協同工作；簡單來說，這種工作方式是將組件庫 Sketch 文件放在云端，通過云帳號的能力使得大家可以同時共享并使用這份文件。文件內會包含設計規范說明、組件、典型頁面等。設計師在工作時可以直接調用這些內容。具體操作如下:

1. 將組件庫 Sketch 文件通過 iCloud 云盤分享給團隊設計師 (可以根據團隊的需要來設置相應的編輯、查看權限) ；
2. 被分享的小伙伴們的云盤內出現該組件庫文件，可將其添加至 Sketch Library；
3. 即可以通過 Symbol 在項目文件中引用組件；
4. 每當團隊內對組件進行更新時右上角會出現「Library Update」推送，選擇更新的組件即可。

四、不僅僅是設計師的事情

相信很多小伙伴也嘗試整理出一套標準的組件規范，希望以此提高設計效率和確保產出一致。但在實際工作中會面臨一些問題：除了自己或設計團隊在使用組件外，似乎前端頁面并沒有達到組件化后的效果，不同的開發依然會對每個組件重新寫一遍代碼，沒有效率的同時視覺還原度也比較差。

出現這種情況主要的原因在于：在開發層面沒有實現代碼化，組件僅僅只是一張設計稿，并不是真實可調用的「積木」。

所以維護組件絕不單單僅靠設計師，開發也應作為主要參與者之一。需要二者通過多次的溝通、校對和持續開發維護 (此處省略諸多協同的過程，事實上，團隊排期的協調是一個十分重要的因素) 。而最終我們輸出的應該是一套可視產物和其背后的實現代碼，能夠真正地在代碼層面實現拖拽組件搭建界面的目標。

小結

在本篇文章里，我們主要聊了「關于如何進行組件庫設計」的一些常見問題，例如整理維護組件庫的必要設定、插件和協同方案的推薦、以及組件代碼化等等，希望能夠對各位的工作帶來一些思考和幫助。