正文
原子设计系统(下均称为设计系统)这个词应该已经流行很久了,像蚂蚁金服最近出的 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™ 的方式实现了一次修改颜色,多端修改的需求。简单来说就是下图所示的样子。
另外还有几个很不错的特性,比如内容自适应、自定义符号等等。
△ 内容根据尺寸自适应
△ 基于「分子」自定义页面内容