组件|如何快速定义一款B端的组件规范？

编辑导语：组件库的搭建在一定程度上可以提高产品开发效率，减少业务流程中的疑惑产生。那么，应该如何设计组件、快速定义B端的组件规范？本篇文章里，作者结合自身撰写、升级组件库的经验，从阶段出发，对如何定义B端组件规范做了总结，一起来看一下。

文章插图
各大设计团队为了释放设计人力，会根据业务情况封装组件库，后续开发成代码，方便前端同学进行组件调取，也同时节省了开发成本。
【组件|如何快速定义一款B端的组件规范？】写这篇文章是根据自己撰写并升级了原有组件库的经验，让大家大概了解设计组件背后需要做哪些工作，日后制定组件规范可以直接套用。
一、写组件的目的在工作中做一件事情首先要思考做了之后要达到什么样的效果。写组件的目的就是要让每一个场景下的操作都具有合理性，让产品变得好用、易用、可用。让各个业务在遇到类似的业务需求时，不要产生：

应该使用哪个组件？
组件操作应该包含哪些状态反馈给用户？
不同业务，同一品牌下如何保证交互一致性？
组件不能满足应该怎么办？
……

一系列模棱两可的疑问。
二、写组件的前期准备：组件结构层梳理从层级上排列：产品——应用——页面——模块——组件。组件在页面中属于原子级的元素。
首先对团队业务组件进行盘点、同时对比行业内竞品组件，比如Ant Design、飞冰 Iceworks、Element、SUI、iView、Admui、Zent。
第一步：根据组件的作用进行分类，梳理组件清单，比如：组件分为通用类、导航类、数据输入类、数据展示类、反馈类等。
第二步：梳理完成后划分组件设计优先级，参考维度：

『我们』有+行业内有（p0）、『我们』有+行业没有（p1）、『我们』没有+行业有（p2）。
『我们』有+行业内有（p0）：代表了这类组件是解决行业内产品问题高频应用的刚需组件，比如搜索、按钮等。
『我们』有+行业没有（p1）：代表这类组件多为业务类型组件，是业务的特殊性产生了这类组件，比如：卡片、折叠面板等。
『我们』没有+行业有（p2）：代表了这类组件可能是行业内潜在有某种业务形态，列在『我们』范围内以免以后遇到类似的，无规范可查。

第三步：对组件进行结构层、行为层和表现层元素进行拆解，参考标准为是否常变动。

文章插图
三、写组件前期准备：行为场景梳理其实结构层分为组件种类（导航类、按钮类、提示类……）和组件类别（下拉菜单、顶部tab、走马灯……）分析到现在应该得到的是原子级的组件类别，接下来就需要根据场景继续细分组件的形态，从而得到组件形态的分类定义。

文章插图
组件最难的是如何定义和区分组件行为层的类别，不断在定义标准，目的是保证撰写组件时，状态不会模棱两可，难以取舍。通过写组件经验分享一下我们从应用、差异化、组件构成是通过以下角度确立的标准：

组件应用标准：通过组件使用规律给组件下定义。
组件差异化：通过限定场景突出功能特点，让用户感知到信息操作的差异，赋予业务场景特定交互特色。
组件分区：通过前面梳理的，组件有哪些是常变动、哪些是不常变动的，去定义，基础必备元素构成写死（不可调整），基础元素以外的内容，可以写成活代码（可调整）。