设计系统团队：目标、挑战与成功

分享我在多个设计系统团队的工作经验，这不是技术性文章，而是更多关注团队的目标、挑战和成功经验。

设计系统是可重用组件、指南、模式和最佳实践（包括可访问性和响应式设计）的集合，帮助公司构建一致且高效的用户界面。它提供了构建块，以在产品或多个产品和平台间创建一致的用户体验。涉及多个学科：设计、前端工程、产品管理等。

设计系统团队是涵盖上述学科的人员组成，负责设计系统。

是否总是需要设计系统？我认为是（至少在大多数情况下），它有助于创建一致的用户体验，加速开发过程，并使基础可维护。

是否总是需要设计系统团队？不，根据公司规模和产品复杂性，您可以使用第三方设计系统，或者产品团队可以在开发产品的同时处理它。但如果您有复杂的产品或大型团队，那么拥有专门团队来确保设计系统得到良好维护、更新并与产品目标保持一致是值得的。

设计系统团队的目标

最终（也是最重要的）目标是让产品团队从非产品相关任务中解放出来。让他们专注于构建产品相关功能和解决用户问题。

他们不应担心（或解决）常见的设计令牌、组件、可访问性、模式或工作流。他们花在这些任务上的每一秒，都是他们没有花在创造更好产品上的时间。

我们可以将该目标分解为更小的目标，这些目标可能因公司和产品而异，但一些常见目标包括：

• 创建设计令牌：设计令牌是定义设计系统视觉风格的变量，如颜色、排版、间距等。它们应一致且可重用。
• 创建基本UI组件：这些组件是设计系统的构建块，如按钮、输入框、模态框等。它们应可重用和可定制以适应不同用例。它们是商品组件；每个设计系统都有它们，但它们应设计良好、实现良好，以确保一致的用户体验。即使它们是常见、简单和商品化的组件，关于一致性仍需做出重要决策。例如，在按钮中，我们可以在左侧或右侧渲染图标，或仅在左侧渲染。
• 确保组件可访问：可访问性是任何设计系统的关键方面，组件应设计和实现为对所有用户（包括残疾用户）可访问。
• 定义常见模式：例如，如何渲染表格数据，元素可以在表格中渲染等。
• 定义工作流：用户应如何创建新元素，遵循的步骤是什么，如何处理错误，如何显示错误等。

设计系统团队的客户是谁

在产品团队中，交付的客户很明确：是客户或使用应用程序的人。

在平台团队中，客户是工程团队。

在设计系统团队中，客户既是客户（因为他们是消费和使用组件、模式和工作流的人），也是产品团队（产品经理、工程师和设计师），因为他们基于设计系统团队提供的组件、模式和工作流创建产品。

这非常重要，因为作为设计系统团队，您需要理解客户和产品团队的需求。您需要创建易于使用、灵活且可定制的组件、模式和工作流，同时满足客户的需求。

遗留问题与一致性

除非您在创建产品之前创建新的设计系统（这不常见），否则您将不得不处理遗留组件、模式和工作流，它们不一定属于正式设计系统，可能是在特定时间为满足特定需求而创建的。

迁移到新设计系统不是一次性任务；您不能冻结产品数周或数月来迁移所有组件、模式和工作流。您需要逐步进行，并导致产品中出现视觉和用户体验不一致。对此没有神奇解决方案；我们可以在时间和数量上最小化不一致，但无法消除它们。

迁移策略

水平迁移

一种策略是首先处理新组件（在设计和前端），并替换与旧组件（或多或少）一一对应的组件。例如，按钮、输入框、模态框等。您需要知道现实世界并不完美，通常新组件与旧组件不一一匹配。您需要定义策略来创建旧组件用例目录，以及如何将它们迁移到新组件（注意：不迁移行为可能是可接受的解决方案）。

此策略允许完成一些旧组件，但需要时间创建新组件，然后替换它们，并且直到在整个产品中使用新组件时才能获得反馈，它会在所有应用程序页面/视图间创建水平不一致。

这样做的一个优点是，您可以使用代码修改工具“自动”迁移旧组件（不完全自动，因为旧组件可能使用运行时计算的属性，难以通过代码修改工具迁移，但有助于过程）。

AI代理可以补充确定性代码修改工具，它们在此过程中也非常有帮助，因为它们可以协助理解上下文并根据您的迁移提示做出迁移决策。

对于与新组件不一一匹配的组件、模式和工作流，您可以做同样的事情：逐步替换它们，但在这种情况下，迁移需要更多对上下文和用例的理解，因此您需要与产品团队密切合作，了解他们的需求以及如何迁移组件、模式和工作流，并且同样，直到迁移完成才能获得太多反馈。

