編輯導語：設計在滿足基本的產(chǎn)品需求的同時，也要注意各業(yè)務線平臺的設計一致性，給用戶傳達好正確的品牌認知。本文以QQ動漫設計系統(tǒng)為例，分享了一些過程中的思考和經(jīng)驗，希望對大家有所幫助。

隨著項目的不斷發(fā)展，設計團隊在不斷壯大，設計師之間的協(xié)作也越來越多，相應的溝通和協(xié)作成本在不斷增加。如何才能更高效的合作，并把設計質(zhì)量和一致性做的更好，是我們需要去解決的問題。

01 問題之源—本地組件庫

在項目初期，團隊設計師的協(xié)作方式是通過一個本地的sketch規(guī)范文件，以復制粘貼的方式來復用一些元素和控件。在設計師協(xié)作人數(shù)不多，UI控件改動頻繁的情況下，這套流程可以比較快速的完成需求。

但隨著項目逐漸成熟，協(xié)作設計師人數(shù)變多、UI控件逐漸趨于穩(wěn)定且需要復用的地方逐漸變多時，之前流程的不足就逐漸凸顯出來。

1. 更新通知缺乏自動化

文件更新難以做到及時有效的通知到所有設計師，且需要人工在群里發(fā)通知，告知大家更新了文件。有些設計師暫時可能沒有相應的設計需求，可能會忽略更新后的文件，造成設計的不同步。或者等到需要的時候才去群里找更新的規(guī)范文件，版本容易搞錯且費時費力。

2. 全局組件更新困難

由于組件樣式是通過復制或修改的方式應用到界面設計中，當規(guī)范文件更新時，無法智能的自動更新修改相應的組件，需要設計師人工核對哪些地方有修改。這樣很難保證大家的設計版本都能得到統(tǒng)一的更新，當大家使用的組件版本不一致時，輸出的界面就會出現(xiàn)雜亂無章的情況。

3. 代碼復用率低

開發(fā)沒法全局調(diào)用代碼樣式，有些樣式可能需要反復復制使用，耗時費力，并因此產(chǎn)生的代碼臃腫，還會直接影響產(chǎn)品性能。

02 解決之道——云端組件庫

鑒于設計師目前多使用sketch+xshow的工作流程，而xshow正好也具備云端管理的能力，故決定以xshow作為橋梁，建立一個基于sketch+xshow的云端設計組件庫，以非常低的遷移和學習成本完成流程優(yōu)化。

優(yōu)化后的流程是把sketch本地組件庫通過xshow上傳至云端服務器，設計師通過xshow云端功能添加到sketch中，并在設計文件中嵌入這些云端組件。

這樣做能很好的解決上面說的問題：

1. 更新通知自動化

更新文件不用再靠人工在群里發(fā)通知，設計師也不需要去找文件，而是在sketch中會自動進行提醒。一旦有更新，會在右上角顯示提醒消息，設計師只需要點擊提醒，下載最新組件文件即可完成更新。

2. 全局組件一鍵更新

當更新組件庫文件后，界面中所有之前使用過云端組件的控件元素都會自動比對更新前后的差異，方便設計師判斷是否更新。這種更新最厲害的地方在于，更新是全局的，也就是一旦你確認了更新后的內(nèi)容，所有界面都會自動按規(guī)范進行更新而無需設計師再逐個篩查。這樣做既能保證設計稿的一致性，也能大幅提高設計效率。

3. 開發(fā)效率和質(zhì)量大幅提升

開發(fā)通過代碼把一些常用的樣式進行封裝，在一些高度復用的場景中直接調(diào)用。一方面可以通過調(diào)用的形式減少重復樣式代碼的復制，精簡代碼，降低軟件包體積，另一方面也可以減少不必要的工作量還能方便后期維護。

03 實踐之行—云端組件庫搭建

想要高效解決問題，正確的方法很關鍵，這里我們用到的方法就是原子設計理論。2013年前端工程師 Brad Forst 將此理論思想運用在界面設計中，形成一套設計系統(tǒng)，包含5個層次：原子、分子、組織、模板、頁面，這套理論為組件庫的搭建提供了思路和方法。

在實際搭建過程中，因為組件庫的搭建工作量往往比較大，需要先明確流程和分工，主要包括以下幾個關鍵步驟：

1. 明確工具流程

因為是搭建云端組件庫，所以首先需要有一個云端工具進行管理。針對以sketch為基礎的云端組件庫來說，常用的工具流程包括sketch cloud，各類云同步盤，第三方云數(shù)據(jù)庫自主部署等等。我們選擇的sketch+xshow工作流也是基于xshow具備云端管理功能，與其他流程本質(zhì)上是一樣的，大家根據(jù)項目實際情況合理選擇就好。

