我所理解的设计系统

在进入正题之前，我想先聊聊我所理解的设计系统是什么。设计系统这个词自诞生以来，频频出现在我们的视野中，但每个人对它的理解都不太一样。有人说它是组件库，有人说它是设计规范，也有人说它是设计过程自动化，而我更喜欢把它倒着读来理解——也就是“系统地设计”。

展开来说，就是在做设计时能够更加系统化一些，而不是像艺术家那样随意而又感性。我一直认为用户界面设计是一个很工程的事儿，在面对繁多的业务需求而又要保持整体的一致性时，采用组件化、工程化、自动化的方式可以保证设计被高效率高质量地执行。

因此，我觉得设计系统更像是一种方法或理念，它提供了完善的理论和具体可实践的方法，来帮助我们更加高效地设计。组件化、设计规范、提效工具都是其中的一部分，至于要使用哪些方法要根据团队当前状况而异，并不是说要全部都走一遍才叫设计系统。

我踩过的坑

网上关于设计系统成功的案例很多，但失败的案例却寥寥无几。所以在接下来的内容中，我想讲一讲我做设计系统这几年所踩过的坑，来帮你避开它们。

你真的需要设计系统吗？

关于设计系统最大的坑，就是有可能你并不需要它。最近几年设计系统突然变成一个时髦的东西，各个设计团队都开始构建自己的设计系统。但是，我认为在很多情况下其实并不需要设计系统。设计系统在产品的稳定期可以发挥更大作用，如果没有找到稳定的赚钱方式，还需要快速迭代去探索，就不太需要设计系统。这是因为设计系统需要达成共识，团队所有人在设计时需要遵循一定的规则，这可能会降低设计效率。

当然，如果已有一套设计系统，想要基于此快速构建新的产品去验证新的商业模式，设计系统也是有帮助的。

把设计系统当做一个产品去做

曾有人问过我，你在公司把设计系统做完之后要做什么？我认为问出这个问题的人对设计系统的理解还不够深。

一个设计系统应该和一个正儿八经的产品一样，要跟着产品迭代而迭代，没有做完的概念。和所有面向用户的产品一样，它也有需要面向的用户，需要多个角色全职投入不断迭代。如果一个设计系统会在某个阶段停滞，说明它是一个假的设计系统。

不要试图满足所有业务设计师的需求

设计系统的主要用户是业务设计师，但是就像做面向最终用户的产品一样，我们不能完全听用户的话，满足他们的所有需求。

举一个例子，Action sheet 多选组件我们只提供了下图左侧的样式，有一个业务设计师找到我们要求提供右侧的样式。如果我们直接答应了这个业务设计师的要求，那么组件库中就会存在两种多选样式，其他业务设计师就不知道该用哪一个了。所以，我当时的做法是和对方详细了解了他提出这个需求的背景，才知道他是要用在选择语言界面，觉得左侧样式不太合适（具体为什么不太合适我也不记得了）。最终的解决方法是这里就作为特例，不再使用组件了。

做设计系统更多的时候需要权衡，是把复杂留给自己还是业务设计师，如何保持设计系统的简洁，如何让业务设计师能更好地遵循规范，这些都需要我们去多听多思考。

不要把组件做的太复杂

我曾经很追求把组件做少，这就意味着组件会变得复杂，现在看来有点炫技。借助 Figma 的组件属性，现在可以把若干个组件合并成一个组件，但这也意味着在右侧会有一堆配置项。这种组件看起来很不错，但业务设计师在使用时往往不知道如何配置，只能把组件 detach 掉自己改改用，这样就丧失了组件的意义。

提供尽可能少的选择

后来，我尝试把组件的变体尽量罗列出来，而不需要让业务设计师自己配置组合。这样不仅减少了组件的复杂度，也避免了业务设计师不知道如何配置的问题。当然，这并不是说要罗列出一个组件的所有可能性，比如一个顶部导航的左中右部分有各种可能，如果穷举所有的组合，可能会出现一些十分“怪异”的组件，也就是在设计时很少会用到或者不好看的组件。

所以，我们只需要提供哪些常用的符合美感的组件，这样也可以限制业务设计师乱用，因为“少”本身就是一种规范。

