作者：ZYUN（20190401）
预计阅读时长：15m 08s（5268 字；12 图）

摘要：主要记录设计系统的创建过程、具体内容和实际应用，以及其中的不足与反思。

规划

重点内容

在对我们的产品、设计和开发流程、团队协作等方面的具体情况进行分析，并列出相应痛点之后，我开始构思我们的设计系统的内容。
针对第一篇中提到的痛点，我的解决思路集中在以下几点：

• 建立基础样式库、组件库，以便高效复用、统一修改、多人协作，进而提高设计效率，解决视觉风格、交互方式不一致的问题。
• 将我们团队协作的特点考虑在内，在组件库中加入标注、交互说明、流程图连接线等小工具，以便在视觉稿上直接、快速补充交互细节。
• 从现有产品中提取出高复用的界面作为模板页面，以便直接调用、填充数据，快速完成简单页面的设计。
• 创建设计文档统一模板，以标准化的方式更新、维护设计文档。
• 以共享文档的方式制定、记录关键元素、交互行为、功能流程的设计规范。
• 创建交互自查表，以便在各个环节快速进行查漏补缺。

指导原则

如前文所述，我们的产品都是基于网页的数据密集型产品，业务繁复，功能庞杂。因此，我希望我们的设计系统能以简洁实用为创建原则，以内容的可读性和页面的加载时间为首要考虑因素。譬如，使用清晰干净的配色，避免分散用户对内容的注意力，从而提高信息获取效率；譬如，优先使用系统默认的界面字体，避免因加载字体而影响页面加载速度。

创建

STEP 1：设计元素清查

对很多产品来说，设计元素清查这一步可能会耗费大量的时间，因为他们需要对产品中所有的界面逐一清查，从中提炼出可复用的界面组成要素。
而我们的后台产品中绝大部分的组件都是系统组件，自定义的业务组件相对较少。并且在这里，我打算只创建适用于所有后台产品、所有项目都可调用的组件库，各个后台独有的、特定的业务组件可在设计的过程中逐步创建本地组件。
因此，这里的设计元素清查就相对简单一点。
1）我先以其他在线设计系统为参考，列出所有基础视觉要素（如配色、字体等等）和可能的系统组件类型（如按钮、输入框等等）。
2）以近期最完善、最全面的一个后台产品为准，将其中对应的元素进行整理、归类。
3）将其他后台产品中的设计元素与第二点中整理好的设计元素进行对照，了解当前存在不一致的地方，并去除冗余的元素，增添缺少的必要元素。

STEP 2：创建组件库

1. 站在后台产品设计的整体层面，理解所有设计元素的设计原则和使用方式，以便以统一的标准对这些元素进行梳理。

例如，我们现有的后台产品中分别有以橙色、红色、蓝色等为主色的多种配色。
那首先，我需要对这些配色的使用背景进行了解：它们都是依据我们 C 端产品的视觉风格制定的，而 C 端产品又几经视觉改版，所以在 C 端产品不同视觉风格期间设计开发的后台就有了不同的配色。
然后，依据之前定下的指导原则，我们的界面用色需要以简洁实用、清晰干净为准则。
此外，红色在后台管理系统的设计中通常用作功能色，以突出危险信号、错误提示，如果同时作为主色，则容易产生混淆，导致无法准确传达信息、提供清晰反馈。而蓝色则比较清新，传递出的情绪相对稳定、可靠、友好。
因此，综合以上几点，我最终采用了蓝色作为主色。

类似地，我们现有的后台产品中有多种类型的布局，全屏展示的、固定内容区域宽度垂直居中的、响应式的、静态的等等。这种情况下，我需要先去了解这些布局的使用背景、设计原则、开发实现方式等等，再结合我们现在的使用情况，综合选取合适的布局作为最终布局。

2. 先对基础的视觉风格与样式规则进行统一定义，包括配色、字体排版、图标、间距、插画等。

3. 根据确定下来的视觉风格和样式规则，对具体的交互元素进行调整、统一，包括外观样式、交互细节等。

例如，对于按钮，会调整按钮的配色、圆角、文本标签的字体、按钮内元素的间距等，再根据使用情况确定几种通用尺寸、补齐各种交互状态（如，默认、悬停、点击、禁用等）。