2. 全面匯總并分類

按原子理論由小到大來對常規(guī)控件進行匯總并分類。對于QQ動漫項目來說，常見的控件類別包括：顏色、字體、圖標、按鈕、導航、狀態(tài)欄、彈窗、列表、標簽等等。每個項目所需要整理的組件不盡相同，原則就是對要復用的元素進行整理。

3. 制作樣式模板

為了便于維護和提升合作效率，將組件庫拆分為幾個不同的獨立文件，每一個文件由組件庫搭建小組成員獨立負責，減少混亂。

如果是有多位設計師參與時，因為組件庫的元素存在相互調(diào)用的情況，會遇到到底誰先做的問題。解決流程分2步：

1）由一位設計師把組件庫的原子級組件（主要包括顏色，字體，圖標）先做好，并建立分類組件標準模板，其他設計師在這些模板基礎上進行完善，保證組件庫在邏輯層級統(tǒng)一。

2）如果過程中遇到，自己組件中需要調(diào)用對方組件，比如某個圖標沒有在圖標組件文件中，但自己的列表中又需要，可以先用其他組件中的圖標代替，等圖標組件庫更新后，再同步更新這里的組件即可。

QQ動漫組件庫一共分了5個不同文件，分別是：基礎、操作、導航、反饋和內(nèi)容。

4. 搭建本地組件庫

1）確定命名邏輯

提升設計效率，是組件庫存在的重要目標之一，而合理的組件命名起到了至關重要的作用。組件的名稱要保證通用性，太獨立的命名可能不夠兼容其他場景，也會讓使用的同學產(chǎn)生誤解。

對于組件命名，要多與使用的設計師一起探討，因為每個人的習慣都不同，方不方便因人而異，所以需要做一些平衡。

比如在做圖標命名邏輯的時候，糾結于要先按尺寸分（圖標/序號類別/尺寸/圖標名），還是按功能分（圖標 / 序號類別/尺寸/圖標名/狀態(tài)），不斷調(diào)整多次，這時候就需要找大家一起探討，怎么才是最方便的。

命名的方法是盡可能按共用屬性由多到少的順序來整理。比如，圖標共用的尺寸屬性多，就把尺寸歸到上層；如果圖標功能分類比較集中，那就把功能名稱歸到上層。根據(jù)實際項目和設計師使用情況的不同，會有不同的命名形式，命名確保效率就好。

在梳理組件庫結構命名時，先用思維導圖描繪一份結構化地圖，方便前期討論及調(diào)整。明確層級關系后，用在多人合作時進行參照，從而統(tǒng)一組件庫層級。在做這份結構化地圖時，需要列好全部分類、層級、具體名稱及示例。

2）顏色

顏色庫的設計，需要將產(chǎn)品中可復用的顏色匯總并分組，比如品牌顏色，按鈕顏色，圖標顏色，裝飾顏色等等，這樣可以使得用到顏色屬性的組件更加靈活。顏色的命名規(guī)范是：序號_功能/淺色or深色/序號 _ 屬性 / 序號 _ 狀態(tài)。例如， 04 _ 按鈕色/淺色/01 _ 常規(guī)按鈕/04 _不可點

3）字體

字體樣式需要做全字重、顏色和左中右三種對齊方式，因為按目前sketch的組件邏輯，還不能修改嵌套字體的屬性。這些屬性可以對應到組件的命名上，字體組件的命名規(guī)范是：大小/序號對齊方式/屬性/用途，例如42px/1居左/常規(guī)/主文本。

邊做邊檢查。由于文字組件需要的命名特別多，很容易出錯，所以建議是最好每做一組，就檢查一遍。檢查的時候打開組件樣式，如果在組件預覽中發(fā)現(xiàn)重復或者結構不對的地方，及時調(diào)整。

多行文本行高要注意。文字的行高要尤其注意，一定要在前期檢查好尤其是多行文本的行高。如果行高前期設置不對的話，非常影響后面文本的擴展性，在用到多行文本時會遇到麻煩。想回頭修改的話，因為是最底層的原子需要逐個調(diào)整，所以代價是巨大的。

所以一定要開始設置字體組件之前就確定好行高，比如QQ動漫組件庫中的文字行高統(tǒng)一用文字大小的1.5倍，并取偶數(shù)作為文本的行高。當然，這里的行高也不是完全規(guī)定死，有時候也需要視情況而定。

文本的粗細。文字的粗細也是要在一開始的時候就要設置周全，最好是給所有字號的文字都設置好不同粗細的組件，盡管可能開始用不到，但會提升文字的擴展性，不然后面添加就會比較麻煩。

