设计系统有助于梳理出一套规范化的模式与实践，不仅能在整个组织内带来一致的体验，还能通过代码复用提升工程团队的效率。一旦你说服组织认可这套系统的价值，并推动多个团队采用，接下来在长期管理、扩展和优化系统的过程中，就会面临诸多挑战。

资源投入

首要挑战之一便是为系统保障资源。设计系统往往由充满热情的工程师和设计师自发推动、逐渐发展而成，他们希望在不同应用之间复用模式与代码。这个群体可以组成一个“核心团队”来引导系统的发展，定期讨论共享组件库的愿景，决定哪些内容应该纳入这些库，以及 API 该如何设计。

然而，维护和规划本身就是一份全职工作。指望大家在本职工作之余兼顾这些，根本难以为继。组件 API 之间开始出现不一致，代码评审因实现方案的分歧而延迟，这些都会让开发者感到沮丧。

组建一个平台团队来负责系统的开发并制定贡献流程，有助于解决这一问题。让工程师专注于系统的长期健康，能够为设计系统的演进带来一致性，并让新增内容的流程更加清晰。

定义生命周期流程

借鉴Atomic Design 的理念，为模式的变更制定清晰的流程会很有帮助。一些常见需要考虑的问题包括：

• 何时应该新增组件，何时应该扩展现有组件？我们需要哪些信息来做判断？
• 如何定义组件的成熟度，并将其传达给使用者？如果新增了一个组件，我们是否希望它立刻就在生产环境中被广泛使用？
• 我们的 API 设计理念是什么？更倾向于灵活的 API，还是更受约束的 API？
• 如何管理破坏性的 API 变更，包括废弃或移除组件？我们会提前多久通知使用者？是否有大版本发布计划以便团队提前规划？

保障质量

设计系统对其他工程团队的核心承诺之一，就是减少他们的工作量：使用我们预先构建好的组件，就不必自己从头搭建！如果你的改动频繁破坏这些组件在他们应用中的使用方式，很快就会引发不满，因为意料之外的调试工作会落到他们头上。

可以使用Storybook 创建一系列“stories”来测试应用团队使用组件的各种方式。每个 story 都代表一个功能/视觉测试用例，确保所有使用场景都被 story 覆盖，有助于避免给使用者引入问题。将 Storybook 与Chromatic 结合，还能增加视觉回归测试，并让设计师更方便地参与评审。Storybook 的play functions 则可以覆盖那些需要用户交互的场景。

使用react-testing-library 编写单元测试，是创建可维护测试的好方法，同时也能促使大家编写更具可访问性的组件。

对自己的设计系统进行内部试用，也是在下游使用者发现问题之前捕捉问题的有效方法。在设计系统内维护一系列分子和有机体，有助于更早地发现原子层面的问题。

获取反馈，发掘未来机会

作为设计系统的维护者，你可能会被问到：设计系统什么时候才算“完成”。事实上，随着组织不断构建新应用、遇到新的使用场景、涌现出新的模式，设计系统会持续演进。品牌重塑和设计团队方向的调整，也会给系统带来不小的冲击。

你需要定期从用户那里获取反馈：工程团队、设计师、产品经理以及终端用户。设计系统本身就是一个产品，需要有人承担产品负责人的角色，确保它朝着正确的方向发展，并持续为所有用户解决问题。