设计系统是关于关系的

设计系统非常有用。 它们提供了可重用的元素和指南，用于在产品之间构建一致的“外观和感觉”。 因此，用户可以将他们从一种产品中学到的知识应用到另一种产品中。 同样，团队可以推出经过良好测试的导航或评论模式，使产品更值得信赖。 有效的设计系统以可重复的方式解决无聊的问题，以便开发人员和设计人员可以专注于解决新问题。

然而，当有人在会议中使用“设计系统”一词时，我永远无法确定会发生什么反应。 我看到了对尝试一种新的工作方式的好奇和兴奋，但我也看到了对限制设计师创造力的系统的想法感到沮丧和担忧。 一些设计师认为设计系统会削弱创造力，或者它们是寻找问题的解决方案。 设计系统会随着时间的推移而碎片化，导致团队停止使用它们。

不过，设计系统并没有消失。 一项调查显示，2018 年只有 15% 的组织缺乏设计系统。 这比前一年的 28% 有所下降。 一些团队使用大型通用设计系统，例如 Google 的 Material Design，而其他团队使用更小、更定制的系统，例如 REI 的 Cedar 和 Mozilla 的协议。

设计系统应该赋予团队权力，而不是限制他们。 为此，我们需要开始更全面地思考。 设计系统不仅仅是代码、设计或文档。 就是所有这些东西，加上系统的制造者和使用它的人之间的关系。 它不仅包括 CSS 文件和 Sketch 文档，还包括信任、沟通和共享所有权。 事实证明，有一整个研究领域致力于探索这样的系统。

大局

1960 年的一篇题为“社会技术系统”的论文探讨了技术、人类以及它们所在的更大环境之间的相互作用。 Enid Mumford 解释说，研究人员开始研究如何在经理和员工之间建立更好的关系，但到 1980 年代，他们专注于提高工作效率和成本效益。 2011 年，Gordon Baxter 和 Ian Sommerville 写道，这项研究有助于激发以用户为中心的设计，而且还有很多工作要做。

Baxter 和 Sommerville 认为，今天，关注员工生活质量的“人文”研究与关注员工生产力的“管理”研究之间仍然存在紧张关系。 他们还解释说，同时考虑技术和人机交互很重要：“系统性能依赖于技术和社会子系统的联合优化。”

我认为设计系统是社会技术系统。 它们涉及创建系统的人员、使用系统创建产品的人员以及与这些产品交互的最终用户之间的交互。 它们还唤起了巴克斯特和萨默维尔所看到的效率和人文主义之间的同样张力。

设计系统不仅仅由图像和代码组成； 它们涉及设计师、开发人员、产品经理、首席执行官和 GitHub 上随机人员之间的对话。 这些交互发生在各种环境中——公司、开源社区、家庭——它们跨越文化和组织边界。 组建团队可能意味着将动画、声音设计、数据可视化、触觉和文案等学科的人员聚集在一起。 创建一个成功的设计系统需要同等的技术专长和软技能。

然而，仔细阅读设计或工程新闻聚合器，您可能会看到对“技术子系统”的明显关注——代码和工具，而不是人员和对话。 哪种创意工具最适合跟踪设计令牌？ 应该使用哪些 JavaScript 技术来构建可重用组件——React、Web 组件或其他？ 哪个构建工具最好？

当然，这些问题的答案是“视情况而定！” 谁将设计、构建和使用该系统？ 他们的需求是什么？ 他们在哪些限制条件下运作？ 他们对哪些工具和技术感到满意？ 他们想学什么？

为了回答这些问题，Baxter 和 Sommerville 推荐了两种类型的活动：

• 宣传和认识活动
  了解将创建和参与系统的各种人，并广泛地分享这些信息。
• 建设性的参与
  跨角色沟通，构建原型，并考虑系统的技术和社会部分。

吃吧

在 2019 年初，我是一个团队的一员——我们称他们为“蓝队”——正在为一个大型组织构建设计系统。 我促进了与这个团队和“绿色团队”的非正式聊天，他们正在使用设计系统来构建一个 Web 应用程序。 每隔几周，我们就会让所有开发人员和设计师围坐在一张桌子旁，讨论我们正在构建什么以及我们试图解决什么问题。 这些聊天是我们的“宣传和意识活动”。

