更高效的溝通、更迅速的開發(fā)、更一致的體驗……諸多優(yōu)點讓組件庫的搭建在近幾年流行起來。甚至一些大廠的組件體系已非常成熟，如Ant Design，WeUI等等。成熟的組件庫對產(chǎn)品體驗確實有肉眼可見的提升。如果你也想為團隊搭建一個組件庫，希望以下內(nèi)容能幫到你。Enjoy~

產(chǎn)品、組件與設(shè)計規(guī)范

組件庫簡單來說就是一些積木，而產(chǎn)品相當于成品模型。我們可以根據(jù)業(yè)務(wù)需求，以“搭積木”的方式，讓“模型”快速落地。而“搭積木”過程中并不是隨心所欲，至少需要看一看“使用說明”，而這“使用說明”就是設(shè)計規(guī)范。產(chǎn)品、組件和規(guī)范差不多就是這樣的關(guān)系。

至于為什么要搭建組件庫，怎么去搭建組件庫，網(wǎng)上已有很多相關(guān)文章，也有非常系統(tǒng)的方法，在此給大家推薦一本書《設(shè)計體系》。國內(nèi)也有大神翻譯過此書，翻譯得很棒，推薦給大家：鏈接。

而近段時間，正參與一個體量較大的B端項目，負責(zé)其中財務(wù)模塊的交互設(shè)計以及產(chǎn)品的組件庫搭建。目前組件庫已經(jīng)基本搭建完成，能覆蓋70%+的業(yè)務(wù)場景，團隊效率大大提升的同時保障了產(chǎn)品體驗的一致性。藉此機會，我想分享一下在搭建組件庫這個項目中的一些心得。

1 絕不是設(shè)計師就能搞定的事

其實在這個項目之前，我也嘗試過梳理出一些所負責(zé)的產(chǎn)品的組件和規(guī)范，以便日后有新需求時可以參考復(fù)用，不必重復(fù)造輪子。但設(shè)計規(guī)范基本很少人看，然后就一直靜靜地躺在文件夾里。我也曾經(jīng)在Sketch上做了很多Symbol，推廣團隊內(nèi)部用起來，從而提高畫稿的效率和一致性。但交付開發(fā)同學(xué)后，不同的開發(fā)依然會對每個組件都要重新寫一遍。

現(xiàn)在回頭一想，出現(xiàn)這種情況，原因也很簡單：以前梳理的組件沒有開發(fā)落地，只是一張圖紙，并不是實打?qū)嵉慕M件。

所以搭建組件絕不是設(shè)計師就能搞定的事情。而且開發(fā)應(yīng)作為核心的主力之一，我們的輸出物應(yīng)該是開發(fā)的代碼，真正地在代碼層實現(xiàn)拖拽組件就能搭建界面原型，而不是Sketch上的Symbol。只停留在紙面上的組件和規(guī)范，其實意義不大。

或許搭建組件庫這事情會讓人興奮不已，巴不得馬上擼起袖子開干。但在此之前，是否有開發(fā)的支持、設(shè)計與開發(fā)是否達成共識、大家是否愿意并肩作戰(zhàn)，是我們首要解決的難題。

2 要搞明白面向的對象是誰

以我的項目為例，面向的是設(shè)計師、前端開發(fā)和產(chǎn)品經(jīng)理這三個群體，而這三個群體對組件庫的需求是截然不同的。設(shè)計師希望能了解到組件庫的使用規(guī)范、適用場景、拓展方案等等；產(chǎn)品經(jīng)理希望知道新的業(yè)務(wù)需求可以拿什么組件完成，組件是否能滿足業(yè)務(wù)場景等等 ；開發(fā)更關(guān)心的是組件的接口、方法、屬性等等。這樣一梳理下來，就可明確輸出物應(yīng)該包含什么內(nèi)容、如何呈現(xiàn)、需協(xié)調(diào)哪些資源來完成。

3 不要套用模板、每個細節(jié)都值得思考

在設(shè)計之前我們會參考一下競品如：Material Design、Ant Design、WeUI……，看看他們?nèi)绾畏诸?、如何命名、如何定義等等。為了趕進度，我們也曾套用了一些模板，為自己埋下了不少坑。比如組件的分類，一個搜索組件，有的會將其歸為操作類，有的將其歸為導(dǎo)航類、基礎(chǔ)類、輸入類等等。為了方便我們直接參考了競品的分類方法，簡單粗暴地將其歸為輸入類。一開始并不覺得有什么不妥，但后來發(fā)現(xiàn)難以應(yīng)對的各種挑戰(zhàn)也隨之而來。