亮暗色设计

现在亮暗色主题几乎都是产品标配了，但亮暗色主题要设计好也不容易。比如，下图中的按钮背景色都是一样的，在暗色模式下由于周围环境更暗，导致文字和背景色的对比就没那么强烈；再比如，下拉菜单的背景色在亮色模式下和整体背景一样，如果在暗色模式下也这么设定，就和背景区分不开了。

像这种在亮色模式下没问题，到暗色模式下就不行了的问题还有很多，我在这一块也不是专家，就不乱讲了，就只抛个砖。

多平台设计

多平台设计也是一个很大的坑，一个设计系统适配多端是不现实的。屏幕的尺寸差异本身就会让用户产生一些尺寸感知的区别，即使我们统一按照一套标准去设计，比如相同的尺寸、间距、字号，在用户看来可能就是不一致的。所以，多平台设计时不应该追求形似，而应该通过圆角、颜色、宽松度去追求神似。

是否需要文档？

大家可能都不太喜欢写文档，但是一个好的设计系统文档还是必须要有的。写文档的过程也是一个查缺补漏的过程，可以通过写文档来反思自己做的组件是否考虑周全。从业务设计师的角度来看，文字太多的文档几乎没啥人看，最好的方式是通过一些图示。下图中的 Do & Don't 对比图是一种比较受欢迎且有用的表达形式。

开发何时加入？

一套完整的设计系统肯定需要开发的参与，否则就只是设计师的自嗨。基于我的经验，可以尽早和开发达成共识，明确这件事的意义，但不需要开发过早投入。写代码的成本是高于画图的，而设计系统在早期会经历很多变化，过早投入会浪费很多成本。

而且，设计系统最好要有全职的设计师和开发一起共创，严格按照一个产品的迭代路径，去设计、排期、评审、开发，否则只会引起混乱。

自动化

在产品构建过程中有很多时间都浪费在一些琐碎的流程上，如果能够自动化一些过程可以把效率提高不少。自动化要有，但不需要一开始就有，可以在设计系统达到一定体量之后再去考虑自动化的事情。

以上，就是我在做设计系统的过程中遇到的一些坑。

我们总能听到设计师对开发的吐槽，或者开发对设计师的吐槽。在我们的印象中，这两类人是两个星球上的人，拥有着完全不同的思维方式。但工作中我们总是需要互相对接，如果还是给对方贴着固有的标签，就不可避免地导致一些沟通上的损耗。这种损耗表现在最终的结果上，就是我们的产品不能达到预期。

所以，我想说的第一点就是，我们可以先摒弃对开发的固有印象，敢于上前和他们多沟通。可能你会觉得有些开发不好沟通，但有可能只是你没有使用他们熟悉的方式去沟通而已。

在这期博客中主播提到的一个做法就挺好的，就是他们会找每一个新来的开发一起，开一个小会给他们讲清楚设计交付到开发的流程，并演示如何使用这些交付工具，比如在 Zeplin 中如何查看样式集合，或者在 Figma 中如何导出图标。

当然，仅仅在事前讲清楚还是不够的，在真实的对接中还是会遇到很多小问题。对于这种情况主播介绍了他们的一个经验，在我看来和开发之间所谓的“约定大于配置”有点相似。举个例子，你所有的设计都使用 4x 栅格（4 的倍数），内边距或元素间距永远都只可能是 4px、8px、12px 等等，但是开发在交付工具中却看到了一个间距为 17px。

假如开发不知道你使用的是 4x 栅格，那么他可能就按照 17px 写下去了。但是，如果你事先和他约定好了“我所有的设计都是 4x 栅格，如果你看到某个间距不是 4 的倍数，你可以自己把它改为最相近的一个 4 的倍数，实在不确定可以找我确认一下”，他可能就会自己纠正为 16px 了。

其实很多情况可以事先约定好，比如说你的设计稿都是像素对齐的，那么如果开发看到了小数就可以自己四舍五入一下。还有 Figma 中的切图，开发很容易点到里面切出尺寸不对的图，那么你们可以事先约定好所有的图标都是 16px 宽的正方形组件，这样他们点到了里面一看尺寸不对就知道点错了（此处打个广告，用 Figma Handoff 可以设计师自己切好图，避免开发切错）。

