組件庫設計指南（一）：組件庫的誕生

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

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

一、關于組件庫

1. 組件的本質(zhì)是一種規(guī)則

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

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

2. 持續(xù)維護的意義

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

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

二、必要設定

1. 基礎樣式

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

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

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

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

2. 組件結(jié)構(gòu)

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

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

3. 命名規(guī)則

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

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

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

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

三、工具與同步

1. 插件推薦

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

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

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

2. 協(xié)同方案

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

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

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

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

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

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

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

小結(jié)

在本篇文章里，我們主要聊了「關于如何進行組件庫設計」的一些常見問題，例如整理維護組件庫的必要設定、插件和協(xié)同方案的推薦、以及組件代碼化等等，希望能夠?qū)Ω魑坏墓ぷ鲙硪恍┧伎己蛶椭?/p>

歡迎關注作者微信公眾號：「Gtech UED」