比如，在之后的動效庫項目中，我們希望輸入類組件應(yīng)減少動效，避免過多的動效打擾用戶。但同時又覺得搜索組件應(yīng)該加上動效，能給予用戶更清晰的引導(dǎo)。這時我們陷入了問題的漩渦中：如何解釋同類的組件為什么會有截然不同的動效屬性？動效的規(guī)范又如何定義？為什么搜索會被歸為輸入類組件？……一系列問題被引發(fā)出來。這就是我們在分類組件時思考不到位所帶來的結(jié)果。

總之，今天不假思索套用的模板，會成為日后需要不斷填的坑。越基礎(chǔ)的東西越影響全局，牽一發(fā)而動全身。

4 事先應(yīng)了解技術(shù)限制

開發(fā)在實現(xiàn)組件時都會基于一些現(xiàn)有框架，不會去重復(fù)造輪子。例如，螞蟻的Ant Design 基于 React 框架，有贊的 Zant 基于 VUE 框架。技術(shù)選型看似對設(shè)計影響不大。但到了要落地的時候，開發(fā)同學(xué)的一句“框架不支持”，能直接將你的設(shè)計打回原形。框架不支持就需要改框架，不是開發(fā)同學(xué)不做到，是真的需要很長時間。在設(shè)計的時候提前了解到開發(fā)的限制，會讓我們少走彎路。

5 溝通、溝通、溝通

我認為，溝通協(xié)調(diào)是搭建組件庫中最大的挑戰(zhàn)之一：收集各個模塊的產(chǎn)品經(jīng)理、前端開發(fā)、后端開發(fā)、視覺設(shè)計的意見和建議，建立評審機制，傳達設(shè)計思路，統(tǒng)一設(shè)計方案……

每個角色都會在各自立場對組件提出不同意見。例如，針對篩選組件：

• 視覺設(shè)計師希望：“樣式布局應(yīng)該是清晰有規(guī)律的，否則用戶難以尋找信息?！?/li>
• 交互設(shè)計師希望：“在用戶感知層面應(yīng)盡快地讓用戶辨認出所需的篩選項，而不是每次都需要花時間尋找。”
• 負責(zé)財務(wù)模塊的產(chǎn)品經(jīng)理希望：“時間的篩選對于財務(wù)人員來說幾乎每天都需要用到，這個應(yīng)該強調(diào)?！?/li>
• 負責(zé)業(yè)務(wù)模塊的產(chǎn)品經(jīng)理希望：“業(yè)務(wù)的篩選場景非常個性化，一個固定的模式必然遭用戶吐槽，最好有用戶自定義的功能?！?/li>
• 開發(fā)希望：“維護的成本太高，無論在什么場景下都應(yīng)該是統(tǒng)一的組件，統(tǒng)一的邏輯?！?/li>
• ……

涉及這么多利益相關(guān)方的討論，不可能一次兩次就可以解決。必須反復(fù)溝通，甚至能在溝通7次之后達成共識已經(jīng)是不錯的結(jié)果。有時候我們設(shè)計師會覺得，好不容易想出一個方案，被如此評頭品足，還要推到重來，非常不爽。

仔細想想，自己的眼界往往是局限的，不可能完全了解用戶在各個模塊下，各個狀態(tài)下的使用場景。其他角色的輸出其實非常有價值。不抵觸意見，接納各種思想，抽象提煉關(guān)鍵設(shè)計點，才能推導(dǎo)出大家認可的解決方案。

6 艱難的抉擇：業(yè)務(wù)獨特性與組件一致性的沖突

當組件和規(guī)范已有雛形，投入使用的時候，新的問題又來了：我們應(yīng)該在什么時候放棄規(guī)范，什么時候堅持規(guī)范？

除了負責(zé)組件庫項目，我還是其他產(chǎn)品模塊的設(shè)計師。這讓我陷入了兩難：一方面我想保證整體產(chǎn)品的一致性，盡量不打破原有的規(guī)則去設(shè)計，盡量使用組件覆蓋業(yè)務(wù)需求；但另一方面，在一些特殊的業(yè)務(wù)場景下，不使用組件的設(shè)計方案會有更好的體驗。這樣的兩難困境會經(jīng)常遇到，業(yè)務(wù)的特殊性和組件的一致性很難共存。

以下總結(jié)了幾點小建議可以分享給大家：

第一，影響全局的組件調(diào)整，建議遵循規(guī)范。比如，不可能因為一個特殊的業(yè)務(wù)去改變 導(dǎo)航結(jié)構(gòu)，一旦改變，其他業(yè)務(wù)都會受到牽連，得不償失。除非在一個大版本迭代中，全局考慮一并調(diào)整。

第二，用戶感知弱的優(yōu)化，建議遵循規(guī)范。比如，為了讓用戶能在一個頁面內(nèi)閱讀更多信息，想去改變表格的行高 ，但調(diào)整后也就省了一行的高度。這種改變，用戶的感知是很弱的，反而會增大開發(fā)維護的工作量。

