Explore, learn, enjoy

本文是我于9月25日在公司内部做的分享。因为听众主要是设计师,因此会有一些关于GitHub使用的小白知识。

随着设计的发展,我们发现我们需要对Design System有个深入思考,而不是简单的把页面罗列在一起。

现在有不少所谓的Design System,但它们更多的是建立颜色、字体、网格、纹理之类的规范。这部分工作当然很重要,但不是设计系统最核心的部分。设计系统关注的是界面如何组成起来以及如何更高效的设计。

原子化设计最初由Brad Frost提出,他的灵感来自化学。物质由分子组成,分子由原子组成,原子由电子和质子中子组成。相似的,界面也可以分解为更小的组件。以下原子化设计的图片就来自他的文章

什么是原子化设计

原子化设计是创建设计系统的方法,按照Brad Frost的分法,包含5个层级:

  1. Atoms 原子层
  2. Molecules 分子层
  3. Origanisms 有机体
  4. Templates 模版
  5. Pages 页面
组件的层级

原子层

原子是最基本不可拆分的“块”,比如按钮、label、输入框。原子可以包含更抽象的属性如颜色、字体、间距等。在一些文章中,原子层下面还有一层Principle就是指这类抽象参数。就像现实中原子通常不会独自出现(就算是金属单质,原子也是分子),原子层的组件一般也需要和其他组件组成更复杂的部分才能更好的使用。

原子层

分子层

分子层由原子层组成,是最小的功能性单位。比如一个表单组件,由输入框和按钮组成,分开来看没什么作用,组合起来就是一个最基本的功能单元。分子层一般只会有一个目的,只完成一个任务。

Alt Text!

有机体

最小功能单元可以组成有机体,能实现更复杂但相关的功能。只看原子层组件没什么意义,但是组成了有机体后,实际的界面开始成形。

Alt Text!

模版

简单讲,模版已经接近最终设计稿,能完成一个更大更复杂的任务。

Alt Text!

页面

往模版中加入更真实的填充效果就构成了页面,这也是最终的设计稿。页面也可以用来测试不同数据的影响:如不同字数对组件显示效果的影响。

Alt Text!

为什么要原子化设计

原子化设计与原来的样式库设计思路不一样,原子化设计从抽象到具象,从元素到组件,让设计师从底层开始思考,对整个设计会有更清晰的理解。同时也能让设计更加统一,在新增组件的时候更谨慎。

如何实践原子化设计

目前还没有设计软件能实现真正的原子化设计(观望Framer X中),因此只能近似的实现。Sketch的Symbol支持嵌套,我们可以利用Sketch来尽可能的实现我们的需求。需要注意的是,目前很多打着Design System旗号的充其量只是个Style Guideline,并不是真正的“system”。

Sketch

Sketch的Symbol是可复用的组件,将一系列图层、文本添加进一个Symbol之后就可以在其他地方重复使用,并且文字部分可以修改。

Library是Symbol的集合。将Library文件添加后,便可以将Library中的Symbol插入到设计稿中。如果Library有变动,所有引用了该Library中组件的设计稿也会同步更新。

这个不是什么新功能。更重要的是我们可以利用这个特性和Symbol多层嵌套来实现一个Design System。

首先我们把Principle层的属性做成一个Sketch文件,并将其添加为Library。这个文件在sense-system中叫Basics.sketch,里面包括颜色、形状、边框、阴影、头像等。

然后用Basics里的元素做成Button.sketch、Input.sketch等原子层组件,并添加到Library。

接着用原子层的Library组成分子层,如Button Group、Form。以此类推。

这样完成后,任何一个symbol的改变,都会同步到所有引用了该symbol的文件中——当然,需要你打开那个文件手动允许修改。举个例子,设计师修改了Basics中的一个主题色;然后打开Button会提示有样式修改,是否同步,点击允许;打开用到这个Button的Form文件,同样提示修改;一层层修改下去,实现所有相同组件同步更新。

但是这就有一个问题,Library只能有一套,如果我想要旧版本的设计怎么办,如果我不希望所有的设计稿都使用最新的样式库怎么办?接下来就是Git出场了。

GitHub

Git是一个版本控制程序,GitHub是程序员交友网站,这两个我们都会用到。我已经在公司帐号里建了一个sense-system的项目,以后说不定会开源。我们将会在这个GitHub项目里同步Sketch Library文件。

为什么用GitHub而不用同步盘?

相信你在使用我们公司网盘的时候已经发现了,当多个人操作同一个文件的时候就会发生冲突,会多出很多冲突导致的备份文件,久而久之这个目录就没法看了,变得乱七八糟。因此我们需要Git进行版本控制和协作,虽然会麻烦一点,但是有必要。

利用 Git 管理文件则可以很好的实现多个版本并行,设计师根据自身需求切换分支。并且可以随时切换到任意时间的任意分支。

首先需要理解 Git 开发的几个概念。

  • Fork 分叉

指从一个分支上复制了一个新分支,你可以自由修改。就像比特现金从比特币分叉出来,分叉前数据一样,分叉后各走各的路。

  • Pull request 合并申请

如果你想让你做的修改加入到原项目,就需要发起一个 Pull request。等待原项目负责人审核。

  • Merge 合并

原项目负责人看到了其他人提交的修改,便可以批准合并,将新代码/文件加入原有的主线。一个标准的 git 工作流完成。

各分支是平等的,每个分支都可以被 fork,也都可以互相 merge。但是在这里,我们只需要使用两个分支,一个 master 主线分支用于实际使用,一个 design 分支用于修改、迭代。

协作流程

Design System 分为两个分支:

  • Master 主线分支为长期稳定版本,用于生成视觉设计稿,给开发提供参考。
  • Design 设计分支用于提交修改,设计团队内部审核使用。

通常工作流如下:

  1. 设计团队将仓库克隆到本地,选择 Design 分支设计组件;
  2. 每一段设计修改通过 commits 提交修改记录。定期将设计 push 到云端;
  3. 经过设计评审后将 Design 分支的修改 Merge 到 Master 分支;
  4. 以后对于新的需求和修改,也是在 Design 分支下操作,再合并到 Master。

对于开发和其他的设计,需要使用最新当前正式版组件,只需将分支保持在 Master 即可。

流程图应该是这样的:

Alt Text!

如果需要出最终视觉设计稿,就需要切换到 Master 分支,使用该分支的 Library 进行设计。对已完成的设计稿进行锁定存档。下一版设计时将 Master 更新,获取最新的文件,再进行设计。

需要注意的是,分支内的组件都是当前版,如果需要设计旧版本的图,可以将分支回滚到以前版本,这样 Library 就是旧版本的样式了。

还有相应的设计规范和使用指南,我会写在GitHub项目的wiki文档里。

总结

经过这些操作,我们就能实现真正的Design System:设计组件化,实现一处修改,处处同步。不同成员做出的设计稿不再是风格各异,也不会同样功能多种实现方式。同时设计规范的沉淀也会更容易。


知识共享许可协议
Atomic Design - 原子化设计体系李大毛 采用 知识共享 署名-相同方式共享 4.0 国际 许可协议进行许可。
基于城中村群租房上的作品创作。