这两天有 B 端新学员问项目中如果产品选用了第三方的组件库，且给的组件产品原型非常完整（比如下图这样） ，那设计师后面应该做什么，计师怎么体现设计的设计价值 ？

设计师在 B 端项目的核心产出包括两个部分：交互设计和组件库 ，它们的现成深入定义都只能由设计师来完成。而我们今天的组件主题 ，就要围绕上周分享的计师组件库系列做进一步的推进，分享 B 端组件库的设计定义思路和原则。

一 、都用端设B 端组件库是现成什么

创建 B 端组件库 ，就需要了解 B 端组件库是组件什么。而在今天不同语境下，计师对 B 端组件库的设计定义是不同的，包含下面几种情况
：

1. 线上发布的第三方开发组件库
2. 包含样式
   、布局 、组件的项目设计规范
3. 用于在软件中进行引用的组件库文件

第一种情况，是由其它团队开发并发布的前端组件框架 ，比如大家熟悉的 AntDesign、TDesign 
、Elements 等组件库。

这些组件库的核心是已经开发好的前端样式代码 ，让其它程序员可以轻易使用它们搭建自己的项目。简单解释就是提供一套模板 ，直接用这套模板 “复制粘贴、修修补补” 就可以做一套新项目出来，节省大量的编程时间。

但因为直接看代码了解它包含哪些内容很没有效率 ，所以这些组件库会提供额外的材料帮助用户理解和使用，而这些材料主要包含三个部分
：

1. 设计说明 ：解释代码内包含的样式、版式、组件内容 。
2. 设计素材：提供代码中包含的样式、组件的设计源文件 。
3. 开发文档：用于解释这套代码的结构、语法 、使用规则
    。

这些第三方组件库是用于提供给其它用户（主要是程序员）使用的产品，它提供的所有材料都可以理解成是这套产品的使用手册 ，用于解释这套产品的内容和使用方法。至于用户想要用它做什么，它就不负责了。

第二种情况，组件库泛指项目中的整体设计规范 。包含对设计样式的定义，版式布局的规范 ，以及控件 、组件的整理和说明。

这就要延续上一种情况的讨论 ，如果项目使用了第三方组件库 ，还有没有项目规范
？当然是肯定的。

因为第三方组件库提供的设计规范只是说明书，它没有规范设计师在项目中应该用什么配色，什么圆角，什么按钮，什么表格布局，设计师依旧要针对项目制定出具体的规范
。

比如样式部分 ，组件库通常会先整理出一套色卡
，包含数百种颜色
，我们不可能在项目中全部用上。所以就算使用它们，也得确定出项目应用的品牌色、功能色的具体色号。

再到组件部分，组件库往往会给同一种组件提供非常多的样式变体  ，我们也需要从中选出项目适用的规格加以限制。

并且一些复杂组件，如筛选、表单 、表格等 ，大概率组件库内的样式是无法满足项目的真实需求 ，所以要在原有基础上做出二次设计，而新的组件自然也要成为规范的一部分整理进来。

这些都只是最基础的设计要求，可以高效的输出“能用”的结果，即使是一个产品经理还是纯交互设计师都可以轻松完成（就像开头原型案例）
。但如果项目对设计要求高，那么这种产出是没有说服力的，设计师要在这个基础上做出更有设计感的结果。

比如侧边栏 ，官方组件库只有非常基础的样式，但不代表设计上它只能长成这样 。对专业设计师来说还有很多的样式发挥空间 ：

而这些自定义设计，也是项目规范的一部分。不管团队有没有使用第三方组件库，项目规范、组件库都需要进行整理
。如果设计师自己对这个原理都没有明白的话
，自然不知道拿到完整原型以后还能做什么 ，以及自己在团队中还有什么价值。

第三种情况
，则是指软件当中创建的用于引用的组件库文件
。比如 iOS 、Material 、Ant 等组件库。引用它们就可以在其它设计文件中，直接调用对应的组件 Component。

组件库也包含官方/第三方组件库和项目组件库 ，而项目组件库是设计规范的一部分，往往跟随项目规范定义过程一起创建 。

这种项目组件库的创建为了满足界面设计和项目协作的需要 ，要耗费设计师非常多的精力 ，对设计师的经验和实践能力也有较高的要求
。

理解以上三种组件库的类型 ，是搭建组件库的第一步。而对于一般设计师而言 ，主要的目标就是学会如何搭建项目设计规范和专属的组件库文件 。

二、组件库的创建流程

设计师制作组件库要面对的首要难题，就是组件库在项目的什么阶段创建以及具体创建的流程是什么
。

这就要先考虑是先有界面还是先有规范的问题 ，而这个问题的答案，就是必须先做出界面，在确定界面样式和效果以后 ，才能整理规范
。如果先做规范 ，就难以掌控页面的最终效果 ，如果效果不理想就可能会全部推翻重做。

