本文從業務組件庫構成、如何構建業務組件庫、為什么要做這些、如何評估組件有效性4個方面，掌握業務組件庫設計。

組件干貨：

一、業務組件庫構成

1. 組件概述

1. 基礎原子組件
2. 原子組成的分子組件
3. 分子組成的區塊組件（組織）
4. 區塊組件構成的模板組件
5. 由模版組成的成套頁面

現在可以把我們的組件庫想象成樂高，每一個小零件組合成一個新的大零件，在由大零件組合成一個面狀零件，直至完成一個模型。在完成這些后，我們會發現缺少了一個地基以供模型合理擺放：

小知識：業務組件庫的原子分子，可以由任意組件庫構成，如 Ant design、Tdesign、Arco design 等等（沒必要重復造輪子）

2. 組件概述：柵格布局（地基）

柵格布局又是地基，所以我們會將該步驟作為搭建組件庫的第一步驟，以更好的幫助我們計算每個組件的尺寸（小到原子大到區塊組件）。

這也是我們經常說的規范驗收，間距、尺寸、圓角、樣式等等，柵格布局也能更好的適配自適應規則。

補充：假設是一個成熟的產品，因為一些情況需要調整布局，這里可以反向推導：

1. 確定設計稿的頁面尺寸
2. 確定區塊組件的大小
3. 確定布局間隙是否一致
4. 確定左側導航具體寬度

確定容器柵格：

柵格線基本以 24 條為例，那么對應的水槽線（間隙）則為 23 條。確定水槽線的寬度（全局通用包含橫向縱向且能夠被整除的）

這時候組件可以根據柵格布局進行合理擺放位置，并且在規范內，設計好盒子框架，以便開發做好自適應斷點規則。

二、如何構建業務組件庫

不知道各位有沒有在 B 端業務產品中，遇到很多同類似的組件，在相同的業務場景中，用了不同的交互方式，并且還被問到了：“為什么這里的組件和其他地方樣式及交互不一樣，結果卻是一致？”這時候你會怎么去說服提問者？

對于我看來，會出現這種情況得原因，我總結以下三點：

1. 缺乏組件庫的使用規范及標準
2. 在個業務頁面中，邏輯梳理的方式與其他設計師不同
3. 組件的變種樣式沒有得到組內一致對齊

那么我們如何做才能解決該類似的問題呢？

1. 提取每個頁面被高頻使用的相似控件

第一步，走查其中 A 平臺所有相似組件，并記錄

第二步，走查所有平臺中所有相似組件，并記錄

第三步，將單一平臺和所有平臺的相似組件進行抽離擺放

第四步，定義組件的形式（擴展性組件、樣式相同交互卻不同、交互相同樣式卻不同）

2. 分析每個相似的控件解決的目的是什么

以上文（一）舉例：我們將這兩種業務定義為分為相似組件后，分析每個組件所對應的業務場景；

方案 1 的對應業務場景：在填寫表單頁面中幫助使用者呈現更加具體描述的信息，從而幫助使用者快速進行做出選擇。

方案 2 的對應業務場景：通常應用在配置頁面中，幫助用戶直觀的進行定位選擇。

3. 拆分區塊組件，并定義每個組件用途及業務場景

假設：相同組件下，樣式不統一，并在團隊內部起到了爭議，我們該如何進行 battle

舉例如上圖。

通過走查發現，使用方案 2 的組件在團隊內部占據多數，此時你該如何說服他們進行統一?

1. 可以通過使用組件的時間進行比對：舉例查找某 8 個省份及 8 個城市進行各自選擇后的總時間
2. 可以通過使用組件的效率進行比對：組件選擇進行重置后，在選擇 4 個 相同省份城市名稱及 4 個不同的

這是比較常規的判斷方式，并且可以通過擴展性的維度去考量。

4. 對拆分的區塊逐一進行用途描述

可以拆分區塊進對功能描述也可以拆分組件進行描述，在團隊進行講解，形成規范一致性。便于后續對某組件進行擴展或功能替換。

5. 在盒子內重構布局，形成規范排版

6. 補充條件規則

1. 響應式規則
2. 浮層、彈窗、抽屜使用規則
3. 操作區布局規則
4. 柵格規則
5. 驗收規則
6. 組件交互使用說明規則

三、為什么要做這些

1. 所有的組件可以在標準范圍內自然增長

什么是自然生長，就是一個組件隨著業務場景的增多，也會隨之匹配著業務進行變種升級，不會偏離基礎組件的設計。

所以滿足自然生長，就得確定業務組件能夠被擴展，而不是定樣式。

2. 控件的變種得到有效統一控制

3. 基于底層可以優化迭代，減少重復溝通交流

不知道各位同學，有沒有遇到過，某一個組件用了一段時間，突然這時，你靈光一現，發現這個組件并不是很契合，你畫完圖去找前端改一改組件。這時開發說，不行，太麻煩了，我手上還有其他活，沒辦法做全量替換，一個個又太麻煩了，你等下一個排期吧。諸如此類的拒絕話術。

此時如果，有業務組件庫，那么優勢也被突出出來，在底層中進行優化迭代，并且全量替換，咱們只需要走查一下布局有沒有沖突等問題就行

4. 驗收標準得到可控，減少多人多面驗收意見

四、如何評估組件有效性

我們所做的組件如何才能被定義為是合格或有用的呢？這里我會從 2 個方面去做闡述

1. 組件本身的效率

在 B 端場景中，我們通常判斷為是工作業務場景，即 效率性，也就是常說的提效，我們回歸本質，一方面是頁面的排版布局、功能交互時長，另一方面是用戶的認知理解時長。

還是以選擇城市舉例：（僅說組件測試，當然頁面也能夠被衡量）

以這種小測試的方法，不限于人，不限于組件，提升團隊的專業性。對比兩者使用時長（秒表卡點）

2. 系統層面的效率性

在面對繁雜的業務場景中，使用了新的設計組件，是否能夠完美匹配或者靈活匹配，去幫助業務去降低用戶理解的成本。

組件拼裝的模版頁面，是否降低重復開發的成本。

是否具有代表性的組件可以全平臺通用

五、總結

歡迎關注作者微信公眾號：交互思維鋪子