我们无权公开我们的设计系统，所以我们做了次好的事情：我们将其视为组织内的一个小型开源项目。 我们将代码放在两个团队都可以访问并请求贡献的存储库中。 蓝队负责审查和批准这些贡献，但任何一个团队中的任何人都可以贡献。 Team blue 也在构建他们自己的应用程序，因此从某种意义上说，他们既是设计系统的用户，又是设计系统的保管人。

这些互动帮助团队构建了更好的产品，但同样重要的是，它们在团队之间建立了信任。 蓝队了解到，人们正在深思熟虑地使用该系统，并在此基础上构建聪明的新想法。 格林团队了解到该系统确实是根据他们的需求量身定制的，因此他们可以使用它而不是反对它。 Baxter 和 Sommerville 可能将这项工作称为“建设性参与”。

我们发现，两个团队都面临着学习新技术和快速交付完整产品的压力。 换句话说，他们已经在相当大的认知负荷下运作。 因此，两个团队同意专注于使系统易于使用。 这意味着回避整个 Web 组件的争论，主要关注 CSS，并确保我们的文档清晰友好。

把它们放在一起

各种规模的组织都创建了可重用的设计元素，以帮助团队构建更一致、更优雅的应用程序。 不同组织的需求和动态在他们的设计系统中表达出来。 这里只是几个例子：

• Google 的 Material Design 有多种不同框架和语言的实现。 它被 Google 内部和外部的各种人使用，因此它具有全面的文档和各种用于设计应用程序的工具包。
• Microsoft 的 Fluent Design System 针对四种截然不同的平台。 与 Material 一样，它包括用于 UX 设计师的工具包和综合文档。
• Mozilla 的协议是在 Sass 和 vanilla JavaScript 中实现的。 它非常注重国际化。 亚历克斯吉布森说，这个系统帮助 Mozilla “以更快的速度创建品牌网页，减少重复的手动工作。”
• REI 的 Cedar 是用 Vue.js 组件构建的，不能与其他 JavaScript 框架一起使用。 Cedar 主要由 REI 的内部开发人员使用，并且与公司的品牌密切相关。 设计系统的代码是开源的，但它的字体不是。
• Salesforce 的 Lightning 设计系统是一个与 JavaScript 无关的 CSS 框架。 它可以选择与 Lightning 组件框架一起使用，其中包括两个 JavaScript 实现：一个使用 Web 组件，另一个使用 Salesforce 的专有 Aura 框架。
• Red Hat 的 PatternFly 旨在为公司的云平台产品提供一致的用户体验，因此它具有相对较高的信息密度并包含各种数据可视化组件。 在对 Web 组件进行了一些实验之后，PatternFly 团队最近从 Angular 切换到了 React。 PatternFly 还包括一个使用 HTML 和 CSS 的与 JavaScript 无关的实现。 （全面披露：我是前红帽员工。）
• IBM 的 Carbon Design System 提供 React、Vue、Angular 和 vanilla JavaScript 的实现以及用于 Sketch 的设计工具包。 Carbon 团队正在试验 Web 组件。 （向 Jonathan Speek 致敬以追踪该存储库。）

像这样的系统是一致且可靠的，因为来自不同团队和角色的人一起工作来构建它们。 这些系统解决了实际问题。 它们不是开发人员试图将自己的意愿强加给设计师的结果，反之亦然。

Josh Mateo 和 Brendon Manwaring 解释说，Spotify 的设计师“将他们的角色视为共享系统的核心贡献者和共同作者——他们拥有一个共享系统。” Mina Markham 将自己描述为 Pantsuit 设计系统中的“工程与设计之间的翻译者”。 Jina Anne 深入研究了设计系统背后的团队动态和用户研究：“剧透警报！ 你需要的不仅仅是设计师。”

让我们建立一些东西！

现在我们已经完成了研究和一些示例，让我们来谈谈如何构建一个新的设计系统。 从与人交谈开始。 弄清楚谁将使用并为您的设计系统做出贡献。 这些人可能跨越多个学科——设计、开发、产品管理、业务等等。 了解人们的需求和目标，并请他们分享他们正在做的事情。 考虑安排一次非正式会议，提供小吃、咖啡或茶，营造温馨的氛围。 与这些人建立定期沟通。 这可能意味着加入共享聊天室或安排定期会议。 保持语气随意和友好，并专注于倾听。

当你谈论你正在做的事情时，寻找常见的问题和目标。 您可能会发现团队需要显示大量数据，因此他们正在研究用于显示表格和生成报告的工具。 优先解决这些问题。

