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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 溝通、溝通、溝通

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

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

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

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

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

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

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

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

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

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

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

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

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

7 走查：將理念傳達(dá)出去

保證產(chǎn)品體驗(yàn)的一致性是我們的目標(biāo)之一，但只完成組件庫無法完全保證產(chǎn)品的一致性。因?yàn)橄嗤墓δ芸梢杂刹煌慕M件滿足，相同的組件在頁面上也可以有不同的布局。所以，將組件庫搭建出來后還遠(yuǎn)未結(jié)束，我們需要一致性走查。

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

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

8 驗(yàn)證與迭代

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

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

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

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

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

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

寫在最后

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

#專欄作家#

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

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

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