作者：ZYUN（20190401）
预计阅读时长：14m 42s（5080 字；10 图）

前言

本文旨在记录和分享我在有车以后尝试为我们的后台产品创建一个设计系统的探索过程，以及其中的不足与反思。同时，也是借此机会对这两年的后台产品设计工作进行回顾和总结。

全文内容共分为三篇，第一篇（本篇）主要介绍此设计系统的创建背景、必要性和价值，第二篇主要记录此设计系统的创建过程、具体内容和实际应用，第三篇是相关设计工具、技巧，以及相关文章、书籍等资源的推荐。
全文内容结构如下图所示：

此设计系统的记录文档已存放在语雀和 Gitbook 上，点击 Singularity Design System（语雀） 或 Singularity Design System（Gitbook） 即可查看、搜索所需内容，并下载源文件。
除此之外，也可以直接前往腾讯微云​下载源文件，以使用或参考。

本文及此设计系统的内容都仍存在许多不足之处，且仅代表我个人在面对特定产品、项目和团队时所用的工作思路和方法，并非放之四海而皆准，但如果能为你带来一点点的参考价值，那就太好了～如果有什么疑问或建议，可以在评论区告诉我，一起讨论、学习啊～提前感谢你的阅读～

背景

产品特点

由 2017 年三月开始至今，我共参与了有车以后内部近 10 个后台产品的设计。其中，少数几个产品是从零开始进行设计，多个项目则是对原有产品进行改版后继续更新迭代。

这些产品都是基于网页的数据密集型产品，集成了很多的功能和信息，本身的业务、交互逻辑都比较复杂，并且长期在没有设计标准约束和指导的情况下进行迭代。久而久之，视觉表现、交互体验上的问题都开始突显出来并愈演愈烈，流程变得复杂，信息架构变得混乱，系统越来越庞大臃肿。加之一些历史遗留问题，整体使用体验较差，也不利于后续的迭代和维护，因此需要进行改版。

此外，由于前期缺乏统一有效的设计规范和组件库，这些产品在视觉风格、交互体验上存在较大的差异。为了保证同个产品的一致性，延续产品原来的风格，设计师在设计时需要牢记和区分不同产品对应的设计模式，如颜色，字体，间距、控件样式等等，前端开发工程师则需要根据不同的设计稿标注去进行开发，这无疑增加了设计、开发和团队协作的成本，产生了大量冗余的工作。再者，由于难免会有疏漏，产品最终上线时的设计还原度也常常得不到保证。

从产品类型来看，多个产品都是 CMS 产品，我们通过这些后台系统对不同的前端产品进行管理，同时，也有像「有车号平台」、「经销商平台」这样的平台级工具产品。
另外，我们还有从这些产品中衍生出来的定制化产品，客户购买我们的产品以对特定的业务进行运营、管理。因此，我们需要根据客户提供的品牌 VI，调整、更换产品的 logo、界面配色、UI 元素风格等等。在没有建立统一组件库的情况下，这样的定制化需求常常给我们带来大量的设计修改和开发工作。

开发流程特点 / 人员架构特点

产品项目多、更新迭代快、人力资源不足，这都要求设计和开发必须具备高效输出的能力。尤其是，我们的研发团队中没有「交互设计师」一职，我是唯一参与后台产品设计的设计师，需同时兼顾交互和视觉设计。因此，我常常会在视觉效果图上进行交互细节的标注，然后输出给前端开发工程师，以节省时间。但有时候，产品经理也会直接将产品原型图交付给前端开发工程师进行开发，最终导致控件使用不规范、遗漏交互细节等问题。

此外，我们的后台产品基本都是业务驱动的，常有为了解决某个问题而提出的紧急需求。这种情况下，通常会安排新的开发人员临时接手项目。但由于没有统一的设计规范和组件库，新的开发人员在接手项目后，无法快速了解、熟悉项目，和产品经理、设计人员、其他开发人员之间的沟通成本也因此增大，开发效率、整体工作效率都会因此下降。
而在平时的开发工作中，缺少统一的组件库也常常导致开发工程师重复开发，协作效率低下。