4. 命名方式

• 样式、组件的命名方式可参考 CSS 的语义命名法。语义化命名即通过「用途」对元素进行定义描述，而不是通过具体的表现样式（如颜色、位置等）。
  例如，主色可命名为「color_primary」，而不是结构化命名「color_blue」。这样命名的好处，一是有利于我们后续的更新维护，当我们修改主色为红色时，我们只需要更改 color_primary 的色值，不需要修改命名；二是可以避免命名冲突，主色蓝色和信息色蓝色可分别命名为 color_primary 和 color_info；三是方便与开发工程师协作，保证设计师和程序员之间使用同一套语言进行沟通。

• 在 Sketch 中，我们通过命名对组件进行组织，合理的命名可以保证组件库条理清晰，易于理解，方便设计师快速识别、调用。
  1）在命名中使用符号「/」区分层级。
  2）组件一级分类的命名，可按我们上文所列系统组件的名称进行命名。例如， Button、Input 等等。
  但是，为防止一级分类列表太长或某些分类包含层级太深的子分类，我在这里做了一些调整。对于子分类层级不多的组件，我会在前面加一个层级，即系统组件的大分类。例如，Modal、Message、Popconfirm、Alert 等等属于反馈类的组件都归为 Feedback。
  3）组件子分类的命名，通常可按状态（例如，默认、禁用、已选、未选、开、关）、尺寸（例如，大、小）、情感（例如，危险、警告、成功、失败）、位置、数目等等特征进行命名。
  此外，由于组件可能包含这些特征中的一个或多个类型，所以需要先定好一致的特征优先级。例如，「Buttons / Danger / Small / Hover」就是按「组件名称 / 情感 / 尺寸 / 状态」的顺序依次命名。
  
  

STEP 3：制定设计约定

对后台产品中高复用的交互方式或功能流程进行提炼、总结，并以在线文档的形式进行记录、共享。
例如，一般情况下，数据表格的批量操作交互为：批量操作按钮默认不可用；选中表格中批量操作相关的项目后，按钮呈现可用状态；点击批量操作按钮，弹出 Popconfirm 进行操作确认。
将通用的交互流程提炼出来，作为设计师和开发工程师之间的约定，则不需要每次都进行标注、沟通，可减少重复工作，大大提高协作效率。

STEP 4：创建设计文件模板

基于我们的设计、协作流程特点，创建统一的设计文件模板，以标准化的方式更新、维护设计文档，解放出更多的时间、精力用于设计思考。模板包含以下内容：

• 提供模板页面，可直接复制、填充数据，快速完成简单、常见页面的设计
• 对所用组件库的内容、调用方法进行说明
• 对页面命名方式，更新日志的记录方法等作统一规定
  
  

STEP 5：编写记录文档

我在语雀上对我们的设计系统进行记录，包括所有模式和组件的设计指南、设计系统的更新记录、设计源文件等等，相当于设计系统的使用手册，同时也可作为我们设计、开发时的快速参考。
语雀文档提供了文档大纲和文档内跳转等功能，可直接定位到特定内容，方便我们进行快速查询和导航。另外，语雀文档也支持分享、协作、在线评论，我们的团队成员都可以随时访问，进行反馈或者编辑，共同参与设计系统的维护和完善。

内容介绍

1. 组件库的内容主要包含 3 个部分：

• Foundations 基础样式
  这部分属于感知性的设计模式，即界面中的非实体组成要素。包括图标、颜色、字体排版、插画、布局等核心视觉要素的样式定义和使用指南，相当于使用此系统进行设计的产品的「品牌指南」。
• Components 组件
  这部分属于功能性的设计模式，即界面的实体组成要素。包括所有可在全局范围内复用的元素，共有四个部分，分别为 Navigation 导航、Data Entry 数据输入、Data Display 数据展示、Feedback 反馈。
• Patterns 模式
  这部分是从当前后台产品中提炼出来的高复用的交互行为、功能流程等内容。目前仅包括「设计约定」和「交互自查表」。

2. 除了组件库，目前设计系统中还提供了部分可用的设计资源。包括 Sketch UI 组件库和后台产品设计 Sketch 模板。