其实，在设计中我们很容易手误，有时候多了一像素，有时候整数尺寸变成了小数，这都有可能。但是，如果我们事先和开发约定好，告诉他们你的设计习惯，就能省去很多沟通过程。毕竟，工具是死的，而人是活的。

播客中还聊到了另一个建议，就是我们可以尝试去理解开发的思维方式，并学会使用他们的开发工具。前文也说到了，我们会让开发去使用交付工具，让他们注册 Zeplin 或者 Figma 账号，反过来想，我们是不是也可以去学一下 XCode、Android Studio 或者 VSCode 如何使用呢？

当然，这并不是说我们要学会完整的开发技能，而是当整个项目环境在我们的电脑上运行起来之后，我们起码应该知道如何改代码以调一下颜色或尺寸这些视觉属性。会使用这些开发工具，自然而然地也会学会他们的思维方式，这对于双方沟通是大有裨益的。

除了播客中提到的这几点，我还有一些比较落地的建议：

• 合理分布图层结构
• 图层合理命名
• 尽量使用真实或者接近真实的填充数据

虽然在很多交付工具中是看不到图层结构的，但是合理地分布图层结构对我们自己影响很大。设计稿中的图层结构和代码中元素的结构虽然不一定完全一致，但也有着很大的相似性，合理分布图层结构，其实就暗含着你引入了一定的开发思维，就不至于做出天马行空的设计。

图层的命名也有很大学问，整齐优雅的命名不仅有助于别人理解，让别人少一步思考，有些命名方式能和开发习惯对上甚至能减少开发很多工作量。比如说图标命名，开发代码中使用 icon-home 的命名方式，正好你也是用这种形式，就很容易对上。同时，建议所有图层没有特别必要都使用英文命名，毕竟开发写代码都是用英文的。

最后，设计中的数据，比如商品描述、人物头像、评论等，尽量使用真实或者接近真实的数据。首先，真实数据可以让你提前感知你的设计在真实环境中是什么样的。假如说有一个商品列表页面，每一个商品图你都用了特别好看的插画，这样设计时看起来可能很好看，但是一旦上线变成用户上传的图可能就惨不忍睹。其次，数据尽量接近真实可以减小开发理解成本。

其实，要把设计交付开发这件事做好，说到底还是“多沟通”三个字。借用最近在看的《因计算机而强大》这本书里的观点：“我们的文化分裂为‘人文’与‘科学’两种领域，这让他们感到安全……它构成一个怪圈：文化越是分隔，被分隔的两方越是各行是”。虽然我们的工作内容不一样，思维方式也不太一样，但我们不应该互相排斥，而是要互相学习。

这篇文章是我在 Mixlab 广州分享会上的总结。Mixlab（ID：mix-lab）是一个汇集跨界人群的组织，愿景是让每个人有无限可能。

互联网自诞生距今已有五十余年，这几十年中互联网产品形态发生了巨大的改变，其生产流程也在不断变化。在互联网产品的生产流程中，设计师的角色发生了很大转变，设计环节变得越来越重要，设计方式也在不断进化。

在以前，互联网公司商业模式单一，产品形态足够简单，界面交互也没有那么丰富。那时的设计师被称作网页设计师，他们的工作更多的是将平面设计搬到网页上，自己设计自己切图甚至自己写代码实现。随后智能手机出现，设计师们需要开始为移动端设计，不过初期的 App 也不是很复杂，所以即使是细节丰富的拟物化设计，设计师也能够应付过来。

当时市场竞争也没有现在激烈，很多产品很长时间才会迭代一次，因而，设计师有足够的时间慢慢设计。那时候的设计师，就好像一个“手工匠人”，经营着一个个的小作坊，打磨完一个产品就开始另一个产品。

但是随后，产品形态开始变得复杂，市场竞争变得激烈，产品迭代周期变得更短，我们需要适应一种快节奏的设计方式。这个时候，一个设计师很难应付一个项目，我们需要多人一起协作，每个设计师的工作也变得更加专职化了。此时，以前那种“作坊式”的设计方式便不再适用，我们需要更加系统化、规模化的设计方法来加速产品设计流程。