使用人群特点

由于这些产品居多是内部 CMS 产品，所以我们的主要用户就是我们公司内部的同事，例如内容编辑、美术编辑、运营人员等等，这些同事常常需要配合使用多个后台系统去完成日常工作任务。基于这一点，这些产品之间的体验一致性就显得尤为重要。譬如，如果不同产品中类似的操作却有着完全不同的反馈，就很容易让人一头雾水，甚至操作出错。
让我们的同事去适应不同视觉风格和交互方式的界面将会使其工作质效下降。

痛点

通过以上的背景分析，我梳理得出我们在后台产品设计中存在的痛点如下。

设计师

花费很多精力去记住和区分不同产品对应的设计模式，无法有效复用设计资源，无法高效输出标准化的交互稿和视觉稿。

开发工程师

存在大量重复开发的工作，接手新项目时无法快速了解、熟悉项目，设计还原度不可控。

团队

沟通成本大，协作效率低下，无法快速响应客户的定制化需求，并且这些问题会随着团队规模的扩大而愈发突出。

产品

产品设计缺乏统一的设计标准指导，同一产品内、多个产品之间的体验一致性受影响，并且这些问题会随着项目规模的扩大、功能复杂度的提升愈演愈烈，最终难以解决。

用户

不得不去适应不同内部产品的不同视觉和交互体验，学习成本大，操作效率低，导致工作质效下降。

解决方案

明确目标

基于以上背景，我开始思考如何制定一个具体的、切实可行的计划，以解决这些痛点。

作为设计师，我们很容易就陷入以设计为中心的解决方案中，譬如，立马打开 Sketch，创建一份完美的设计规范文档。
然而，根据以往的经验，我们的 Style Guide 虽然对配色、字体、图标等元素进行了风格定义，但最终也只能躺在我们的电脑硬盘里，无助于维护设计模式的一致性，无法为团队带来实用价值。 其原因在于：
1）查询极不方便，无法直接调用相关设计元素，设计师最终都是凭记忆去使用，容易出错；
2）调整、修改规范后，常常无法及时更新文档并同步给其他相关人员；
3）文档中未详细记录相关设计元素的设计原则、使用方法；
4）仅由设计师创作完成，实际上只是一份视觉风格指南，内容缺乏团队层面的普适性；使用的仍是设计师的语言，无法在设计师、开发人员和产品经理之间建立起一套共同的语言。

有鉴于此，我们需要站在产品、团队的整体层面，用系统化的思维去探索新的解决方案。
恰逢此时，通过对 Ant Design 等一系列在线设计体系的学习，我开始了解到一种基于原子化设计理念的解决思路：基于标准化的设计语言，提供配套的代码组件库和设计文档，以模块化、体系化的方式推动设计和开发流程，在解决实际需求的同时也具备良好的可维护性。

但是，我们的目标不是创建出和这些设计体系一样完善的设计系统，实际上我们也没有能力和资源实现这一点。我们的目标，是学习和借鉴“标准化、模块化、体系化”的思路，结合我们的产品、团队特性，创建一个简单适用的设计系统，帮助产品经理、设计师、开发人员规范工作流程，使产出、协作更加标准化，提高产品设计和开发效率，解放出更多的精力用于设计思考，并最终提升产品在视觉表现、交互等层面的一致性，进而提升产品的用户体验。
另外，在解决痛点的同时，也希望随着设计系统的构建和实践，设计团队在公司内的专业度与影响力能得到提升。

可行性

1. 基于真实产品构建