Sketch UI 组件库中提供了 116 种字体样式定义，25 种颜色样式定义，68 种图层样式定义，可直接在文件中调用；此外，还提供了 7 大类 44 小类元件，所有 symbol 支持直接复用、覆写，并且布局支持响应式、可按需更改尺寸。
具体使用方法及其他说明可在 Sketch 文件中查看。

后台产品设计 Sketch 模板中共提供了 54 个常用模板页面，可直接复制、覆写，快速完成常见页面的设计。
具体使用方法及其他说明可在 Sketch 文件中查看。

应用

在团队中推动

在设计系统第一个版本的构建完成之后，我首先在我们 UI 小组内进行了展示，分享了设计系统的整个探索过程和个人思考，然后分享给我们的开发工程师小组，最后是我们的产品小组。
在将设计系统应用到实际工作之前，我需要向我们的团队展示现有的问题、创建一套标准统一的设计体系的必要性，以及它如何能为我们的产品和团队增值，从而在设计系统的构建和应用上达成共识。

共享和应用

设计方面

由于我是唯一参与后台产品设计的设计师，所以组件库暂未进行共享和协作。我将 Sketch UI 组件库文件添加为 Library，并已在我们的新后台产品设计中进行调用。数据敏感原因，无法在这里展示真实的应用界面。

开发方面

目前，我们的线上组件库仍在开发中。

迭代与维护

到目前为止，我们的设计系统还未进行第二个版本的迭代。

反思总结

不足与问题

通过对此次设计系统的探索过程进行回顾、反思，我总结出以下几点不足和问题。

1. 如上文提到的，在对样式、组件进行命名时，使用语义命名法是更好的。但是，这一点我是经过后来的学习才发现的，起初创建组件库时仍采用了结构化的命名方式。

2. 在样式库中定义了过多的文本样式、图层样式。实际上，根据我们后台产品的特点，有些用途单一或边缘的样式可不进行定义，否则将导致样式库过于复杂，造成不必要的样式浪费。
   例如，在某个后台产品某个特定界面，为了某种视觉效果而设置的特殊字体样式，无需定义为共享字体样式。这种样式只在特定场景里使用，并不会在其他地方进行复用。

3. 除以上具体问题外，我们面临的最大问题是，后台产品新旧版本的迭代问题。

   • 为保证正常的产品工作进程不中断，我们的组件库是在边完成现阶段业务需求的情况下边进行设计、开发的，所以组件库的最终完成度比较不可控。
   • 组件库设计完成后，新项目便开始使用组件库进行设计，但此时线上组件库仍未开发完成，设计与开发之间的对接流程仍是之前的模式，这对于开发工程师来说，无疑又增大了工作量，他们需要根据新的标注进行开发。
   • 线上组件库开发完成后，面对这么多已有的后台产品，我们应该如何逐步完成这么大体量的更新修改？这也是我们正在思考和规划的。

当然，不管是设计系统本身还是此次探索过程，都还存在很多其他的不足，未来也许还会面临各式各样新的挑战，我将不断尝试不断学习，期待能和我们的团队一起努力，使我们的设计系统、工作流程、产品设计质量都日趋完善。

设计系统并不是我们的最终目标

如果我们暂时没有足够的资源和精力去创建设计系统，或者我们并不确定自定义化的设计系统能如何为我们的团队增值，那么我们也可以利用现有的开源设计系统等资源去解决问题。
而当问题已经严重到需要通过创建一个自定义化的设计系统加以解决时，我们也可以依据实际情况、有针对性地对设计系统的创建和实践进行规划。
毕竟，创建一个完美的设计系统并不是我们的目标。
我们的目标是优化工作流程，提高产品迭代效率，改善产品设计的一致性问题，提升产品体验。而随着业务需求的变化和产品复杂度的提升，我们的解决方案将不断变化、更新。
因此，设计系统本身的构建也是动态的、无止境的，它应该始终效力于设计工作的规范与优化，而不是成为枷锁。

相关链接：
后台产品设计体系的创建过程回顾一：创建背景
后台产品设计体系的创建过程回顾三：工具与资源分享
SDS 的记录文档（语雀）
设计约定记录文档（语雀）
SDS 的记录文档（Gitbook）
源文件下载（腾讯微云）