设计系统（Design System），设计和开发之间的“DevOps”

最近，我们网站的上新增了几个新功能，比如通过导航栏的QR Code可以下载App；通过Carousel的方式，显示多条信息。

以往这样的功能可能需要2-3个Sprints完成，但是现在这些功能都是在一个Sprint内完成了所有功能的开发和测试。之所以我们能高效的完成开发和测试，主要归功于我们对设计系统（Design System）的成功应用。

什么是设计系统？

对于设计系统，大家已经不太陌生，业界已经有很多成功的案例，比如像Google的Material Design，蚂蚁金服的Ant Design，抖音的Semi Design等等。这些公司借助他们的设计系统，成功的改变了他们设计和开发产品的方式，通过一组可重用的组件，以及一套指导这些组件使用的规范，可以快速的完成设计和开发工作。

设计系统和普通的UI组件的一个主要差别，就是使用设计系统完成的产品，其结果总是一致的。就像Google的所有产品，你都可以看到Material Design的影子，完全符合其设计规范。但是像BootStrap这样的UI库，可以搭建出风格完全不一样的网站。

所以通常我们说的设计系统，就是一组可重用的组件，以及一套指导这些组件使用的规范。基于设计系统的组件和规范，可以组合出来任意数量的应用。

对于我们公司来说，由于涉及多个品牌和多个平台终端，如果有一套统一的设计系统，将可以极大的提升我们的设计和开发效率，并且可以保证我们设计开发的结果和品牌形象保持一致。

所以从去年底开始，由设计部门最初提出构想，Web开发部门参与实施，我们一起构建了公司的设计系统。

我有幸参与其中，负责其项目管理和架构设计工作。项目之初，我也认为设计系统不过是一套设计规范加上一套组件库，并不是什么新鲜的概念。

等到今年上半年系统初步实施完成，开发团队和设计团队都开始使用这套系统，我才逐渐发现，设计系统其实不仅是一套设计规范和组件库，更为设计人员和开发人员之间带来一种新的协作模式，甚至是一种文化的改变，就像我们常说的开发和运维之间的DevOps一样。

设计系统在帮助构建设计和开发之间的协作文化

在我们谈到DevOps时，最让人振奋的就是开发和运维一起紧密协作的工作方式，从而可以更快更可靠的构建、测试和发布软件。

但当我们谈到设计系统，你可能会想到Design Token，想到组件库，想到文档，却很难联想到设计和开发的协作，以及它和DevOps有什么关系。

而实际上，我们从设计系统开始构建之初，设计和开发两个团队，就一直一起紧密的协作，共同完成了这套系统的构建，也一点点的形成了协作的文化。

设计和开发有了共同的沟通语言Design Token

在设计系统之前，设计和开发都在各自的世界里用自己的语言进行工作，相互之间也很难沟通，最终的结果就是每次设计出来的设计稿，在开发实现后，总是有比较多和设计稿上的出入，因为开发并不能很好的理解设计稿，需要设计和开发沟通多次才能达到与最初设计一致的结果。

所以在构建设计系统时，最重要的事情之一就是定义Design Token。

Design Token本质上是一套Key Value的组合，将设计规范抽象成一个个的key value，比如下图就是一个颜色的design token列表，简单而清晰。

有了Design Token后，设计人员在描述设计稿时更简单清晰，开发人员也易于理解。

对比一下下面这两张图，第一张是在有Design Token之前，一张是在有Design Token之后，差别非常的明显。

虚拟的设计系统团队

Design Token只是第一步，要做好设计系统，团队才是最重要的！

和很多公司不一样，我们没有一个专门的设计系统团队来负责整个设计系统的构建，从一开始就是以一个虚拟团队的形式在运作。

当初我在和设计团队一起讨论设计系统的时候，我们都知道这绝对是一个很好的方向，但是如果遵照传统的立项、成立团队的方式，我们还要等很久才能开始做这件事，于是我们决定以虚拟团队虚拟项目组的形式来做这件事。就像一个内部的开源项目，大家利用20%的工作时间贡献其中。

这在一开始的时候给我们带来巨大的挑战，我们不能全职做这件事，必须利用日常项目之外的资源来投入。好在设计团队在之前已经做了不少准备工作，我之前也领导过一个内部的前端组件库开发。所以我们从去年底开始正式从头设计和开发这套系统，设计部门定义Design Token和设计系统所需要的基础组件，我从自己团队和其他团队找了几个对设计系统有兴趣的前端开发人员一起成立开发小组，和设计团队一起开始了项目。

虽然是一个虚拟的团队，但是我们一样是按照敏捷开发的方式在运作，我们每两周一个Sprint，尽可能在每个Sprint交付一些内容。我们将所有的任务和Bug通过Jira管理跟踪，每周会有团队的会议交流进展和下一个Sprint的计划。

