5000字干货！如何快速完成B端设计规范落地？

一、B端设计规范的内容整理

不同项目的 UI 的设计规范虽然看起来都很像，但因为项目需求、设计差异，不可能一模一样。所以虽然网上有很多规范案例，但新手很难直接照搬。所以我们首先要解决的问题是规范里有什么，如何应地制宜展开规划，输出符合项目实际情况的规范内容。

简单解释，在 B 端设计规范中，主要包含三个核心模块，分别是：布局、样式、组件库，下面分别对它们进行说明。

1. 布局部分

即 B 端界面的主要框架、版式信息，比如使用了哪种响应式模式、栅格规格，还有全局组件导航栏、信息栏、内容区域的布局模式，以及浮层抽屉、通知窗口等元素的显示方法，最后还有很多人会忽略的间距参数的应用。

布局部分的规范决定了整个项目的基础版式和交互路径，虽然内容不多，但却是整个设计规范中最复杂也最难完整落地的部分，需要设计师具备扎实的基础理论知识和一定的项目经验。

2. 样式部分

样式通常指界面最基础的视觉细节，UI 中最基础的样式内容就包含色彩、字体、图标这三个大类。如果项目风格化强一点，那就还可以整理一些额外的内容，如投影、透明度、渐变、毛玻璃效果的具体参数和使用细节等。

样式是规范整理中最简单的部分，只有在字体整理上存在一定的认知歧义，需要设计师花比较多的时间去理清楚具体的参数和规则。只要样式规范能整理并设置好，那么就可以快速应用到后续的项目设计中去。

3. 组件库部分

组件库就是项目中使用的控件、组件元素的合集，比如按钮、开关、下拉菜单、导航栏等。我们需要把项目会用到的这些内容整理出来，并罗列它们的不同场景和状态样式。

不同项目中会用到的控件和组件不同，且同一个控件也会使用不同的设计样式，所以每个项目的组件库都是独立的难以复用。

组件规范整理本身并不困难，但新手主要遇到的矛盾是如何对组件进行归类，毕竟每个项目都会包含数十种控件、组件应用，如果没有分类形式就会导致后续使用的混乱。

所以我们根据 Ant、TD、Arco 来简单总结下 B 端组件库的分类：

其中 “布局” 主要包含栅格、间距、弹性布局等内容，在开发语境中，它们也是代码组件化的一部分，但在我们现在的语境里，它们是前面布局的内容而不是可视的组件元素，所以先忽略它。

下面分别解释以下其它几个分类主要包含哪些要素：

通用/基础：主要是按钮、链接两个组成网页的最基本交互元素

导航：包含导航菜单、分页工具、步骤、锚点等，用于表示所处位置、状态的控组件

数据输入：包含输入框、单选、多选、下拉选择等用户录入数据的控组件

数据展示：包含头像、徽标、日历、卡片、表格等展示数据信息的控组件

反馈/消息：包含警告、提示、消息、引导等用于提示用户的控组件

其它：一些难以归类的组件类型

在我们项目中应用的大多数控件和组件，都可以根据这个通用的分类来整理。如果其中一些特定的组件内容、样式非常多，也可以做成一个独立的组件分类，比如表格这样的组件。

有的项目会包含多种表格的类型和样式，加上表格本身复杂的交互和状态表现，需要有非常多的篇幅进行整理和展示，所以做成一个独立的分类也是合理的。

再者，如果项目有一些比较特殊的业务模块，比如自定义页面、流程编辑、设备管理之类的，应用了一系列特殊的控件和组件，那么也可以根据这个模块类型命名创建一个新的分类。

最后，组件库还有个特殊的类型 —— 图表库。之所以前面没有列举，是因为常规项目极少会自定义图表组件，都是调用第三方图表库生成的（Echart之类的），在这种情况下如果要输出规范，就只能制定图表的用色逻辑。

如果是完全自动图表，那么就可以作为一个单独的分类，每个图表类型如折线、柱状、扇形等再逐一进行整理和解释。

以上就是 B 端设计规范中会包含的主要内容，下面我们就来分享如何进行具体的整理。

二、B端布局规范整理

