使用设计系统扩展前端设计

如果一个组织有一个产品组合，并且每个团队都在构建自己的资产，提出调色板和页面布局，那就不是很好地利用他们的时间。一遍又一遍地构建相同东西的开发人员将宝贵的时间从解决核心工程问题上浪费了，那些忙于为几个月前由其他团队构建的相同 UI 创建规范的设计师可以通过进行用户研究得到更好的服务。

从本质上讲，设计系统要成为一个活生生的、不断发展的系统，代表组织的最佳思维，它需要交付共享价值。要使组件可重用，它需要与多个产品团队相关。让设计系统团队参与构建仅特定于你的产品的组件不是系统思维。具有一次性案例的组件不应属于组件库或设计系统。

来自中央团队的支持

任何设计系统的核心都是设计和开发 UI 组件的中心团队。一个功能强大的设计系统团队遵循定义明确的流程来设计、构建和记录组件、视觉指南、工程指南和用户体验模式。

例如，在构建系统功能（例如，按钮组件）时，设计系统团队应通过对变量、大小和可组合性等项目进行初始设计发现来收集需求。在最初的发现之后，团队应该与想要使用该组件的开发人员分享他们的发现，以确保它具有发布后需要采用的所有功能。在这一点上，构建组件是容易的部分，但应该有关于设计、代码和可访问性的清晰文档来支持这个新元素。这些是设计系统团队的核心职责。

此外，该团队还负责修复错误、支持设计社区、创建培训材料等。设计系统应该被视为一个产品团队，其客户是内部设计师和前端工程师，专注于构建和扩展系统。

最后，团队负责采用。如果没有被其他团队采用，那么为了构建一个设计系统而构建一个设计系统是一种浪费的努力。有许多方法可以评估设计系统在组织内的影响，例如，设计系统团队可以扫描公司范围的代码库，以确定系统的使用位置和方式，这也有助于了解哪些团队正在使用最新版本的 UI 组件。

评估采用率的另一种方法是要求产品团队每季度自我报告他们的采用进度，这取决于组织的规模，设计系统团队还可以将调查与其他评估方法结合使用。通常有一名产品经理负责与其他利益相关者建立伙伴关系，他们创建开发路线图并将社区需求带回给设计人员和开发人员。

旨在帮助开发人员

设计系统旨在为前端开发人员提供他们的开发工作流程。

如果一个设计系统构建了组件，但无法分发它，它会让许多开发人员感到沮丧。或者，如果包是通过过时的包管理器分发的，这将使开发人员使用设计系统组件具有挑战性。一个好的设计系统会不断发展其分发工具，当今许多设计系统都普遍支持现代包管理器工具，例如 NPM 或 Yarn。

此外，需要对组件进行正确的版本控制，并且需要经常更新发行说明以反映主要和次要版本的更改。许多设计系统通过围绕测试记录他们的过程来获得开发人员对组件稳定性的信心。

此外，开发人员关心样式封装以及代码的编译和转译。一些开发人员关心作用域 CSS 类名。许多设计系统使用 CSS 模块来模块化和组合 CSS，设计系统利用 CSS 模块来启用类名称的自定义范围，并防止不同版本之间的名称冲突，CSS 模块允许 UI 组件与其他版本的库在页面上共存。

设计系统可以帮助解决其他几个工程问题——JavaScript polyfill、对 Vue 或 React 框架的支持、使用 CDN 分发库资产、SCSS 后处理或覆盖、内置可访问性等等。关键是设计系统远远超出了视觉指南，支持工程任务是设计系统工作的一部分。

如果你发现你的团队一遍又一遍地构建相同的组件，那么也许是时候将你的设计系统化了。