第三，符合規(guī)范不是思考的起點。如果組件體系運行地還順暢，我們就有可能產(chǎn)生依賴，一上來就規(guī)規(guī)矩矩地依照規(guī)范設(shè)計頁面。而這往往是設(shè)計的禁區(qū)，組件和規(guī)范是效率工具，不應(yīng)該成為我們創(chuàng)新的枷鎖。我們思考的起點永遠是用戶、場景和目標。設(shè)計規(guī)范只是在最后幫我們扶正一下，哪些可以復(fù)用組件，哪些可以跟規(guī)范走。

第四，不認死理，規(guī)范就應(yīng)該不斷迭代。如果發(fā)現(xiàn)我們的組件和規(guī)范能覆蓋的場景非常有限，就應(yīng)該去迭代它們，而不是強行地套規(guī)范來設(shè)計。

7 走查：將理念傳達出去

保證產(chǎn)品體驗的一致性是我們的目標之一，但只完成組件庫無法完全保證產(chǎn)品的一致性。因為相同的功能可以由不同的組件滿足，相同的組件在頁面上也可以有不同的布局。所以，將組件庫搭建出來后還遠未結(jié)束，我們需要一致性走查。

一致性走查，能規(guī)范現(xiàn)有頁面的同時，也能在上下游對接中傳達一致性的理念。比如，在開發(fā)修改的時候，我們可向他們傳達：主要按鈕次要按鈕的用法是怎樣的、什么時候應(yīng)該用復(fù)選框、什么時候應(yīng)該用開關(guān)等等。因為他們未必有時間去查看設(shè)計規(guī)范，面對面的傳達更加有效。

另外，B端產(chǎn)品體量太大，不可能每個頁面都有設(shè)計資源支持。不少頁面并沒有經(jīng)過設(shè)計就直接開發(fā)。所以走查的目的不僅是把問題改好，而是將一致性的理念和設(shè)計規(guī)范傳達出去。如此一來，在面對新的業(yè)務(wù)需求時，大家才會更快得把事情做好。

8 驗證與迭代

對組件所做的每一個優(yōu)化，都是基于用戶和場景的假設(shè)，可能正中用戶下懷，也有可能是一廂情愿。我們的優(yōu)化需要經(jīng)得起用戶和市場的驗證，于是對組件庫進行了多次可用性測試。而每一次測試都會有意外發(fā)現(xiàn)。比如一些我們理所應(yīng)當?shù)牟僮?，用戶根本理解不了。又或是我們精心打磨的細?jié)，用戶其實毫不在意。所以驗證-迭代是組件庫不可或缺的環(huán)節(jié)，同時也是一個反復(fù)而漫長的過程。

9 創(chuàng)新總在矛盾中產(chǎn)生

組件庫的難點在于需要解決各種矛盾：業(yè)務(wù)特殊性與組件通用性的矛盾、易用性與復(fù)雜度的矛盾、設(shè)計設(shè)想與開發(fā)實現(xiàn)的矛盾、各產(chǎn)品線間的需求矛盾等等。有時會陷入這些矛盾中無法繞出來，甚至矛盾是無解的，只能折中方案。

但機會與困境總是并存的，在我們的項目中，幾乎所有的創(chuàng)新點都在矛盾中產(chǎn)生，有的還申請了專利。所以，擁抱矛盾，機會一直在我們眼前。

10 要為產(chǎn)品負責(zé)

組件庫雖然是從出業(yè)務(wù)層抽離出來的東西，但其宗旨依然是服務(wù)業(yè)務(wù)。我們很容易迷失在一個個組件中，忘記業(yè)務(wù)的真實場景是什么、真實用戶是誰，很容易一味地追求組件和規(guī)范本身的邏輯自洽，卻忽略用戶的實際感知。比如，我們嚴格區(qū)分了按鈕和鏈接的區(qū)別，按鈕適用于某個功能的觸發(fā)，而鏈接隱喻著頁面跳轉(zhuǎn)。但用戶是否會這樣理解？有這樣的感知？還是對于他們來說都是可點擊的東西而已？組件和規(guī)范不應(yīng)限死所有邏輯，我們的目的不是自圓其說，而是真切地對產(chǎn)品有幫助，對用戶有幫助。

寫在最后

通篇看下來之后，你可能會覺得，這不就跟平時的產(chǎn)品設(shè)計思路差不多嘛。是的，組件庫就是一個產(chǎn)品。每個產(chǎn)品都值得我們細心經(jīng)營、用心打磨。Thanks~

#專欄作家#

Genrry，公眾號：設(shè)計師阿余，人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注用戶體驗，擅長多端交互設(shè)計、界面設(shè)計。曾負責(zé)大型B端產(chǎn)品及VR游戲產(chǎn)品體驗設(shè)計，制定設(shè)計規(guī)范，打磨細節(jié)體驗，探索創(chuàng)新交互體驗。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議