还要寻找类似主题的重复模式和变化。 您可能会发现不同团队的按钮和登录表单看起来有些不同。 这些变化有什么意义？ 哪些变化是有意的——例如，主按钮与辅助按钮——以及意外发生了哪些变化？ 你的设计系统可以命名和编目有意的模式和变化，它可以消除“意外”变化。

这里的目标是与使用设计系统的人建立一个快速的反馈循环。 更快的反馈和更小的迭代有助于避免在错误的方向上走得太远而不得不大幅改变路线。 PJ Onori 将这些突然的、巨大的变化称为“冲击”。 他说，一些挫折是好的——这表明你正在学习和应对变化——但太多可能会造成破坏。 “你不应该害怕颠簸，”他说，“但你需要知道它什么时候有用，以及如何帮助减轻它的缺点。 减轻痛风不利影响的最佳 [方法] 之一就是从小处着手——从小事着手。”

考虑通过设置一些基本元素从小处着手：

• 用于存储代码的版本控制系统。 GitHub、GitLab 和 Bitbucket 都是不错的选择。 确保使用该系统的每个人都可以访问代码并提出更改。 如果可能，请考虑将代码开源以覆盖尽可能广泛的受众。
• 实现系统的 CSS 代码。 使用 Sass 变量或 CSS 自定义属性来存储“设计标记”——常见的值，例如宽度和颜色。
• 一个 package.json 文件，它定义了应用程序如何构建和安装设计系统。
• 演示如何使用设计系统的 HTML 文档，最好使用系统自己的 CSS。

CSS 框架 Bulma 的 node-sass 文档更详细地描述了这些步骤。 如果您想从头开始，您可以跳过安装和导入 Bulma，或者如果您想从一些基础知识开始，您可以包含它。

你可能已经注意到我在这里没有提到任何关于 JavaScript 的内容。 您可能希望最终添加此元素，但您不需要它来开始。 研究最好和最新的 JavaScript 工具很容易陷入困境，而迷失在这项研究中会使入门变得更加困难。 例如，“Web Components 非常适合设计系统的 5 个原因”和“我为什么不使用 Web Components”都提出了有效的观点，但只有您可以决定哪些工具适合您的系统。 从 CSS 和 HTML 开始，您可以收集真实世界的反馈，这些反馈将帮助您在时机成熟时做出决定。

当您发布系统的新版本时，请更新系统的版本号以表明发生了哪些变化。 使用语义版本控制以“1.4.0”之类的数字来指示发生了什么变化。 增加最后一个数字表示错误修复，增加中间数字表示新功能，增加第一个数字表示大的、破坏性的变化。 与使用设计系统的人保持沟通，邀请反馈和贡献，并随时进行小改进。 这种协作、迭代的工作方式有助于最大限度地减少“颠簸”并建立共享所有权感。

最后，考虑将您的设计系统作为一个包发布到 npm 上，以便开发人员可以通过运行命令npm install your-design-system来使用它。 默认情况下，npm 包是公共的，但您也可以发布私有包，将包发布到私有注册表，或者要求开发人员直接从版本控制系统安装包。 使用包存储库将更容易发现和安装更新，但直接从版本控制安装可能是帮助团队入门的简单短期解决方案。

如果您有兴趣了解更多有关事物的工程方面的信息，Katie Sylor-Miller 的“构建您的设计系统”提供了一个很棒的深入了解。 （全面披露：我曾与凯蒂合作过。）

包起来

设计系统由代码、设计和文档以及关系、沟通和相互信任组成。 换句话说，它们是社会技术系统。 要构建设计系统，不要从编写代码和选择工具开始； 首先与将使用该系统的人交谈。 了解他们的需求和限制，并帮助他们解决问题。 在做出技术、设计或战略决策时，请考虑这些人的需求，而不是理论上“最佳”的做事方式。 从小处着手，进行迭代并随时进行交流。 使您的系统尽可能简单以尽量减少颠簸，并邀请反馈和贡献以建立共享所有权感。

通过同等重视工程和人际因素，我们可以在避免陷阱的同时获得设计系统的好处。 我们可以以高效和人道的方式工作； 我们不必二选一。 我们可以授权团队而不是限制他们。 授权的团队最终会帮助我们更好地为用户服务——毕竟，这就是我们首先来到这里的原因。

关于 SmashingMag 的进一步阅读：

• 管理设计系统的技巧
• 在您的设计系统中包含动画
• 超越工具：构建设计系统如何改善您的工作方式
• 为美国政府构建大型设计系统（案例研究）