布局是构成界面视觉框架的基本要素，包含页面布局、栅格/响应式、浮层、间距四个部分的应用规则。

1. 页面布局规范

页面布局就是页面的主要模块排布，包括导航栏、菜单栏、内容区域三个核心模块，还有页脚、抽屉、页签栏（如果有做的话）等。

在我们自己的项目，就是把页面的标准布局剥离出来示意，如下面的案例。

部分复杂的项目可能会在不同的模块、页面中使用不同的布局形式，这些布局自然也要整理，但这和开源框架中提供多种布局形式有本质不同，它们只是先把选择提供出来用户自己选择，而我们的整理的是项目必须要用的类型。

2. 栅格/响应式规范

B 端项目往往会应用响应式布局，来支持不同规格的屏幕和浏览器窗口缩放。但和一般企业官网所使用的完整响应式规则不同的是，B 端通常应用的是响应式的 —— 简化（阉割）版。

比如基本不会去适配平板、手机的尺寸，也不会支持太多断点（BreakPoint）和多种布局，仅仅是让内容区域可以根据屏幕宽度拉伸而已，比如下面案例：

在这种情况下，响应式的栅格系统也就变成摆设，用它作为宽度单位的意义已经不存在了（需要了解响应式的基础知识）。

之所以这么简陋是因为响应式开发涉及的开发量过大，收益却不高。设计师需要先和前端开发商议后再做规范的定义，确定开发用栅格了再定义栅格的系统，如果不做就只确定最关键的几个规则并做出示意。

包含：

1. 最小宽度：页面支持的最小浏览器视图宽，低于这个宽度不再适配
2. 响应模块：会产生宽度适配效果的模块，侧边导航通常不跟随页面宽度变化
3. 断点支持：是否添加特定的断点值，实现导航栏或其它侧边栏的隐藏。

3. 浮层应用规范

浮层指的是项目中各类悬浮控件、组件，包括提示框、通知、气泡、抽屉、展开菜单等等，具体可以看我之前分享的浮层解析。

浮层规范要做的并不是直接开始整理并解释这些视觉组件，而是确认它们的应用、布局逻辑，以及在模态环境下，背景遮罩层的规格。

简单整理起来可以如下图所示：

浮层一多，下一个问题就是层级，这些浮层共同出现时的叠加关系，所以还要简单梳理 Z 轴的层级逻辑。具体的逻辑就不在这里展开，大家可以看上面分享的浮层。

4. 间距规范

间距是组成布局的重要依据，而我们要整理的就是项目中要准备应用哪些间距的规格。虽然下意识我们会选择 4 的倍数间距，但这要看实际应用效果，必须以有效的设计稿为依据做整理，并明确规定几个常见的间距应用数值。

这些间距场景包含：内容区域外边距、模块外边距、模块内边距、标题副标题间距、图标文字间距等。可以通过一两个个有代表性的设计稿做标注来表示。

三、样式规范的整理

样式规范包含色彩、字体、图标、风格四个组成部分，是最容易理解和整理的规范，但做好并应用起来却不容易。

1. 色彩规范

色彩规范主要整理项目的主色、辅助色、中性色，对应的概念就不需要多做解释了。要注意主色只能有一个，而不能将多个颜色作为主色。而辅助色除了品牌色外，主要包含功能性用色，比如警示、错误、正确等色彩应用，一些视觉化的运营图、插画、图标用色是不需要作为辅助色整理进去的。

除了纯色，渐变也可以做出对应的整理，包括固定的渐变色，或使用渐变的色彩过度规则、渐变角度定义等。

2. 字体规范

字体规是规范中最难定义的部分，常规情况下我们可以根据文字的应用场景将它们划分成标题、正文、注释、数字/英文等四个大类，每个大类下包含若干的具体样式规格。

字体涉及的规范主要包含：字体类型、字号、字重、行高、字色等属性，每一个字体样式都具体定义了这些属性值。因为前面定义过色彩规范，所以字色需要匹配色彩规范和命名，而不是给一套的新的十六进制色值。

另一个问题就是行高的定义，一般文本行高都用默认即可，但如果出现了大段文本的场景（比如文章），那么就要增加正文行高来提升可读性，这种情况下就等于出现了两种字体样式，而不是一个字体样式包含两种行高。同时，大段文本的应用还要关注一个额外的文字属性 —— 段间距，只需要在这类字体样式上设置即可。