得益于虚拟团队的模式，让我们一开始就没有了部门的壁垒，不需要去区分这是设计部门还是开发部门的事情，从一开始大家就是为了构建设计系统这个共同的目标一起努力。

也正是由于虚拟团队的模式，让跨团队协作成为可能，每个开发团队的成员都可以参与其中，到现在为止，已经有至少4个不同的开发团队的成员一起参与了我们设计系统的构建。

虚拟团队的模式，还有一个意想不到的好处，就是在后面推广设计系统时，我们没有受到什么阻力，每个团队都愿意迁移到设计系统，因为他们也曾参与其中。

自动化设计系统的构建

我们公司是DevOps的践行者，自动化的理念深入人心，我们尽可能自动化一切自动化的操作，从日常的测试到生产环境的部署，都是自动化操作。

所以在构建设计系统时，我们也将自动化融入设计系统的很多方面。

自动更新发布Design Token

我们所有的Design Tokens，由设计部门用一个Google Spreadsheet管理和维护。如下图所示：

当设计部门对Design Tokens有任何更新，会通知开发团队，开发团队会通过自动化脚本，将Spreadsheet的内容导出，并解析成标准的Json格式，然后针对不同的应用平台生成不同的格式，最后以PR的形式提交到Git上，当PR通过审核和自动化测试后，CI/CD帮助将更新后的内容自动发布新的版本。

借助自动化，设计人员参与系统的更新发布

在以前，设计人员无法参与到开发中，对于发布更新ICON之类的事情，必须给开发团队提交Jira Ticket和必要的资源，然后等待开发团队安排工期，在某个时间完成。

而现在，我们借助设计系统，大大简化了这些操作，设计人员可以直接通过Git网页版以PR的形式提交新的SVG文件，当通过自动化测试，PR合并后，CI/CD会自动将SVG文件发布成ICON组件以及为移动端生成对应尺寸的png文件。

不止是对ICON的发布更新实现了自动化，整个设计系统文档系统的更新也是如此，设计人员可以直接通过Git网页版，提交Markdown格式文档的更新PR，当PR合并后，文档网站就会自动更新。

自动化测试设计

在自动化测试中，UI的自动化测试是最难的。现在由于设计系统对Design Token的抽象，所有界面组件都够建于Design Token之上，所有界面的属性比如颜色、尺寸都必须从Design Token中获取。

所以我们在编译前端组件的时候，会有插件检查所有设计系统UI的属性，当发现有组件的属性使用了超出了Design Token范围的值，则会出现错误提示，可以第一时间避免设计错误的发生。

在Code Review阶段，我们也计划借助机器人帮助我们发现代码中对设计规范的错误使用。

当然设计的自动化测试我们还有很多路要走，但设计系统让对设计的自动化测试成为可能，未来我们还会在这个方向上继续探索。

设计系统，让信息更透明

在设计系统之前，设计和开发都在各自的部门内工作，对双方来说对方的信息就像一个黑盒子，相互并不了解对方多少，这也给沟通协作上带来一定的障碍。

在设计系统的第一阶段完成后，我们做的第一件事就是用设计系统搭建了设计系统的网站，将设计团队所有设计的规范文档、Design Token的内容、组件的设计规范都放在了设计系统网站上；开发团队开发出来的组件，所有组件相关的使用说明文档也都放在了设计系统网站上。

不仅如此，以前设计人员在向开发提供设计稿时，仅仅提供设计上的颜色尺寸等信息，但现在的设计稿，会对相关的组件和属性，都附带有到设计系统网站的链接，让开发可以清楚的知道在实现时，可以直接使用哪些设计系统的组件，以及该如何设置属性。

借助这个公共的设计系统网站，开发和设计都通过同一个网站获取信息，信息对双方来说不再是黑盒子，而是相互透明的，开发对设计的规范有了更深入的了解，设计也知道了开发是如何使用组件的。

最后

经过一年的努力，我们已经打造出一个适合自己的强大的设计系统，并且成功在Web部门落地，主要的Web系统已经集成了设计系统，在新项目中极大的提升了设计和开发的效率。

设计系统的成功，并不仅仅是因为我们重新打造了一套组件库，也不在于它有一套Design Token，而是在于它更加自动化的方式构建系统的UI，让设计和开发之间的信息更加透明，最重要的是，设计系统构建了更好的设计和开发之间协作文化。 这也同样是DevOps的三个重要原则：自动化、信息透明、构建协作文化。

就像我们基于设计系统开发的像二维码下载这样的项目，之所以能高效交付，正是由于开发人员和设计人员日常已经紧密协作，借助设计系统网站对Design Token的各种规范已经熟悉，那么在实现界面的时候，就不需要反复的去和设计确认细节；设计系统本身丰富的组件库，可以半自动化的帮助搭建UI；在提交代码之前，设计系统的自动化检测帮助发现了可能的界面错误，避免了后续UI错误导致的返工。

设计系统正一点点的在改变我们的研发文化，让设计和开发之间的协作更加紧密。