垂直迁移

另一种策略是与特定页面或工作流的产品团队合作，并共同考虑如何迁移它们。在此过程中创建新组件、模式和工作流。此过程的输出不是最终设计系统（尚未创建所有必要组件、模式和工作流），它将是一个完全遵循新设计系统（组件、模式和工作流）的页面，但您将拥有一批组件、模式和工作流，并可以在下一个要迁移的页面中使用它们，该页面将需要更多组件、模式和工作流……这是一种更迭代的方法，允许您在过程早期从产品团队和客户获得反馈并改进它。

在不一致性方面，这将创建垂直不一致，即同一产品的页面之间的不一致。

这种方法可能看起来比前一种慢，因为未参与页面迁移的产品团队仍在使用遗留设计系统，但速度呈指数级增长，因为在每次迁移中，您将有越来越多的组件、模式和工作流用于下一次迁移。

这种方法还创建了“羡慕”效应，因为其他产品团队看到新设计系统全面应用的好处，并推动迁移自己的页面和工作流。

使用这种方法，您也可以使用代码修改工具帮助迁移，但不是一次性迁移应用程序中的所有页面，而是可以为每个迁移的页面或工作流创建代码修改工具。

这是我在以前公司工作的团队使用的方法，非常成功，因为我们能够逐步迁移设计系统（和前端框架），从产品团队和客户获得反馈，并在产品中创建更一致的用户体验，团队规模更小，释放了那些开发人员来从事产品功能工作。

严格管理组件使用

在小型公司或简单产品中，产品团队较少，非常开放的设计系统团队可能运作良好，因为易于验证组件、模式和工作流的使用，并确保产品团队正确（以预期方式：一致、可维护等）使用设计系统。

“开放”设计系统意味着您可以允许开发人员使用所有组件属性，确信他们会以预期方式使用它们，遵循设计系统指南。

基于真实经验的简单示例：

表格组件是设计系统中的常见组件，单元格通常显示文本、数字、链接、徽章等。在开放设计系统中，您可以允许开发人员使用单元格属性传递任何类型的内容或组件，您可以定义一些规则或协议来确保仅使用某些内容类型，何时使用以及如何使用，例如，您定义图像仅允许在第一列使用，链接仅在最后一列使用等。但组件允许单元格中的任何内容，因此开发人员可以以任何方式使用它，但在小团队和小产品中，易于通过培训、文档等沟通规则。

但在拥有多个产品团队和复杂产品的大型公司中，这种方法可能导致不一致。即使规则有良好文档记录，它们也与大量其他文档和指南竞争，容易忘记或误解。

在这种情况下，我们需要更严格管理组件使用，并通过代码强制执行组件、模式和工作流的使用。在表格示例中，我们不能让开发人员向单元格属性传递任何内容；我们需要创建一个系统，仅允许特定内容类型和有限配置。

这种严格性（即使必不可少），尤其是在产品团队之前使用开放设计系统时，可能导致挫败感，开发人员可能觉得这是人为限制，使他们的开发速度变慢，但为了确保产品中一致的用户体验，并使设计系统长期可维护，这是必要的。

最小化挫败感

为了最小化产品团队的挫败感：

• 清晰沟通严格性背后的原因，并让他们参与定义组件、模式和工作流的过程，这与垂直迁移策略配合良好。
• 提供清晰文档和组件、模式和工作流的使用示例，附带良好示例（Storybook是此方面的好工具），明确指南和最佳实践。
• 快速响应他们的反馈/问题/请求，如果您不快速提供答案或实现功能，可能导致寻找捷径或变通方法，从而在产品中导致不一致。

总结

设计系统是一种商品，但这并不意味着它不重要：

• 这意味着它本身没有价值；它需要被产品团队使用来创造价值。
• 这并不意味着您不应关注或投入资源。投资设计系统可以为整个组织带来显著的长期利益。

好的设计系统和好的设计系统团队不会神奇地使您的产品更好，但会使开发更快、用户体验一致，而坏的设计系统会使您的产品更差，提供不一致和令人沮丧的用户体验，并迫使产品团队花时间解决问题和构建本应由设计系统提供的构建块，花时间在非产品相关任务上，而不是专注于构建产品功能和解决用户问题。

作为类比，我们可以考虑电力：它是一种商品，但对许多产品和服务的运作至关重要；如果供应不好，将难以创造好产品，或者如果供应失败，它们将无法使用。设计系统就像电力；它是提供构建产品和服务基础的商品，需要良好才能创造好产品。