在 DataCamp，我们的使命是让人人都能获得数据科学教育。目前我们在全球已有超过 200 万名学习者，进展迅速。以这样的速度发展，需要公司里每个人投入大量精力，同时也带来了许多令人兴奋的新挑战。
对设计团队而言，这意味着我们正从逐页设计转向更具可扩展性的设计方式。复用现有组件、缩短开发时间、提升可用性并增强无障碍性，正变得愈发重要。
本文将介绍我们如何开始理清并构建设计系统。
什么是设计系统？
设计系统汇集了分发和复现一种设计解决方案所需的全部组件。它并非新鲜事物，也不只属于数字产品设计——历史上有许多例子可循。
例如，第一位中国皇帝时期，弓箭手无法使用同伴的箭。每支箭都针对特定的弓而设计，其他箭根本不合用。第一位中国皇帝，嬴政，对箭的设计进行了标准化，这对他们的军事征服产生了巨大影响。
在上世纪 50 年代，纽约地铁系统的每个车站都有各自的标识。由于每个车站都有自己的一套导视方式，造成了大量困惑。结果，很多人因不明白系统如何使用而不愿乘坐地铁。Massimo Vignelli 和 Bob Noorda 制定了 NYC Transit Authority——图形标准手册，对标识应如何制作以及应如何在车站中布置进行了规范。多年下来，这套系统基本保持不变，至今仍在积极使用。
为何需要设计系统？
当每个页面被孤立设计时，许多组件会出现重复或相似替代。这会让用户难以理解数字产品，也让工程维护变得困难。在 DataCamp，我们在产品中发现了超过 20 种不同的按钮，每个都有自己的“小毛病”（不同的悬停状态、不一致的禁用状态等）。当产品快速增长时，很难跟踪所有这些组件，几乎不可能维护。这正是设计系统发挥作用的地方。
对于数字产品，设计系统描述了可以用于创建界面、解决问题并为用户带来一致体验的用户界面组件。
当设计系统执行得当时，会带来一系列连锁效应，能够……
- 减少沟通误差
- 缩短实现时间
- 降低维护工作量
- 减少缺陷
- 降低支持工单数量
- 提升质量
- 提高效率
- 延长寿命周期
- 增强可学性
- 提升可用性
- 提升无障碍性
- 促进创新
- 提升专注度
- 提高销售额
这并不容易……
创建、维护并执行设计系统需要所有参与创作过程的人保持高度的自律和持续投入。这不只是设计；工程和产品管理同样是重要的相关方。大家都应该能提出尖锐的问题，比如：“我们为什么要做这个？”、“这个组件能否在别处复用？”、“我们是否已有类似的东西？”、“相比投入的精力，这个自定义组件带来的收益是否足够？”。
DataCamp 的设计系统入门
1. 建立组件清单
目标：确保所有人了解组件的存在与状态。
我加入 DataCamp 时有一个 Sketch 文件，里面包含颜色、图标、字体和一些基础组件。虽然远不完整，但也是不错的起点。前端工程这边也有一套在各项目中使用的组件集合。
我们一起基于生产中使用的组件，在 Airtable 中建立了清单。这让设计团队了解已有内容，避免在不知情的情况下新建组件。也让我们直观看到相似组件的数量，以及问题到底有多严重。
2. 使用命名规范
目标：避免设计与工程之间的沟通误差。
在对比组件时，我们发现设计与工程并未使用同一种语言。比如，设计中定义的“主色”在代码里却是“次色”。这类问题在团队扩张时会导致误解，进而引发混乱和挫败。于是我们确保不同团队之间采用相同的术语体系。
3. 优化设计流程
目标：避免丢失工作成果，并确保流程透明。
作为一个设计团队协作，会带来自身的一系列挑战。我们曾把设计稿存放在 Dropbox，但随着团队扩张，丢失工作的风险和跟踪变更的成本急剧上升。
我们的设计团队对流程变更非常开放，于是开始使用 Abstract。它让我们能够正确地进行版本管理、拥有透明的工作流程，并在设计时更有信心。
4. 更好的文档与入职培训
目标：加快员工入职，并减少沟通开销。
我们开始使用 Slite 记录流程与设计系统。凡是需要重复解释的内容，都应文档化并分享给团队。这能大幅减少沟通开销，并防止信息丢失。
5. 设计评审
目标：在设计与工程之间明确预期。
设计评审必须是双向的。设计师应该能审阅前端实现，前端也应该能审阅设计。设计师常常倾向于创造新颖酷炫的东西；工程师则应能提出尖锐问题，比如：“为什么要做自定义？”、“这个组件不能复用吗？”、“我们能把这个组件做得更好吗？”、“这个组件是否值得额外的开发投入？”。关键在于向所有参与者论证决策并明确预期。
结语
我们刚开始着手构建设计系统，仍在努力理清产品中发现的各类重复组件。前路仍长，但随着我们不断打磨每一个组件，正在为客户打造一个更佳、更一致、更易上手的产品。
我们也好奇其他组织如何理解并运用设计系统。若您愿意分享经验，请给我发邮件。
在 DataCamp，我们一直在寻找优秀人才加入我们的团队。有兴趣吗？查看开放职位。
在 DataCamp，我们的使命是让人人都能获得数据科学教育。目前我们在全球已有超过 200 万名学习者，进展迅速。以这样的速度发展，需要公司里每个人投入大量精力，同时也带来了许多令人兴奋的新挑战。
对设计团队而言，这意味着我们正从逐页设计转向更具可扩展性的设计方式。复用现有组件、缩短开发时间、提升可用性并增强无障碍性，正变得愈发重要。
本文将介绍我们如何开始理清并构建设计系统。
什么是设计系统？
设计系统汇集了分发和复现一种设计解决方案所需的全部组件。它并非新鲜事物，也不只属于数字产品设计——历史上有许多例子可循。
例如，第一位中国皇帝时期，弓箭手无法使用同伴的箭。每支箭都针对特定的弓而设计，其他箭根本不合用。第一位中国皇帝，嬴政，对箭的设计进行了标准化，这对他们的军事征服产生了巨大影响。
在上世纪 50 年代，纽约地铁系统的每个车站都有各自的标识。由于每个车站都有自己的一套导视方式，造成了大量困惑。结果，很多人因不明白系统如何使用而不愿乘坐地铁。Massimo Vignelli 和 Bob Noorda 制定了 NYC Transit Authority——图形标准手册，对标识应如何制作以及应如何在车站中布置进行了规范。多年下来，这套系统基本保持不变，至今仍在积极使用。
为何需要设计系统？
当每个页面被孤立设计时，许多组件会出现重复或相似替代。这会让用户难以理解数字产品，也让工程维护变得困难。在 DataCamp，我们在产品中发现了超过 20 种不同的按钮，每个都有自己的“小毛病”（不同的悬停状态、不一致的禁用状态等）。当产品快速增长时，很难跟踪所有这些组件，几乎不可能维护。这正是设计系统发挥作用的地方。
对于数字产品，设计系统描述了可以用于创建界面、解决问题并为用户带来一致体验的用户界面组件。
当设计系统执行得当时，会带来一系列连锁效应，能够……
这并不容易……
创建、维护并执行设计系统需要所有参与创作过程的人保持高度的自律和持续投入。这不只是设计；工程和产品管理同样是重要的相关方。大家都应该能提出尖锐的问题，比如：“我们为什么要做这个？”、“这个组件能否在别处复用？”、“我们是否已有类似的东西？”、“相比投入的精力，这个自定义组件带来的收益是否足够？”。
DataCamp 的设计系统入门
1. 建立组件清单
目标：确保所有人了解组件的存在与状态。
我加入 DataCamp 时有一个 Sketch 文件，里面包含颜色、图标、字体和一些基础组件。虽然远不完整，但也是不错的起点。前端工程这边也有一套在各项目中使用的组件集合。
我们一起基于生产中使用的组件，在 Airtable 中建立了清单。这让设计团队了解已有内容，避免在不知情的情况下新建组件。也让我们直观看到相似组件的数量，以及问题到底有多严重。
2. 使用命名规范
目标：避免设计与工程之间的沟通误差。
在对比组件时，我们发现设计与工程并未使用同一种语言。比如，设计中定义的“主色”在代码里却是“次色”。这类问题在团队扩张时会导致误解，进而引发混乱和挫败。于是我们确保不同团队之间采用相同的术语体系。
3. 优化设计流程
目标：避免丢失工作成果，并确保流程透明。
作为一个设计团队协作，会带来自身的一系列挑战。我们曾把设计稿存放在 Dropbox，但随着团队扩张，丢失工作的风险和跟踪变更的成本急剧上升。
我们的设计团队对流程变更非常开放，于是开始使用 Abstract。它让我们能够正确地进行版本管理、拥有透明的工作流程，并在设计时更有信心。
4. 更好的文档与入职培训
目标：加快员工入职，并减少沟通开销。
我们开始使用 Slite 记录流程与设计系统。凡是需要重复解释的内容，都应文档化并分享给团队。这能大幅减少沟通开销，并防止信息丢失。
5. 设计评审
目标：在设计与工程之间明确预期。
设计评审必须是双向的。设计师应该能审阅前端实现，前端也应该能审阅设计。设计师常常倾向于创造新颖酷炫的东西；工程师则应能提出尖锐问题，比如：“为什么要做自定义？”、“这个组件不能复用吗？”、“我们能把这个组件做得更好吗？”、“这个组件是否值得额外的开发投入？”。关键在于向所有参与者论证决策并明确预期。
结语
我们刚开始着手构建设计系统，仍在努力理清产品中发现的各类重复组件。前路仍长，但随着我们不断打磨每一个组件，正在为客户打造一个更佳、更一致、更易上手的产品。
我们也好奇其他组织如何理解并运用设计系统。若您愿意分享经验，请给我发邮件。
在 DataCamp，我们一直在寻找优秀人才加入我们的团队。有兴趣吗？查看开放职位。