4）圖標

圖標組件最關鍵的地方在于使用邏輯和圖標規(guī)范。比如，我現(xiàn)在做的圖標邏輯是：圖標/類別/使用場景/具體名稱/尺寸/不同狀態(tài)，主要是按使用的頻次來整理的。也可以有其他邏輯方式，以方便使用為準。

圖標規(guī)范也會影響組件庫的整理和日常使用，在做圖標組件時，需要定義好圖標的最大范圍和最小范圍，嵌套起來使用才不會出錯。圖標的規(guī)范要嚴謹，同一個尺寸下的圖標視覺面積要保持一致。不然在大小這個層級就會出現(xiàn)，雖然是相同尺寸的圖標切圖范圍，但圖標的體量看起來卻并不一致。

將純色或漸變圖標中的顏色剝離，并使用顏色組件進行嵌套，這樣做既方便替換又能減少圖標組件庫的復雜度。

對于圖標的多種狀態(tài)，建議做在同一個層級中方便選擇。

對于圖標來說，直接對畫板設置切片即可，不需要再加切片框。如果你的組件庫之前用了很多切片來導出圖標，可以用Automate插件直接清理或設置全局的切片，非常方便。

5）控件

有了顏色、字體、圖標這些基礎元素后再來制作組件就會相對簡單很多，只需要通過拼裝把通用性強的組件做出來即可。這里可能需要注意設置好布局方式，讓內(nèi)容盒子隨著內(nèi)容的變化而變化。新版sketch的布局設置相對于老版本的確實會方便很多，理解起來很容易，所以這就不多討論了。

6）代碼組件化

在開發(fā)側進行前端UI組件庫的封裝，實現(xiàn)從設計到開發(fā)的樣式統(tǒng)一，提升效率和質(zhì)量。

在優(yōu)先級上，代碼組件化跟UI組件化可以同步進行，開發(fā)先寫好框架，然后隨著UI組件化的逐步確定，代碼也進行相應補充。

5. 構建云端組件庫

本地組件庫構建完成后，即可通過xshow上傳至云端，再由xshow直接添加到本地sketch中，完成整個使用流程的搭建。

6. 權限與維護

為了更好的維護云端組件庫，避免更新混亂，需要成立組件庫小組，只允許組件庫小組成員有編輯權限。日常需求中，如有新增組件，需提交給組件庫小組成員審核，通過后方可上傳至云端組件庫。

在制作組件文件的過程中，需遵循先自測后上傳的原則，避免在上傳后發(fā)現(xiàn)一些諸如命名錯誤、遺漏、嵌套混亂等問題，造成麻煩。

7. 編寫規(guī)范文檔

文檔的作用是給相關同事查閱，形成標準化使用流程。一些在組件庫中難體現(xiàn)的設計說明、未形成組件元素的使用規(guī)則或一些常見問題都可以寫在文檔里。

8. 問題與技巧

1）善用插件，提高效率

我其實是一個非常喜歡“偷懶”的人，但凡需要重復，批量的工作，我都覺得應該有更聰明的辦法。這里我推薦幾個我在做組件庫中經(jīng)常用到的小插件。

• 云端組件管理工具Xshow：https://xshow.tencent.com
• 針對組件相關的修改，功能非常強大Automate：https://github.com/Ashung/Automate-Sketch
• 批量改名Rename it ：https://renameit.design/sketch

2）不斷測試

組件庫的設計過程中，一定要邊做邊測試，尤其是在前期確立邏輯的時候，要不斷檢測是否真的好用。

3）內(nèi)容更新權限與維護需要專人專辦

舉例：假設我負責字體，那么后續(xù)所有的字體更新相關都只找我來修改。若其他人在組件庫內(nèi)找不到相應的組件搭建頁面而又特別高頻使用，需要向組件庫小組提出申請，并由對應組件庫管理員進行更新，不可以私自修改組件庫內(nèi)容并上傳。

04 總結

組件化思維不僅僅應用在UI領域，甚至在各行各業(yè)都需要建立組件化，比如對于一些時效性非常強的新聞產(chǎn)品，就需要針對突發(fā)事件內(nèi)容模板化，以期能第一時間發(fā)布；如果想追熱點，組件化能夠使得產(chǎn)品具備隨時跟進熱點的能力，提升市場競爭力等等。

組件化是一種思維模式，也是如今設計師必不可少的能力。通過組件庫提升效率能夠讓設計和開發(fā)有更多的時間去打磨產(chǎn)品細節(jié)，從而打造出對用戶更加友好的產(chǎn)品，賦能設計的價值。