专栏名称: AleCC
善良的小美工
目录
相关文章推荐
美团技术团队  ·  空降香港!美团无人机率先在港启航 ·  2 天前  
架构师之路  ·  DeepSeek开源V3/R1架构设计思路, ... ·  3 天前  
架构师之路  ·  第6篇10W+,原来不跳舞也可以... ·  4 天前  
架构师之路  ·  一个无价的DeepSeek闭门会,送10张门 ... ·  昨天  
架构师之路  ·  总有人问,出海怎么用DeepSeek满血版( ... ·  4 天前  
51好读  ›  专栏  ›  AleCC

聊聊市面上的「真伪」设计系统

AleCC  · 掘金  ·  · 2018-02-14 02:43

正文

原子设计系统(下均称为设计系统)这个词应该已经流行很久了,像蚂蚁金服最近出的 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™ 的方式实现了一次修改颜色,多端修改的需求。简单来说就是下图所示的样子。

另外还有几个很不错的特性,比如内容自适应、自定义符号等等。

△ 内容根据尺寸自适应

△ 基于「分子」自定义页面内容







请到「今天看啥」查看全文