一个好的设计系统的秘诀

这篇文章得到了我们亲爱的 Backlight 朋友的大力支持，Backlight 是一个协作平台，使前端团队能够构建和发布出色的设计系统。 谢谢！

理论上，每个人对“设计系统”的含义都有一个相对相似的概念，尽管随着我们接近现实世界，细微差别开始出现。 目标可能仍然相同，但不同的组织将需要不同的策略来实现它们。 与工程和架构中的许多复杂任务一样，没有什么灵丹妙药可以打造一个好的设计系统。

尽管成功的努力有一些共同的模式，这些模式使得工具和最佳实践得以出现。 在本文中，我们将了解哪些解决方案适合设计系统的保护伞，以及您在整个项目中需要关注的一些重要步骤和检查点。 我们的经验可能会有所不同，但希望你能从我个人失败和成功的地方学到东西。

目标与意义

如果我们将“系统”视为协同工作的部件的组合，而将“设计”视为某事物的外观和功能计划。 然后我们可以将设计系统理解为定义的集合，这些定义将指示系统互连部分的外观、感觉和工作模式。 这仍然是相当抽象的，但足以理解它不仅仅是看起来。

它不是您像拼图一样组装并获得一致布局的组件库。 一个设计系统确实有一个表现方面，但它也是关于功能和集成的。 这是关于经验。

• 用户体验
  具有可靠且功能一致的用户界面。
• 开发者体验
  具有易于集成的组件和定义的模式。
• 利益相关者经验
  对产品如何发展和发展的总体概述。

有这么多移动部件，可以理解的是，所有设计系统都没有一个单一的答案。

有意与有机

当一个团队决定创建一个设计系统时，他们需要预先决定两种方法：

• 有机的
  以现有应用程序为参考，提取其中的部分并将它们抽象到足以供另一个应用程序使用。 这种方法从一开始就包含较少的决策，但需要团队做出更多的反应性努力来适应采用者新发现的需求。 架构决策倾向于根据需要而不是主动做出。
• 故意的
  标记、模式和组件是提前考虑的。 定义最小可行产品 (MVP) 的边界并开始工作。 对于这种方法，制定目标和要求是使期望与利益相关者保持一致的重要步骤。

有机的

当允许设计系统有机地发展时，努力的成功归结为利益相关者和采用者的支持。 以及团队在清除沿途发现的所有未知数时能够做出反应的效率，而不会在持续的支持下过度破坏。 这是一条棘手的道路，沟通是关键。 没有明确的行动路径，因为它与团队的环境紧密相关。

此外，在系统运行时很难对其进行调整（询问您当地的电工），并且由于任务需要时间，要求可能会发生变化：市场不会等待您的组件库。 对于有机设计系统来说，通常的“成败”时刻是找出组件 MVP（最小可行产品）的开发故事。

一方面，我们的开发人员和设计人员希望打造最佳体验和典型的代码质量； 另一方面，有 KPI、ROI 及其首字母缩略词来衡量成功。 找到平衡并保持可扩展性是很棘手的。 如何把未完成的东西抽象出来就更棘手了，避免那些后续任务在积压中被遗忘是价值百万的产品管理问题。

在处理有机方法时，能够在您的设计系统上快速且渐进地迭代成为基本要求。 它还需要您的消费者开发人员更加清晰（如果有不同的团队：一个创建设计系统，另一个创建产品功能）。 两者都必须清楚地将期望与产品要求和开发人员体验要求保持一致，以实现适当的共生。 因为如果设计系统使用起来很烦人，或者如果它以任何方式使用户体验变得更糟，那它什么都不是。

故意的

在有产品使用之前，有意识地选择构建设计系统时，需要进行更多的规划、清除未知数和准备基础设施。 另一方面，约束带来了更多的清晰度。 目标和期望。 如果在离开港口之前对帆进行双重检查，风暴就不那么可怕了。

当提前计划时，系统的可预测性也会增加，这是因为设计系统成为自己的产品，而不是让其他人变得更好的工具。 通过这种抽象，其他人使用的模式和解决方案更容易传输。

尽管最初选择 Intentional 而不是 Organic 对经验较少的团队来说可能会适得其反，因为没有要测试的概念验证，但在开始时避免常见的陷阱尤其有用。 “站在巨人的肩膀上”是一个常见的行话，在这种情况下是真实的。 所以，这方面的最佳配方应该大致是：

1. 确定基本要求；
2. 对类似案例及早彻底研究；
3. 略去 2 的结果以获取隐含的解决方案和策略；
4. 通过组合常见的解决方案并添加自己的酱汁，将其全部变为您自己的；
5. 迭代。

这五个步骤听起来简单明了，但事实并非如此。 很容易跳过一个需求收集或缩短研究时间。 不过，有一条建议：如果您忘记了其中任何一个，您将在第 4 步支付利息。

为效率而建

当依赖项更新以任何方式破坏他们的应用程序时，没有包消费者喜欢。 当所讨论的包是设计系统的一部分时，也没有什么不同。 实际上，有人可以指出情况更糟。 内部依赖破坏应用程序的反弹往往比它是开源包时更大，此外，UI 更改往往会首先在最终用户面前“悄无声息地破坏”：这尤其令人沮丧。

考虑到这一点，我们已经可以列出一些问题：

• API 文档
  使其易于发现和使用。
• 版本控制
  指示发布预计将如何影响消费者。
• 变更日志
  指示每个版本进行的更改。
• 释放
  一种保持稳定代码易于为所有消费者交付的明智方法。
• 开发环境
  目前还没有应用程序使用它，必须弄清楚如何展示和开发工件。

