編輯導語：組件庫的搭建在一定程度上可以提高産品開發效率，減少業務流程中的疑惑産生。那麼，應該如何設計組件、快速定義B端的組件規範？本篇文章裡，作者結合自身撰寫、升級組件庫的經驗，從階段出發，對如何定義B端組件規範做了總結，一起來看一下。

各大設計團隊為了釋放設計人力，會根據業務情況封裝組件庫，後續開發成代碼，方便前端同學進行組件調取，也同時節省了開發成本。

寫這篇文章是根據自己撰寫并升級了原有組件庫的經驗，讓大家大概了解設計組件背後需要做哪些工作，日後制定組件規範可以直接套用。

一、寫組件的目的

在工作中做一件事情首先要思考做了之後要達到什麼樣的效果。寫組件的目的就是要讓每一個場景下的操作都具有合理性，讓産品變得好用、易用、可用。讓各個業務在遇到類似的業務需求時，不要産生：

1. 應該使用哪個組件？
2. 組件操作應該包含哪些狀态反饋給用戶？
3. 不同業務，同一品牌下如何保證交互一緻性？
4. 組件不能滿足應該怎麼辦？
5. ……

一系列模棱兩可的疑問。

二、寫組件的前期準備：組件結構層梳理

從層級上排列：産品——應用——頁面——模塊——組件。組件在頁面中屬于原子級的元素。

首先對團隊業務組件進行盤點、同時對比行業内競品組件，比如Ant Design、飛冰 Iceworks、Element、SUI、iView、Admui、Zent。

第一步：根據組件的作用進行分類，梳理組件清單，比如：組件分為通用類、導航類、數據輸入類、數據展示類、反饋類等。

第二步：梳理完成後劃分組件設計優先級，參考維度：

• 『我們』有 行業内有（p0）、『我們』有 行業沒有（p1）、『我們』沒有 行業有（p2）。
• 『我們』有 行業内有（p0）：代表了這類組件是解決行業内産品問題高頻應用的剛需組件，比如搜索、按鈕等。
• 『我們』有 行業沒有（p1）：代表這類組件多為業務類型組件，是業務的特殊性産生了這類組件，比如：卡片、折疊面闆等。
• 『我們』沒有 行業有（p2）：代表了這類組件可能是行業内潛在有某種業務形态，列在『我們』範圍内以免以後遇到類似的，無規範可查。

第三步：對組件進行結構層、行為層和表現層元素進行拆解，參考标準為是否常變動。

三、寫組件前期準備：行為場景梳理

其實結構層分為組件種類（導航類、按鈕類、提示類……）和組件類别（下拉菜單、頂部tab、走馬燈……）分析到現在應該得到的是原子級的組件類别，接下來就需要根據場景繼續細分組件的形态，從而得到組件形态的分類定義。

組件最難的是如何定義和區分組件行為層的類别，不斷在定義标準，目的是保證撰寫組件時，狀态不會模棱兩可，難以取舍。通過寫組件經驗分享一下我們從應用、差異化、組件構成是通過以下角度确立的标準：

• 組件應用标準：通過組件使用規律給組件下定義。
• 組件差異化：通過限定場景突出功能特點，讓用戶感知到信息操作的差異，賦予業務場景特定交互特色。
• 組件分區：通過前面梳理的，組件有哪些是常變動、哪些是不常變動的，去定義，基礎必備元素構成寫死（不可調整），基礎元素以外的内容，可以寫成活代碼（可調整）。

四、寫組件設計階段：體驗分析

規範的成立是根據多角度、多業務驗證才确定，所以需要時刻思考組件設計的邊界。在寫組件時可以思考以下6個問題：

五、寫組件設計階段：撰寫組件

通常直接浏覽的角色是：UE設計師、UI設計師、前端程序員、間接浏覽角色：産品經理、售前、後端程序員等。根據角色确定撰寫内容包含哪些結構和信息。

從輸出文檔角度舉例，可以從組件的結構層、行為層和表現層依次撰寫。

從組件業務角度舉例如：下拉菜單。

菜單内容大多是預置、後台調取、後續手動添加，所以根據業務屬性會産生多種形态。确定組件類别後，同時應要對每一個組件的類别确定必有的基礎組件狀态，比如：默認、懸停、點擊、禁用四種是每個組件都必有的狀态，其他會根據組件屬性增加。

基礎菜單：滿足菜單基本功能，單選、多選。

分組菜單：指菜單内容需要展示分類标題和内容時。

多層級菜單：指根據目标層級選擇一個或多個的選項。

以上内容僅此舉例，希望能給大家在寫組件時帶來更多的思路。

本文由@石果果 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部