你可以拥有一个全面的设计系统，其中包含大量结构良好的组件、详尽的文档、周到的指导方针以及经过深思熟虑的设计语言。但是，如果设计系统的使用者无法完成他们要完成的工作，则整个系统可能会被淘汰。
产品团队的主要关注点通常是忙于开展工作，而不是维护设计系统的完整性。团队通过发挥创造力找到完成工作的方式，其中可能涉及破坏风格，创建大量一次性组件或完全放弃设计系统。正如侏罗纪公园（Jeff Jussic Park）里的 Jeff Goldblum 所说，“生命终究会自己找到出路。（Life, uh, finds a way.）”
所以对于设计系统的创建者而言，需要建立一套清晰的治理流程来帮助用户了解遇到以下情况时该怎么办：
- 他们找不到能满足他们需求的组件
- 只能以90％的方式获得设计系统组件，但不是100％
- 他们对设计系统有疑问或疑虑
在与大型组织的设计系统合作中，我们发现设计系统治理流程是经受时间考验的健康设计系统的最重要组成部分之一。
当杰出的设计师Inayaili deLeónPersson在使用科能软件有限公司（Canonical）的Vanilla设计系统工作时，她发表了一张惊人的流程图，详细介绍了新组件是如何进入其系统的。
作者在过去几年的客户工作中一直在以Yaili的总体结构为基础，并在治理流程中增加了更多阶段。具体可查看此图表中规划的治理流程，作者将在本文详细介绍该过程中的每个步骤。
image
步骤1：产品团队使用设计系统来帮助设计和构建新工作
团队应该默认使用设计系统的组件来帮助创建新产品。
最好的情况是，一个团队在组件库中找到他们需要的组件，并发现它满足了他们的所有要求。他们插入该组件并继续处理更紧迫的事情。
步骤2：当设计系统的组件不存在或不满足要求时会发生什么？
image
如果团队进入设计系统以后找不到所需的组件，或者现有组件不能满足所有要求，或者不确定是否系统具有所需的组件，第一个步骤是让产品团队通过团队协作软件、问题跟踪器（Github，Jira等）或其他渠道与设计系统团队联系（注意：设计系统团队应建立明确的支持协议）。
团队将通过进行对话以更好地理解问题，然后确定是否需要开展新工作。设计系统团队通常可以帮助指导产品团队找到符合要求的现有解决方案。记住，一定要进行对话！
步骤3：如果需要开展新工作，是使用 snowflake 还是设计系统的一部分？
image
如果团队同意需要开展新工作，那么首先需要做的工作是：
- snowflake，一个一次性组件，仅与某个特定产品或用例相关（例如抵押计算器，超级复杂且特定的数据可视化，或任何感觉特别明显的化抽象为通用的组件）
- “设计系统”的一部分，为所有产品服务的库的一部分或变体（例如，添加面包屑组件或可能向卡片组件添加“X”按钮以便可以使其关闭。）
如果团队认为需要开展的工作是snowflake，则将根据设计系统的snowflake准则将工作添加到特定产品团队的待办事项（注意：设计系统团队应为snowflake管理建立准则，以便能够跟踪组件并简化在设计系统中的重构）。 如果团队确定该工作是设计系统的一部分，则该工作将被添加到设计系统的待办事项中成为要完成的工作的一部分。
然后，团队将优先安排要完成的工作。如果工作是snowflake，那么产品团队将会自己执行工作。但是，如果设计系统能够正常工作，那么负责最初探索的团队将取决于许多因素，包括优先级，紧迫性和可用资源。
步骤4：原型初始概念
image
一旦确定由哪个团队来领导初始概念，该团队将为所要开展的工作制作初始概念。可以采用线框，草图，comp，浏览器内原型或任何其他形式，这些形式可以快速清楚地阐明用例并定义要完成的工作。
步骤5：审查初始概念
image
设计系统团队和产品团队将再次聚集到一起，以审查概念并确定概念是否满足所有要求。如果发现缺少任何内容，团队都将遍历该概念，并且将继续进行审查，直到满足要求为止。
步骤6：正式设计系统的设计/开发和测试过程
image
在两个团队都批准了该概念之后，设计系统团队将接手该工作，并将其作为设计系统产品路线图的一部分。
此过程涉及在静态设计工具（例如Sketch或Figma）中制作新组件或变体，以及在设计系统的前端工作环境中构建组件（例如，“功能/可关闭的卡片”）。该组件将遵循设计系统的代码准则，并将考虑可重复使用性、灵活性、可组合性、可访问性、性能和其他最佳实践。
构建组件后，将在以下区域进行测试：
- 内容：此组件或变体可以处理各种内容情况（例如冗长的或国际化的文本）吗？
- 可访问性：此组件是否满足或超过可访问性要求并遵循可访问性准则？
- 跨浏览器/设备：跨可支持的浏览器和设备测试
- 自适应：在整个分辨率范围内进行测试，以确保在任何屏幕尺寸上均能正确显示
- 功能：功能的单元测试
- 创建压力测试示例：以捕获常见、边缘和压力场景
- 内部代码审查：确保组件代码符合设计系统编码标准
- 内部设计审查：确保工作遵循设计语言并满足所有设计要求
- 在应用程序中进行试用：与用户开发人员协作测试应用程序中组件的预发行版本以确保一切正常，使用API会更直观。
- 任何其他内部质量检查和测试
步骤7：与产品小组进行最终审查
image
由于概念、设计或执行可能由于上一步中详述的工作而发生了变化，因此产品团队和设计系统团队将开会进行最终审查。如果产品团队不批准工作，则会进行迭代，并且将重构团队，直到产品团队批准工作为止。
步骤8：文档和发布阶段
image
一旦签收，组件/版本将被记录在样式指南网站上，代码和API文档将被最终确定，变更日志将被更新，并且'feature'分支被合并到'development'分支中，这意味着为下一个版本上场做准备。
步骤9：发布新的设计系统
image
是时候创建一个新版本了（注意：团队应该建立一个发布设计系统的节奏；参见这篇 Nathan Curtis发布的文章，根据系统概述的语义版本控制准则，发布了包含新作品（以及任何其他新作品）的设计系统的新版本。设计团队通过所有适当的渠道传达新版本的信息（注意：设计系统团队应确定使用哪些传播渠道来发布新版本）。
步骤10：采用产品团队和质量检查流程
image
产品团队将新版本的设计系统引入他们的应用程序环境并测试新工作。如果出现问题或错误，请按照支持过程来处理任何问题（注意：设计系统团队应再次建立明确的支持指南，详细说明如何处理错误）。
如果未发现错误，则将为下一个版本的应用程序进行工作，并且新组件或变体将进入实时应用程序！
适应和发展
从“我看不到我需要的组件”到“现在我们的产品中已经启动了新组件”这一过程相当漫长。但是，我们发现以这种精细的方式进行说明可以帮助建立产品团队与设计系统团队之间的信任，并减少对创建新产品的担忧。
值得注意的是，该文章的标题是“设计系统治理流程”，而不是“特定设计系统治理流程”。虽然该工作流程可能是一个很好的起点，但是建立最适合你组织的治理流程绝对是必不可少的。例如，将为一位客户进行重大更改，以便做更多的事情。在发布设计系统的新版本之前，质量检查人员将与产品开发人员一起工作。建立自己的治理模型，并不时重新访问它，尤其是当你发现有对该设计系统使用不愉快的用户时。这很可能表明你已建立的流程没有成功。没关系（这都是一个学习过程！），但是一定要反复进行迭代和改进，直到找到一个合适的解决方案。
还有一点值得说明一下，就是在设计系统存在之前就应该建立此过程！我发现与在设计系统开展中处于早期阶段的客户一起完成此过程将有利于发现关键用户是谁，他们会寻找哪些工具，他们想要如何组建团队和流程，等等。
建立设计系统治理流程可能是防止你的设计系统被别人取代可以采取的最重要措施之一！
（编译完）
英文原文：地址
原文作者：Brad Frost
编译作者：微博/公众号@设计吐司
以上译文仅代表原作者观点。如需转载请遵循CC版权协议正确标明出处。
网友评论