起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識關于搭建組件庫的10點心得
更高效的溝通、更迅速的開發、更一致的體驗……諸多優點讓組件庫的搭建在近幾年流行起來。甚至一些大廠的組件體系已非常成熟，如Ant Design，WeUI等等。成熟的組件庫對產品體驗確實有肉眼可見的提升。如果你也想為團隊搭建一個組件庫，希望以下內容能幫到你。Enjoy~
產品、組件與設計規范
組件庫簡單來說就是一些積木，而產品相當于成品模型。我們可以根據業務需求，以“搭積木”的方式，讓“模型”快速落地。而“搭積木”過程中并不是隨心所欲，至少需要看一看“使用說明”，而這“使用說明”就是設計規范。產品、組件和規范差不多就是這樣的關系。
至于為什么要搭建組件庫，怎么去搭建組件庫，網上已有很多相關文章，也有非常系統的方法，在此給大家推薦一本書《設計體系》。國內也有大神翻譯過此書，翻譯得很棒，推薦給大家：鏈接。
而近段時間，正參與一個體量較大的B端項目，負責其中財務模塊的交互設計以及產品的組件庫搭建。目前組件庫已經基本搭建完成，能覆蓋70%+的業務場景，團隊效率大大提升的同時保障了產品體驗的一致性。藉此機會，我想分享一下在搭建組件庫這個項目中的一些心得。
1 絕不是設計師就能搞定的事
其實在這個項目之前，我也嘗試過梳理出一些所負責的產品的組件和規范，以便日后有新需求時可以參考復用，不必重復造輪子。但設計規范基本很少人看，然后就一直靜靜地躺在文件夾里。我也曾經在Sketch上做了很多Symbol，推廣團隊內部用起來，從而提高畫稿的效率和一致性。但交付開發同學后，不同的開發依然會對每個組件都要重新寫一遍。
現在回頭一想，出現這種情況，原因也很簡單：以前梳理的組件沒有開發落地，只是一張圖紙，并不是實打實的組件。
所以搭建組件絕不是設計師就能搞定的事情。而且開發應作為核心的主力之一，我們的輸出物應該是開發的代碼，真正地在代碼層實現拖拽組件就能搭建界面原型，而不是Sketch上的Symbol。只停留在紙面上的組件和規范，其實意義不大。
或許搭建組件庫這事情會讓人興奮不已，巴不得馬上擼起袖子開干。但在此之前，是否有開發的支持、設計與開發是否達成共識、大家是否愿意并肩作戰，是我們首要解決的難題。
2 要搞明白面向的對象是誰
以我的項目為例，面向的是設計師、前端開發和產品經理這三個群體，而這三個群體對組件庫的需求是截然不同的。設計師希望能了解到組件庫的使用規范、適用場景、拓展方案等等；產品經理希望知道新的業務需求可以拿什么組件完成，組件是否能滿足業務場景等等 ；開發更關心的是組件的接口、方法、屬性等等。這樣一梳理下來，就可明確輸出物應該包含什么內容、如何呈現、需協調哪些資源來完成。
3 不要套用模板、每個細節都值得思考
在設計之前我們會參考一下競品如：Material Design、Ant Design、WeUI……，看看他們如何分類、如何命名、如何定義等等。為了趕進度，我們也曾套用了一些模板，為自己埋下了不少坑。比如組件的分類，一個搜索組件，有的會將其歸為操作類，有的將其歸為導航類、基礎類、輸入類等等。為了方便我們直接參考了競品的分類方法，簡單粗暴地將其歸為輸入類。一開始并不覺得有什么不妥，但后來發現難以應對的各種挑戰也隨之而來。
比如，在之后的動效庫項目中，我們希望輸入類組件應減少動效，避免過多的動效打擾用戶。但同時又覺得搜索組件應該加上動效，能給予用戶更清晰的引導。這時我們陷入了問題的漩渦中：如何解釋同類的組件為什么會有截然不同的動效屬性？動效的規范又如何定義？為什么搜索會被歸為輸入類組件？……一系列問題被引發出來。這就是我們在分類組件時思考不到位所帶來的結果。
總之，今天不假思索套用的模板，會成為日后需要不斷填的坑。越基礎的東西越影響全局，牽一發而動全身。
4 事先應了解技術限制
開發在實現組件時都會基于一些現有框架，不會去重復造輪子。例如，螞蟻的Ant Design 基于 React 框架，有贊的 Zant 基于 VUE 框架。技術選型看似對設計影響不大。但到了要落地的時候，開發同學的一句“框架不支持”，能直接將你的設計打回原形?？蚣懿恢С志托枰目蚣?，不是開發同學不做到，是真的需要很長時間。在設計的時候提前了解到開發的限制，會讓我們少走彎路。
5 溝通、溝通、溝通
我認為，溝通協調是搭建組件庫中最大的挑戰之一：收集各個模塊的產品經理、前端開發、后端開發、視覺設計的意見和建議，建立評審機制，傳達設計思路，統一設計方案……
每個角色都會在各自立場對組件提出不同意見。例如，針對篩選組件：
- 視覺設計師希望：“樣式布局應該是清晰有規律的，否則用戶難以尋找信息。”
- 交互設計師希望：“在用戶感知層面應盡快地讓用戶辨認出所需的篩選項，而不是每次都需要花時間尋找?！?/li>
- 負責財務模塊的產品經理希望：“時間的篩選對于財務人員來說幾乎每天都需要用到，這個應該強調?！?/li>
- 負責業務模塊的產品經理希望：“業務的篩選場景非常個性化，一個固定的模式必然遭用戶吐槽，最好有用戶自定義的功能?！?/li>
- 開發希望：“維護的成本太高，無論在什么場景下都應該是統一的組件，統一的邏輯?！?/li>
- ……
涉及這么多利益相關方的討論，不可能一次兩次就可以解決。必須反復溝通，甚至能在溝通7次之后達成共識已經是不錯的結果。有時候我們設計師會覺得，好不容易想出一個方案，被如此評頭品足，還要推到重來，非常不爽。
仔細想想，自己的眼界往往是局限的，不可能完全了解用戶在各個模塊下，各個狀態下的使用場景。其他角色的輸出其實非常有價值。不抵觸意見，接納各種思想，抽象提煉關鍵設計點，才能推導出大家認可的解決方案。
6 艱難的抉擇：業務獨特性與組件一致性的沖突
當組件和規范已有雛形，投入使用的時候，新的問題又來了：我們應該在什么時候放棄規范，什么時候堅持規范？
除了負責組件庫項目，我還是其他產品模塊的設計師。這讓我陷入了兩難：一方面我想保證整體產品的一致性，盡量不打破原有的規則去設計，盡量使用組件覆蓋業務需求；但另一方面，在一些特殊的業務場景下，不使用組件的設計方案會有更好的體驗。這樣的兩難困境會經常遇到，業務的特殊性和組件的一致性很難共存。
以下總結了幾點小建議可以分享給大家：
第一，影響全局的組件調整，建議遵循規范。比如，不可能因為一個特殊的業務去改變 導航結構，一旦改變，其他業務都會受到牽連，得不償失。除非在一個大版本迭代中，全局考慮一并調整。
第二，用戶感知弱的優化，建議遵循規范。比如，為了讓用戶能在一個頁面內閱讀更多信息，想去改變表格的行高 ，但調整后也就省了一行的高度。這種改變，用戶的感知是很弱的，反而會增大開發維護的工作量。
第三，符合規范不是思考的起點。如果組件體系運行地還順暢，我們就有可能產生依賴，一上來就規規矩矩地依照規范設計頁面。而這往往是設計的禁區，組件和規范是效率工具，不應該成為我們創新的枷鎖。我們思考的起點永遠是用戶、場景和目標。設計規范只是在最后幫我們扶正一下，哪些可以復用組件，哪些可以跟規范走。
第四，不認死理，規范就應該不斷迭代。如果發現我們的組件和規范能覆蓋的場景非常有限，就應該去迭代它們，而不是強行地套規范來設計。
7 走查：將理念傳達出去
保證產品體驗的一致性是我們的目標之一，但只完成組件庫無法完全保證產品的一致性。因為相同的功能可以由不同的組件滿足，相同的組件在頁面上也可以有不同的布局。所以，將組件庫搭建出來后還遠未結束，我們需要一致性走查。
一致性走查，能規范現有頁面的同時，也能在上下游對接中傳達一致性的理念。比如，在開發修改的時候，我們可向他們傳達：主要按鈕次要按鈕的用法是怎樣的、什么時候應該用復選框、什么時候應該用開關等等。因為他們未必有時間去查看設計規范，面對面的傳達更加有效。
另外，B端產品體量太大，不可能每個頁面都有設計資源支持。不少頁面并沒有經過設計就直接開發。所以走查的目的不僅是把問題改好，而是將一致性的理念和設計規范傳達出去。如此一來，在面對新的業務需求時，大家才會更快得把事情做好。
8 驗證與迭代
對組件所做的每一個優化，都是基于用戶和場景的假設，可能正中用戶下懷，也有可能是一廂情愿。我們的優化需要經得起用戶和市場的驗證，于是對組件庫進行了多次可用性測試。而每一次測試都會有意外發現。比如一些我們理所應當的操作，用戶根本理解不了。又或是我們精心打磨的細節，用戶其實毫不在意。所以驗證-迭代是組件庫不可或缺的環節，同時也是一個反復而漫長的過程。
9 創新總在矛盾中產生
組件庫的難點在于需要解決各種矛盾：業務特殊性與組件通用性的矛盾、易用性與復雜度的矛盾、設計設想與開發實現的矛盾、各產品線間的需求矛盾等等。有時會陷入這些矛盾中無法繞出來，甚至矛盾是無解的，只能折中方案。
但機會與困境總是并存的，在我們的項目中，幾乎所有的創新點都在矛盾中產生，有的還申請了專利。所以，擁抱矛盾，機會一直在我們眼前。
10 要為產品負責
組件庫雖然是從出業務層抽離出來的東西，但其宗旨依然是服務業務。我們很容易迷失在一個個組件中，忘記業務的真實場景是什么、真實用戶是誰，很容易一味地追求組件和規范本身的邏輯自洽，卻忽略用戶的實際感知。比如，我們嚴格區分了按鈕和鏈接的區別，按鈕適用于某個功能的觸發，而鏈接隱喻著頁面跳轉。但用戶是否會這樣理解？有這樣的感知？還是對于他們來說都是可點擊的東西而已？組件和規范不應限死所有邏輯，我們的目的不是自圓其說，而是真切地對產品有幫助，對用戶有幫助。
寫在最后
通篇看下來之后，你可能會覺得，這不就跟平時的產品設計思路差不多嘛。是的，組件庫就是一個產品。每個產品都值得我們細心經營、用心打磨。Thanks~
#專欄作家#
Genrry，公眾號：設計師阿余，人人都是產品經理專欄作家。關注用戶體驗，擅長多端交互設計、界面設計。曾負責大型B端產品及VR游戲產品體驗設計，制定設計規范，打磨細節體驗，探索創新交互體驗。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
很棒，謝謝阿余。
Zant還是Vant呀
是Vant，感謝指正~
也謝謝你啦 讓我開始了解一個新的組件庫
很專業，基本把推進組件化的坑都提出來了。能夠感受到難度之大，一旦有規范化的執行，對團隊效率肯定是大大的提升。