需要指出的是，这些项目中的每一项的优先级可能会根据您的里程而有所不同。 但随着设计系统的扩展、采用的增加和功能的增长，它们的必要性将会增加。 它们可能不足以阻止团队前进，但如果能力偏向于找出这些解决方案，它们肯定会阻碍生产力。

真相之源

许多团队最终面临的另一个痛点是识别设计系统中的真实来源。 是代码、UI 还是文档？ 对于很多种类的产品，我们只看消费端，我们可以很容易地识别出主要的输出是什么。 在这种情况下变得棘手的原因是因为每种消费者都会以不同的方式使用它，因此答案会根据所询问的人口统计数据而有所不同。

设计系统通常是组件库、文档和样式指南的混合体。 不仅每件文物的消费者不同，而且工匠也不同。 开发人员、设计师、技术作家； 需要不同的人来创建每个输出。

热土豆

为了保持交付的一致性，沟通和协作是关键。 并且已经建立的类似瀑布的过程对任何一方来说都不令人鼓舞。

没有基于每个专业的协作或迭代设计（双关语）空间。 设计师通常不知道一些代码限制，而开发人员对输出的用户体验一无所知。 这种方法并不是非常有偏见，可以用它创造出好的产品。 但是一个伟大的人是很难的，除非团队积极努力纠正它，否则流程的每个部分几乎都是断开的。

总是令人惊叹的 Dan Mall 和 Brad Frost 为新工艺创造了同样伟大的名称：Hot Potato。 这个过程不仅鼓励沟通，而且通过统一工作的真实来源，直接将协作强加给团队。 这样一来，不仅每个交付的工件都有一个共同的来源，而且它们也是联合团队专业知识的产物。

然而，让这种无摩擦的协作说起来容易做起来难。 甚至并排坐着躲避“你被静音了”、“我的连接掉线了”和“你能听到我说话吗？” 烦恼，当信息交流并置时，往往很容易变得非正式，然后该过程可能最终难以记录或过于同步。 我们想要更少的瓶颈，而不是更多。

同行之间的实时协作已经达到了很大的程度。 像 VSCode Share 或 Figma 的 FigJams、云 IDE 一样，有很多选择。 但是当涉及到不同专业之间的迭代时，它并不是非常简单。 将此添加到前面部分中提到的工具、架构或流程堆中，甚至在开始工作之前，您就有大量工作要做。

构建系统

如上所述，维护设计系统是一项繁重的工作。 最好的建议可能是尽量不要从头开始做事。 在方便的地方使用社区资源。 这样做可以减少维护系统特定点的时间，并且如果工程师和设计师已经熟悉系统的某些部分，这将有助于他们入职。

进来背光。 它是一个平台即服务，它以一种自以为是但灵活的方式将一系列工具组合在一起，以加速整个架构设置。 您可以从头开始，也可以选择最适合您项目的入门模板。 如果不是完全必要的话，不会重新发明轮子，它们在所有启动器中都使用社区资源（我尝试过的 Yogi 是基于 ChakraUI 的），它们的维护更少，并且消费者不必担心被锁定。 此外，代码将被推送到您的版本控制平台，因此只需几个 shell 命令即可在必要时移出。

到那里后，它将安排与版本控制平台（支持 Gitlab 和 GitHub）、基于 Storybook 的沙箱、基于 VSCode 的 IDE、单元测试，甚至发布到 NPM 注册表（最后这取决于您与他们的计划，它可以是您的帐户或他们的帐户）。

多个输出

我们之前映射了大多数设计系统需要至少 3 种不同的输出：文档、代码、用户界面。 一旦架构准备好输出它们中的每一个，团队通常会发现另一个挑战：保持它们同步。 开发人员总是渴望以原子方式进行更改，您触摸一个地方，它们就会分散到使用该信息的每个地方。 在设计系统中，这并不总是很清楚如何完成。

如果您没有遵循 Hot Potato Process，很容易忘记开发人员已经解决了哪些 UI 更新。 即使你这样做了，也会有文档。 背光通过搭配一切解决了这个问题。

一旦更改完成，无需离开平台的仪表板。 可以检查更新的实时文档。

而这一切只是触及了他们可以用来提升你的架构的表面。 您还可以获得：

• 使用“视觉审查”功能对拉取请求进行屏幕截图测试
• 带有内置单元测试的测试驱动开发支持
• 带实时预览的沙盒

它是您设计系统的完整开发环境。 即使您决定不使用它们的启动器，您仍然可以获得所有这些集成。 基础设施可以让您构建组件库，从头开始为您的设计系统提供支持。

实时远程协作

如前所述，Hot Potato Process 可能会为团队设置远程和异步工作方式带来麻烦。 背光解决了这两个特点的组合：

• 设计整合；
• 分享一个实时链接。

设计集成将您的设计工具中的设计工件带入同一平台。 因此，团队的其他成员可以直接从同一个仪表板查看、添加评论和参考工作：

借助此功能，无论您的团队位于何处，烫手山芋流程都可以从绘图板开始。 在不切换标签的情况下，它也可以通过链接共享功能来平滑地来回编码过程，用他们的促销 gif 来解释比我自己做的任何事情都好。 开发人员可以共享其工作的实时远程链接，而无需在任何地方发布内容，也无需中间过程，这对于需要快速迭代详细工作的团队来说是一个很大的推动力。

外卖

如果还没有，希望现在更清楚创建和维护设计系统需要什么。 不仅仅是少数 CSS 类、标记定义和字体； 它是工具、积极的支持和倡导。 项目的有用性取决于其输出的质量以及它适应不断变化的需求的速度。

因此，如果不出意外，请准备好在创建项目时提高生产力和效率。 如果您仍在寻找自己的立场，Backlight 等工具将帮助您实现合理的默认设置和开箱即用的出色用户体验。 如果您已经熟悉特定架构，请明智地选择您的战斗并使用社区来处理其余部分。