这篇文章来自于 Invision 出品的书籍，围绕规划、设计、构建和实现设计系统的实践经历来指导读者，其中包含了经验丰富专家的真知灼见和一手经验。我很喜欢，也分享给大家，推荐阅读。这是一个系列，一共有 7 章，感兴趣的话，持续关注吧。

20 世纪 60 年代，计算机硬件技术的升级开始超越软件发展的速度。计算机的处理速度变得越来越快，价格也越来越便宜，但计算机软件开发仍然处于缓慢、难以维护的境地，并且还很容易出错。两者之间的差距以及解决这个问题的困境被称之为「软件危机」。

在 1968 年的北约软件工程会议上，道格拉斯·麦克罗伊（Douglas McIlroy）提出了基于组件开发有可能是解决「软件危机」的方法之一。基于组件开发是一种通过复用代码来提高编程潜力的方法，该方法能帮助编程工作更高效、更易于扩展。这样做既能减少编程工作量又能提升软件开发的速度，让软件更好地运用现代计算机的力量。

在 50 年后的今天，我们又面临着类似的挑战，只不过这一次是在设计领域。在 UI 设计中，设计的角色是在为特定需求量身定做解决方案，所以很难去基于整个应用进行扩展。

你有没有走查过你输出的界面，发现自己使用了几十种类似的蓝色，或者同一个按钮不同的用法，将这些样式组合对应到你设计的每一个 UI 界面，就会意识到一套不成体系的设计是多么的难以维护。

△ 一份 UI 样式走查收集的成果，里面罗列的十几种类似的按钮样式说明之前团队挖的坑有多深。

在这种状态下，设计要跟上开发的速度，公司可以选择做以下三件事：

• 雇更多的人
• 提高设计速度
• 找到一个适用于多个问题的解决方案

通过复用设计，设计系统能够帮助团队更好、更快地构建产品——复用性使规范成为可能。这是设计系统的核心和价值。一个设计系统是一个可复用组件的合集，由清晰的规范作为指导，组合在一起构建成各种的应用程序。

50 多年来，工程师们一直在遵循着这个理念执行工作。现在是时候让设计充分发挥其潜力加入他们了。

用系统思维扩展设计

你可能已经清楚地意识到，设计系统已经成为当今软件行业的一个热门话题，并且理由也很充分。很多企业投资设计系统，因为他们认识到产品体验能够带来竞争优势，不仅能吸引和留住客户，更降低产品学习成本。

在重视设计系统的公司内部，通常能看见这种情况：

• 设计团队不断壮大。
• 设计师分布在整个公司的团队中，可能在多个部门。
• 设计在整个公司平台上的各个产品中都起着关键作用。

如果你是设计师，那么前面所说对设计的投资听起来可能会令你很兴奋，但其实也带来很多挑战。当一个应用由不同的团队负责迭代各自模块的时候，你将如何跨平台设计一致的 UI？又如何使所有团队能够进行快速迭代？当团队的设计师设计出新的独立样式时，你又将如何处理这种不可避免的设计需求？

要了解如何应对上述的挑战，我们要先了解什么是设计系统。设计系统将个体和整体两个概念各自的优点结合在一起。

1. 标准

拥有 MAC 用户界面的技术知识是产品设计的关键因素，但了解用户界面背后的理论，才能够帮助你创造出色的产品。——苹果人机交互指南

为了设计卓越的用户体验，不仅要了解设计系统背后的内容，还要了解其设计的原因。我们一般会通过建立和遵守标准来达成共识，这样做能消除主观性和歧义性，保证产品团队内部不会出现摩擦和混乱。

这套标准的内容涵盖了设计和开发。例如对命名约定、无障碍标准和文件结构等等，帮助团队达成共识，减少出错。

视觉语言是设计标准的核心部分。定义颜色、形状、类型、图标、布局和动效的样式和用法对于创建品牌一致的用户体验至关重要。系统中的每个组件都包含这些元素，它们在表达品牌特性中扮演着不可或缺的角色。

没有标准，决策时就会无据可依。这不仅不能扩展设计，还会造成复杂、差劲的用户体验。

超越平台

视觉语言可以不局限于单一平台，可以在 Web，iOS，Android 和其他平台上延续。将规范文档展示在设计系统网站的醒目位置，能够帮助系统开发者了解组件的样式和交互模式。例如，Google 的 Material Design 就深入到其产品视觉语言的各个层面。

2. 组件

组件是系统中复用代码的一部分，它们充当应用程序界面的基础。组件的复杂性各不相同。将组件简化为单个功能（如按钮或下拉菜单）可以增加其灵活性，使其更易于复用。复杂的组件，如特定类型数据的图表，可以很好地满足其应用场景，但是这种复杂性限制它的使用场景数量。组件的复用性越高，需要维护的次数就越少，规模也就越简单。

基于组件的开发通过复用代码来减少技术开销。建立标准规范了这些组件的用途、样式和用法。两者结合在一起，就相当于为你的产品团队配备了一个清晰的系统，让他们了解到为什么和怎么做。

设计系统的价值

让我们详细看看设计系统如何帮助你解决一直以来的痛苦。