什么是设计工程化

在第一次工业革命中，人类的手工生产方式逐渐被机器取代，这时候很多大规模的工厂取代了小作坊，人类社会的生产效率大大提高。其实设计的工程化与之类似，上述的种种变化让我们开始以一种更加系统化的思维去看待设计，设计不再仅仅是创意工作了，更是一项工程。

为了更加具象地理解设计工程化，我们先看一看现在很成熟的前端工程化。工程师们信奉一句话：不会偷懒的开发不是好开发。因此，他们会将代码分成一个个模块，以期最大化复用；也会写一些脚本工具，来辅助开发、测试和发布流程。也就是说，他们会通过一系列的工具和约束规范，把一些繁琐的事务交给机器来做，提升开发体验和效率，让自己有更多时间关注代码逻辑。

前端工程化并不仅帮他们节省了大量时间，也让工程师产出质量更高，一致性、健壮性更好的代码。

这让我想起了一部叫做《模仿游戏》的电影，这部电影讲述了计算机理论提出者图灵坎坷而又传奇的一生。在剧中，他说过这么一段话：

他这段话的意思是，人类可以思考，机器也可以，只不过我们各自擅长不同的思考方式。放到今天的主题中，我们可以这样理解：我们可以使用计算机来帮我们完成一些重复性的、有规律的工作，让自己专注于更有意义的工作。

回到我们要聊的设计工程化中，其实我们也可以像前端工程师那样，通过一些工具或者规范来帮助我们自动化一些流程，让自己可以有更多的时间去思考创意或者业务。其实，我们现在已经在这样做了。

• 现代化的设计工具都会提供共享样式和组件的功能，让我们减少重复设计。
• 我们也会使用一些插件加速设计，比如内容填充、快速生成表格的插件。
• 我们使用标注工具，将设计文件上传至云端，更方便地交付给开发。

可以看到，我们已经在使用机器（计算机）的力量，来让我们的设计流程更加高效。但其实，在设计工程化这一块我们其实还可以做更多。

如何进行设计工程化

设计师是一个承上启下的角色，我们的上游是产品经理，下游是开发。因此，设计的工程化会涉及到内部工程化和外部工程化两部分。

内部工程化

现在大部分产品都需要多个设计师一起合作才能完成，因此设计团队内部的协作效率会极大地影响其产出效率。

设计原则（理念）

设计团队内部工程化的第一步，是需要所有设计师都有一个基本的设计共识，这一点是非常重要但很多设计团队容易忽略的。如果你平时注意的话，会在很多公司设计团队的设计系统中看到类似于设计原则或理念的东西。比如说 salesforce 的 Lightning Design System 的是 Clarity、Efficiency、Consistency 和 Beauty，并且每个词下方都有详细的解释。这些设计理念当然不是随便写的，而是设计团队在一起讨论总结出来的，代表了他们共同的设计理念，是其设计产出所要达到的共同目标，也是根植于潜意识之中的设计准则。在很多时候，它甚至会成为你在设计时的决策因素，潜移默化地影响着你的设计。

但是，现在很多设计团队都会忽略这一块。在 Alla Kholmatova 的《Design Systems》一书中，她也花了大量篇幅讲述了 Design Principles。可以说，如果在一开始不能达成一致的设计理念，设计工程化将会很难进行下去。

唯一设计数据源

现在设计模式很成熟，我们很少需要自己去创造新的界面元素或交互方式了。很多设计规范，诸如谷歌的 Material Design，已经给我们提供了各种输入框、下拉选择、模态框等，足以满足绝大多数场景。而一个设计团队，想要让所有人一起能够高效地设计出一致的产出物，就需要唯一的设计数据源。

所谓的唯一设计数据源，也就是我们在设计工具中提炼出来的共享样式和组件库。现在大部分设计工具都提供样式组件库功能，不过都是视觉化的，而对于这种需要同步的数据，其实代码有着天然的优势。

为此，Airbnb 设计团队自己研发了一个叫做 react-sketch.app 的工具，它让设计师通过写代码来实现这个唯一的样式组件库，并把这份代码生成 Sketch 资源，让其他设计师可以直接在 Sketch 中使用这套资源进行设计。这套由代码组成的唯一设计数据源更好进行版本管理，也因为具备可编程性可以做更多事情。