但这个先做出界面，不是指要把一个项目的所有界面做完
，而是做出关键的 、可以确定项目设计风格和样式的部分即可。所以不管设计师在项目流程中有什么其它安排，设计实施的部分可以总结成下图的流程 ：

也就是在设计项目排期中
，要制定一个界面设计风格 、样式的过稿节点 ，确保在此之前能完成主要页面的设计，并让相关负责人进行评审，改到定稿位置。

然后以这些页面为基础，建立初步的设计规范。如果有设计团队
，就要在这个阶段和其它团队成员确定设计规范的创建格式  、命名逻辑、维护更新 、使用方法等细则 。

接着用基础规范开始推进后续页面的设计，在推进过程中，必然会在新的页面中发现规范的缺漏。这就需要设计师根据实际情况分析 ，对规范进行优化或补充新的内容。只有当项目的设计基本完成 ，且通过评审以后 ，我们才能确定最终的 、完整的项目设计规范 。

前面阐述的是设计规范在项目设计流程中的位置，但规范创建本身所需完成的工作和耗费的时间也很多，所以当我们聚焦这部分工作以后，还可以单独梳理出它的流程。

大体包含下面四个步骤 ：

步骤 1：规范收集，就是从定稿的页面中收集形成规范的要素
，包括色彩、字体 、版式  ，以及控件和组件等内容，并要对收集的内容进行初步的整理和归类 。

步骤 2 ：规范创建 ，将收集的规范要素创建成软件内可以复用的格式
，包括创建对应样式 Style 或组件 Component。

步骤 3：规范完善，即在持续设计过程中优化规范的内容 ，不管是增加新的规范要素 ，还是优化命名、分类 、自动布局，都要在这个阶段中完成。

步骤 4：规范交付 ，按特定的格式整理设计规范进行归档 ，并交付给其它项目成员
。换句话说 ，就是对设计规范的展示样式进行美化，以及添加标注说明
。

在步骤 1-3 中，设计规范都处于一个更新
、调整的状态
，且界面设计的工作还没有结束 。所以规范内容的表现形式和规格并没有特定的要求 ，怎么方便怎么高效怎么做  。

只有在整体规范内容都已经定稿，不会有大的改变，且团队需要更详细、专业的规范文档时 ，我们才需要进入到第四步，对规范内容进行“包装”。

以上只是规范定义的大致流程介绍，并不是绝对的 ，设计师只需要了解原理即可，在项目中再根据实际场景做调整 。

三、组件库的内容解析

接着，我们还要分享组件库  、项目规范还包含哪些内容，可以总结成下面几个大类
 ：

1. 布局框架
2. 视觉样式
3. 基础控件
4. 通用组件
5. 业务组件
6. 数据图表

1. 布局框架

布局框架就是形成页面布局的规则，比如导航和内容区域的布局 ，消息提示的位置，特定页面版式的要求等等 。

除此以外 ，还包含项目使用的间距参数
、栅格参数 、响应式规则等相对宏观的信息 ，都要做出规范
。

2. 视觉样式

视觉样式即上一篇提到的内容 ，是组成页面视觉效果的基础属性设置 。包括色彩、字体
、样式、图标等内容
。

3. 基础控件

基础控件即可交互的基础 UI 单位 ，比如按钮、标签、输入框 、多选框 、滑块等
。这些元素的使用频率极高 ，也是复杂组件的组成部分之一 。如果控件种类较多
，也可以用操作、展示
、输入
、提示等使用场景进行分类。

4. 通用组件

通用组件就是目前已经被广泛运用的常见组件类型，比如穿梭框 、日期选择器 、色彩选择器、信息表格等。因为通用组件数量也不少
，所以它也同样可以使用上面提到场景做进一步的分类
 。

5. 业务组件

业务组件是别的项目没有，完全根据当前项目需求定制出来组件。比如复杂的表格筛选器、订单规则编辑面板、车辆形式记录控制栏等特殊组件 。业务组件的需求各种各样，所以不容易做归类
，但因为它们的使用频率并不高 ，所以即使没有做分类也没关系。

6. 数据图表

数据图表也是组件的一部分，只不过数据图表从作用 、开发、样式上都自成一派
，所以我们需要把它作为规范中的一个独立分类来考虑 。数据图表总体上可以分为比较、分布、构成
、联系四个大类 ，但项目中不一定会全部用上 ，所以如果项目内使用的图表类型不多的话 ，就无需做出进一步的分类 。

上面提到的六点 ，就是项目设计规范中包含的主要内容 。每一个分类都需要掌握它们专业知识和应用技巧，才能做出有效的制定。

最后有一点，就是规范内容的制定主体是具体的样式或组件内容，而不是对规范的布局美化，它们是规范的收尾工作 ，而不是规范本身。

结尾

创建组件库一定要尽可能的精简，在勉强够用的水平线上徘徊，是效率最大化的保证。而类似各系统官方组件库那种做了自动布局+套娃+变体的完整形态 ，属于作茧自缚，劝大家量力而行~

作者：超人的电话亭