在开始构建设计系统之前，我们已经有了近十个后台产品的设计经验。我们可以从这些产品中提炼出稳定且高复用的内容形成组件库，并在不断解决真实问题的过程中，总结出规范化、标准化的设计指导原则。这很大程度上保证了，构建出来的设计系统能满足我们的需求并应用于我们之后的产品项目中。
相应地，我们构建的设计系统应用在这些产品或者新项目上，经过真实数据、内容的测试、迭代，也可反过来推动设计系统的持续完善。

2. 设计工具赋能

开始接手后台产品的设计工作时，我使用的主要设计工具正好从 Photoshop 转成 Sketch，当时对于 Sketch 还不太熟悉，软件本身的各项功能也还不像现在这么完善，因而无法高效地建立、应用、共享组件库内容。
经过这段时间的摸索，对 Sketch 的运用较之前熟练了一点儿，同时 Sketch 的各项功能、插件也都相当完备，譬如，Library 功能、Anima Toolkit 的自动布局功能等等（更多使用技巧可在第三篇中查看）。这无疑为设计系统、组件库的落地奠定了基础。

推动执行

在构建和推动设计系统的过程中，难免会收到来自产品经理、开发人员的质疑，譬如：

• 为什么不使用 Style Guide 代替设计系统？
  如上文所述，Style Guide 作为静态文档，在调用、维护、协作等方面都存在一定的缺陷，而设计系统则更具实用性和时效性，它能帮助我们解决 Style Guide 在实践中的问题。

• 为什么不使用现成的开源设计系统？
  网络上确实有非常多现成的设计系统可供使用，但大部分设计系统所提供的 Sketch 文件都没有将颜色、字体、图层样式等设置为共享样式，这意味着，如果我修改了某个颜色，字体、图层、组件的颜色都无法随之更改，即，无法做到原子级的全局响应。
  同时，文件中的组件也没有考虑内容的自适应，对 symbol 进行覆写后，其样式可能出现错乱，导致我们无法直接、快速地将这些组件应用到我们的业务场景中。
  因此，这些设计资源对于设计师来说，使用价值相对有限。

• 创建、维护设计系统会不会为开发人员带来大量不必要的工作，成为长期的技术负担？
  我认为，同时具有「设计」和「代码」组件库的设计系统才是最有效的设计系统。所以，针对这个问题，我们可以和开发人员进行沟通，一起讨论如何花较小的开发成本来实现设计系统的最大价值，共同寻找解决方案。

当然，除了以上例子，可能还会有其他各种各样的问题。在构建之前、构建的过程中、投入使用后，我们都需要不断地进行沟通，达成共识。
设计系统是为了解决问题而存在的。只有在大家认同它、使用它之后，它才能发挥出应有的价值；也只有令更多的人参与进来、使用起来、发现问题、提出问题，我们才有可能不断地完善它，使它趋于更适用、更高价值。
否则，我们有可能花费很大的成本却创建出一个过于僵化或者复杂的系统，它将成为我们团队共同的枷锁，限制住我们的思维。这比没有设计系统更糟糕。

写在最后

此设计系统的 Sketch 组件库与后台产品的 Sketch 设计模板都已在今年三月份创建完成并运用在实际的设计工作中。同时，我在语雀上整理、记录了这些组件相应的使用指南和规范，并将通用行为与流程的设计约定、交互自查表等内容纳入了系统。设计系统的详细内容可在第二篇中查看。

需要特别指出的是，除了提炼、总结自我自己的实际工作，记录文档中的部分内容也参考、引用了 Ant Design 的内容，非常感谢 ANTD 团队～
另外，在创建组件库、构建设计系统的过程中，我还参考很多相关的文章、设计系统，都已一并在第三篇中列出，非常感谢这些作者和团队～

以设计系统的形式整理这些内容，一是希望以此作为我们后台产品的设计指南，二是以此作为我个人的工作总结、学习笔记，并期待能借此机会向更多的小伙伴们学习，一起探讨中后台产品在设计、前端开发上的更多解决方案。

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