原子设计系统（下均称为设计系统）这个词应该已经流行很久了，像蚂蚁金服最近出的 Ant Design 3.0 也说是基于「设计系统」进行构建的。如果你没有了解过原子设计系统，那么我建议先去对原子设计系统做一个初步的了解。因为这篇文章并不是原子设计系统的科普文。
虽然设计系统这个概念出现了很久，但是从设计师的角度来看，业界仍然存在大量的「伪」设计系统。为什么这么说？
设计系统是从 Style Guide 之上发展出来的一个设计方法论。所以设计系统其实并不是解决了「设计风格」这个问题，而是在尝试解决 Style Guide 在实践中存在的诸多问题。
先来看看我们传统运用 Style Guide 中存在的问题。
当明确一个设计需求后，我们根据 Style Guide 进行规范化的设计，输出对应的一系列组件。如果 Style Guide 中没有明确定义的时候，可能就会自己创建一些样式，最后交付开发，可能等到产品完全上线后，才会根据之前的设计结果修订 Style Guide 或者组件库。
整个实践模式如下图所示：
这种流程存在诸多问题，比如组件库和 Style Guide 的更新往往因为项目迭代速度快而滞后；新创建的组件与之前的 Style Guide 存在冲突；更新组件库和 Style Guide 又要花费不少时间……
当然我这边说的基本都是中小型公司，像 BAT 这样的大公司不能包含在内——一旦人多了之后，任何设计上的问题就都只变成管理的问题了。
而正是因为这种实践模式存在诸多问题，效率上有待提升， Brad Frost 才会提出设计系统这个概念。值得一提的是，Brad Frost 在 2013 年提出设计系统这个概念的时候， 他的团队只有 4 个人。我想也正是因为团队小，才更加需要效率的提升吧。
设计系统提出的一个实践模式是先设计系统，而后根据设计系统来完成业务与组件库。如下图所示：
这个好处不言自明，组件库与业务线可以同步更新，一次修改，便可以多端响应。完美解决 Style Guide 模式中存在的种种问题。
但是问题又来了，怎么样才可以实现这种实践模式呢？用程序员的话说，设计系统应该抽取哪些内容，然后再分别让业务与 Style Guide 继承呢？
答案就是：模块化，组件化，原子化 。这也是为什么设计系统被称为原子设计的原因。
基于前面提到的，设计系统中必须做到的一点是：当你改动任何一个原子，你有自信其他所有依赖于这个原子的部件全部自动更新。只有满足了这一点，设计系统设想中的效率、解放生产力才会真正实现。
我个人猜测，Brad Frost 应该受到过 React 的启发，因为 React 作为前端模块化开发的鼻祖，其开源时间为 2013年5月，与文章中提到的 2013 年吻合，同时 Brad Frost 是前端开发者，想必很了解React。
设计系统的落地关键
理论的部分讲完了，接下来是落地的关键。也只有到了这个地方，才能够鉴别各种所谓的「设计系统」到底是不是真的设计系统。
还记得我们之前怎么说的吗？修改设计系统中的任何一个原子，整个系统都应该能够被响应到。
那么在 Sketch 中有什么方式可以达到这样的效果？对，分享样式与嵌套符号。
只有合理利用了这两个功能，才能真正达到设计系统的效果。如果在 Sketch 中没有实现样式共享，仍然只是 Style Guide，算不上一个真正的设计系统。没法全局响应就意味着没法执行「先设计系统，后业务与组件库」的流程。
让我们来看下现在风头正盛的 Ant Design 组件库。
可以看到，随便选取的一个颜色并没有任何共享样式，这就意味着如果我去修改这些颜色，组件的样式并不会跟着改变。
在查看完组件中的颜色、字体均没有对应的共享样式后，基本可以断定 Ant Design 的 Sketch 文件并没有构成真正意义上的设计系统。
凭我的主观判断，这么做的原因可能有两个：
- Ant Design 团队内部有一套设计系统更新的工具，可以快速对 Sketch 已存在的原子进行更新，但是并不会以共享样式的方式保存。而因为种种原因，这个工具没有对外发布。
- Sketch 文件发布之初就没有想过原子层面的颜色、字体等还会被替换，因此没有去设置共享样式。我个人认为这种可能性会更大一些。
但是不管我如何去揣测，一个无法全局更新的 Sketch 文件，哪怕具有再多的组件，对于设计师来说，直接使用价值也是非常有限的。 因为设计师没法把这么多组件直接、快速地复用到自己的业务场景中，那么这些所谓的「设计系统」往往就变成了单纯的「参考图」，缺少工程使用价值。
实际上， Ant Design 对于开发者来说价值巨大，我个人在做开发的时候用起来也非常爽。但是对于设计师来说，真正的工程价值可能就只有「设置行间距的时候总是多个 16px 就好」之类的经验了。
而且知乎上对 Ant Design 予以好评的绝大部分都是开发者，而不是设计师。所以可见一斑。
「伪」设计系统
那除了 Ant Design 之外，还有哪些「伪」设计系统呢？我从全网找到了大概了10来份设计系统的 Sketch 文档，一一做了检查与测试。
1. IBM 的 Carbon Design
2. Shopify 的 Polaris
3. Salesforce 的 Lightning Design System
它只定义了一个主色，其他颜色和字体等等都没有共享样式。
4. Atlassian Design Language
他们没有以 Design System 自称，但是这里我也放上来了。
Sketch 文件中一样没有定义颜色的共享样式。不过难得的是它做了字体和阴影样式的定义。
以上都是大公司的 Sketch 文档。可以看到，基本上放出来的设计系统都是「伪」设计系统，对原子做过良好定义的很少。我想究其原因还是因为不会考虑到供其他设计师「复用」这些资源供自己的项目使用吧。我更愿意把它们当成是披着「设计系统的皮」的 Style Guide。
更多的设计系统可以从StyleGuide.io 这个网站上找，我不过是挑选了其中知名的一些来测试。
「真」设计系统
我相信接下来的内容大家可能会更加关心，真正称得上设计系统的有哪些呢？ 因为只有这些设计系统才能帮助提升我们日常工作的效率，让生活变得更加愉悦。
1. UXPT
UXPT 全称 UXPower Tools，应该是市面上真正的设计系统中最完整的一家了，同时有 Web 、移动端的设计系统，均可响应原子操作。
我在前文提到的原子级的颜色、字体、阴影样式等等这些都可以自定义，而且一次修改，所有组件能够同步修改。
拿修改颜色举个例子：
可以看到当我修改样式并进行同步后，所有组件的样式都进行了修改。
UXPT 利用 Style Stacks? 的方式实现了一次修改颜色，多端修改的需求。简单来说就是下图所示的样子。
另外还有几个很不错的特性，比如内容自适应、自定义符号等等。