3. 图标规范

图标规范主要整理的是图标的尺寸和样式规格。

在一个项目中，最完美的图标应用场景就是只定义一套风格一致的工具图标，应用到项目的各个页面和组件中去。

但有相当一部分项目需要设计多种风格的图标，以提升视觉效果和满足不同的应用场景，这就需要我们将这些图标的规格整理出来，同时也需要将设计好的图标置入到规范中，成为后续设计的引用元素。

4. 风格规范

风格规范就是视觉风格性要素的整理，包括圆角、投影、模糊、描边等样式的应用。只需要将用过的案例整理进来，并标注对应的参数即可。

四、组件库的整理

组件库即放置项目涉及的不同控件、组件元素，在初期我们可以根据前面总结的基础、导航、输入、展示、反馈、其它六个大类做区分，每个大类先创建一个独立的画布，将元素置入进去。

组件库和样式不同的是，里面的元素是可交互的，也就意味着它们会有不同的状态用于反馈和示意。所以每个一个控、组件都要做出它们的不同交互状态下的样式。

比如按钮会包含默认、悬浮、点击、不可点，输入框包含默认、悬浮、待输入、输入中、已输入、不可用等状态。这些交互状态是开发中必不可少的部分，但我们无法直接在界面设计稿中完成，所以要在置入规范画布后单独对它们进行设计和展示。

而一些复杂的组件，比如表格、编辑器、图表等，去表现它不同状态是不可取的，因为它们包含了大量的视觉和交互细节，每个操作都画个表格肯定是画不完的。所以只需要表现几个关键的状态，然后将大组件拆分成若干小组件或控件进行独立表示。

这些组件的整理方式 Ant、TD、Arco 等第三方框架都已经做的非常完善了，只要找规范的源文件（官网都有）并参考它们的做法即可。

理论上，设计界面的过程中，只要设计了新的控件或组件，将它们整理进画布中再做出不同的状态，就可以完成组件库的创建。但这种做法的缺点是界面和组件的整理过程各做各的，处于割裂的状态，很容易导致组件之间的样式不够统一。

所以我们在整理规范库的时候，要有目的性的去建立组件之间的联系，并尽可能的在组件库整理的过程中反向提升设计的质量。下面分享一些相关的经验和技巧。

比如按钮和输入框、选择器等都是矩形元素，很多场景下都会并列需要使用相同的高度，所以我们可以在定义完按钮以后去统一类似控件的高度。

并且按钮也有不同的高度规格，这些高度可以继承到其它控件或者细节中，比如步进器、通知栏、头像、表格的表头、步骤条等。

再上一级，比按钮更大的矩形元素则是行类元素，比如菜单栏、表格行、列表行、模块标题栏等，也可以将高度固定成少数几个尺寸。

同理，圆形的控件也可以使用类似的思路统一，比如单选控件、滑动输入、开关、徽标、轮播指示器等。

尽量先把常用基础控件整理完，再去创建复杂的组件，因为复杂的组件都是由这些基础元素组成，前期基础元素整理的越完善，这些复杂组件的设计就会越容易。

总结起来，想有效的整理组件库，就是先从按钮作为整理起点，再拓展至所有矩形类控件的定义，然后定义圆形类控件。整理完常见基础控件以后，再慢慢整理复杂的组件，直至将所有组件整理完毕。

同时，作为项目自用的组件库，不建议花大量的时间去折腾软件内的变体和处理规范展示本身的布局，这会耗费大量的时间，而且不会对后续设计效率产生多少正面影响（甚至是负面的）。

在这个整理过程并没有什么技术难度，考验的是大家的耐心和对细节的重视度。

下面是整理的：

结尾

以上就是基于普通项目创建 B 端项目规范的分享，虽然我没有太花篇幅演示规范具体应该设计成什么样，但它们并不重要，只要思路是正确的你们可以随意发挥。

如果有别的疑问，就可以在我们自己的社群里提出来，今天就分享到这里。

我们下篇再贱~

作者：超人的电话亭