随着应用开发变得越来越动态和复杂，交付风格一致且好用的产品成为了一项挑战，尤其是在有多个团队参与不同产品开发的大型组织中。设计系统定义了一系列的设计模式、组件库以及良好的设计和工程实践，以确保数字产品的一致性。设计系统从过去的企业风格指南演变而来，提供易于查找和使用的共享组件库和文档。通常，设计系统的风格指南以代码的形式记录并进行版本控制，比简单的文档记录更加清晰且易于维护。设计系统已经成为跨团队和学科进行产品开发时的标准方法，每当需要新的视觉组件时，团队不用重新发明轮子，因此能够集中精力，专注解决产品本身的种种挑战。
我们的经验表明，团队在构建设计系统时很少采用产品为中心的思维方式。共享组件库和文档的主要消费者是产品开发团队。在使用产品为中心的思维方式时，设计系统所有者应该与消费者（开发团队）合作，建立共情。我们发现，许多组件库之所以受到批评，是因为所有者团队无法快速响应消费者的需求，并且无法接受来自外部的贡献。产品为中心的思维方式还要求组织思考是否应该允许和怎样向设计系统做出贡献，以及如何管理这些贡献——在这个话题上，我们推荐采用设计系统决策记录 。对我们来说，维护一个良好的设计系统或组件库不光是技术工作，也同样是社交工作。
随着应用程序开发变得越来越动态和复杂，以一致的风格交付可访问且可用的产品变成了一个挑战。在拥有多个团队从事不同产品开发的大型组织中，尤为如此。 设计体系 定义了一组设计模式，组件库，以及良好的设计和工程实践，以确保数字产品的一致性。在过去的公司风格指南基础上，设计体系提供了易于查找和使用的共享库和文档。通常指南是以代码的形式编写，并且受版本控制管理，所以相比简单的文档，它更明确且易于维护。设计体系已经成为跨团队和学科产品研发时的标准方法，因为它可以使团队更加专注于解决围绕产品本身的战略挑战，而无需在每次需要新的视觉组件时都重复造轮子。
随着应用程序开发变得越来越动态和复杂，高效地交付风格一致可访问和可用的产品变成了一项挑战。设计系统定义了一套设计模式、组件库以及良好的设计和工程实践的集合，以确保数字产品开发的一致性。在跨团队和学科的产品开发中，我们发现设计系统是对工具箱的有用补充，因为它们让团队可以专注在产品本身更具战略性的挑战上，而无需在每次需要添加一个视觉组件时都不得不重新发明轮子。你用于创建设计系统的组件和工具的类型都可能存在很大的不同。