设计检查

即使有了唯一设计数据源，也不能保证设计产出没有问题。通常，我们会在设计完成后进行设计评审，除了一些主观建议以外，很多和规范不符的地方其实都可以自动化检测。

比如 Airbnb 通过 Figma 的 API 获取到设计图的色值、字号等内容，输入到既定规范中进行机器设计评审，当有不符合设计规范的色值或字号时便可以迅速发现。这样不仅仅缩短了评审时间，也能够发现一些人眼不能发现的错误细节。

外部工程化

现在让我们再看看外部，也就是和上下游交接的部分，这部分的工程化是指让交付流程尽量自动化。

我们知道，设计师和开发其实是两种性格倾向的人，前者感性后者理性，因此两者之间的沟通其实会有很大的信息损耗，就是说你说的 A 对方会理解为 B。但其实呢，在工作流程上我们之间也是有共同点的。前面也说了前端开发的工程化很成熟了，而且他们也有一套共享样式库和组件库，只不过是代码仓库。那么，我们是否可以找出双方的共同点来形成一个自动化的流程呢？

阿里的 Fusion Design，可以通过插件生成不同主题的组件，直接拖拽至 Sketch 中进行设计。使用这个工具，设计师还可以自定义一套 design token，并使用它约束设计，最终产出这一套 token，给开发用于代码中，这样就保证了交付的一致性。

还有一个例子，是 Github 设计团队的图标自动化交付。现在前端图标多采用 SVG 格式，因为它是矢量的，方便改变颜色尺寸，而 SVG 图形本身就是代码，是可以直接从设计师这里交付到开发手中的。Github 通过 Figma 的 API，直接将图标导出代码，发布到 NPM 上供开发使用。这样的好处是，设计师只需在 Figma 内编辑图标，而开发只需用他们熟悉的命令行更新图标库。（我做了一个类似的可用于生产的图标自动化流程，稍后会写文详述）

设计系统

最近几年出现了一个新的概念，叫做“设计系统”，其实它的作用就是来做设计团队内部和外部的工程化的。有人可能觉得这只不过是一个新造的流行词汇，不就是以前那些设计组件库换了个名字嘛。其实设计组件库只是设计系统的一部分，而且是很小的一部分，设计系统所涉及的东西是很广的，可以看一下 Github 的设计系统组成。

Airbnb 的设计系统也是一个很好的例子。Airbnb 设计团队在业务和团队逐渐扩大时，面临着很多设计方面的问题：比如要保证多平台设计的统一，设计的国际化和本地化，设计团队之间的协作效率，等等。为此，他们自己研发了一系列的工具，来实现部分流程自动化，保证整个设计团队可以高效协作。

他们的设计语言系统 Design Language System（DLS）有一张截图是这样的，设计师可以在上面直接查看某个界面在不同平台和不同语言下的实际效果。当然，这只是表面上能看到的，这套系统背后还包括一系列工具。

像 Airbnb 这种产品复杂，设计团队壮大的情况，如果没有一个高效的设计系统协助，其设计流程很难保持高效，设计产出很难保持统一。

在我的理解中，设计系统是不同设计师之间，设计师和其他角色之间沟通协作的桥梁。我们可以通过设计系统减少协作阻力，从而让自己有更多时间用于自己擅长的地方。

展望

也许你会担心，受到这样机械式流程干扰的设计产出，会不会千篇一律没有灵魂呢？当然不会，首先设计工程化是动态的，我们会不断地更新我们的设计系统；其次，正是因为我们把一些机械化的工作交给了机器，才能有更多时间去实现业务上的创新。

Airbnb 的设计经理 Alex Schleifer 就曾在其设计博文《The way we build》中写道：如果不能在构建产品的方式上创新，你的产品就无法创新。

在未来，设计的工程化其实还有更多可以探索的。比如 Airbnb 曾经尝试通过机器学习将手绘图转化为原型图，用来快速验证想法。现在新的技术层出不穷，我们都可以尝试摸索，用来实现高效的设计工程化。