1. 扩展式设计

随着团队的成长，设计师通常会将注意力集中在应用程序的独立功能区域，如搜索和发现、帐户管理等。这就会导致设计碎片化，就像是一座设计的巴别塔，每个设计师都将他们的设计语言往上添。当设计师单独而不是系统地去解决问题时，就会发生这种情况。

没有通用设计语言统一产品和设计，用户体验就会开始崩溃。当缺乏设计规范时，设计讨论就变得毫无用处。为了使团队内部保持一致，必须要有一个共享的来源——可供参考的官方样式库。

大多数情况下的样式库都是静态的内容，例如设计模版。但是静态的参考几乎立刻就会过时。这就是为什么有的团队会建造像 Shopify’s Polaris 站点这样的网站——一个设计系统站点，用该设计系统构建而成，记录系统的所有方面，包括组件、指南和交互最佳使用场景。因为它是与系统一起构建的，所以它能够保持其永远是最新的。

对于产品团队而言，内部设计系统站点是最佳、最易访问的共享来源。它提供了一个引力，使团队成员保持一致和同步。

2. 管理你的债务

随着应用程序和团队的时间积累，会慢慢形成债务。这种债务不是金融债务，而是技术和设计债务。这些债务是因为解决独立问题获得的。设计债务由大量不可复用和不一致的样式和惯例组成，而维护它们是不可能完成的任务。随着时间的推移，这些债务的累积会成为减缓增长的巨大负担。

创造行为本身并不会产生债务——就像花钱本身并不会产生金融债务一样。但使用设计系统将使你的设计和代码保持足够简洁，同时仍然允许你进行升级和迭代。

3. 一致的设计

一致且重复使用的标准化组件，使你应用程序的易用性大大提升。标准化的组件还能让设计师花更少的时间关注样式，花更多的时间专注于提升用户体验。

4. 更快的原型

在设计系统下工作，你可以像玩乐高一样快速拼凑流程和交互，构建无数的原型和方案进行快速验证，从而帮助团队快速获得数据和结论。

5. 提高可用性

页面样式的不一致会影响产品的可用性，当 CSS 因为数不清的不一致样式元素和交互增加时，页面加载时间也会加长，这会导致很糟糕的用户体验。它还可能产生冲突的 CSS 和 JavaScript，从而可能破坏你的应用程序。通过使用设计程序，通过构建一个整体的组件库（而不是每页）来避免这些冲突，从而花费更少的时间来保证产品质量。

6. 建立可访问性程序

可访问性在组件级别就可以实现，针对残疾人士、网速较慢和老旧的计算机上进行优化。这是一个建立易用性程序很好的方法， 在第 3 章「构建设计系统」中，Katie Sylor-Miller 解释了设计系统如何帮助你改善产品的可用性，并保证遵守你所在国家/地区的法律。

（译者注：美国残疾人法案于 1990 年 7 月通过并签署，其中有规定网站的可用性必须遵守《美国残疾人法》（ADA）的相关内容。）

设计系统的误区

即使有上述说的这些好处，在团队内部推行一个设计系统的时候，仍然很难说服团队成员。设计师可能会感到局限或束缚，但通常这些被感知到的弱点正是设计系统的最大优势。

让我们来揭穿那些你在推行设计系统时经常会遇到的误区吧。

误区1：过于局限

误区：负责深入独立业务的设计师看到的设计标准可能会与其他需求的不一样，因此，他们会认为通用的设计系统过于局限，可能无法满足某些特定业务的需求。

现实：设计师通常会设计出自定义的解决方案以满足应用中的独立的业务，从而增加了设计和技术的负担。而使用设计系统，这些被设计的新解决方案可以被反馈到设计系统里面，使每个人都可以使用这些改进方案。

误区2：缺乏创造力

误区：如果设计师被限制在一个设计系统下做设计，那么他将不能去自由地探索设计风格。前端的工作通常包含着各种样式风格的更新。对应用程序的风格进行改版通常不是一个小任务。这也可能是一个很大的风险，因为从事这项工作会移除一部分的旧资源，可能会对可用性产生负面影响。

现实：设计系统的组成部分是相互关联的，这意味着当一个位置进行更改时，这项更改会在整个系统中同步，这使得系统内的样式更新工作变得轻而易举，但影响却大得多。以前是几周甚至几月的工作量，现在可以在一个下午就能完成。

误区3：一劳永逸

误区：设计和构建完设计系统后，工作就完成了。

现实：设计系统是有生命的，这意味着需要不断对其进行维护和改进。但是由于应用是由设计系统的复用性组件提供支持的，因此该应用会自动同步设计系统的改进内容，从而减少维护应用程序的工作量。这就是设计系统提供的扩展能力。

总结

设计系统不是一时流行的方法，也不是未经检验的假设。为了让设计找到与技术的快速发展相匹配的同等方案，基于组件的设计和开发是一种行之有效的可靠解决方案。

现在你已经了解了创建设计系统的真正价值，让我们在下一章中深入探讨实际的设计过程吧。

更多一线团队的实战经验：

欢迎关注译者的微信公众号：「彩云译设计」