在我过去的设计经验中，搭建和维护设计规范总是非常痛苦的工作。一方面我需要耗费大量精力做组件抽取和标注工作；另一方面还需要将类型不一、拆分粒度不一的组件精心排版，使得每次更新都需要努力克服惰性。

然而！

前几天尝试将用Sketch源文件维护的设计系统转到协作工具Zeplin后，发现懒惰果然是进步的动力~

下面上实践过程。
（本篇不讲理论，先给理论占个坑）

如果是一个全新的项目，可以在确定整体视觉Style以及核心场景页面后，专程再将Sketch源文件整理一遍，把可复用的组件抽出来做成Symbol。再在Symbol层中把元件各种状态梳理+补齐。这样也比较便于在后期业务场景扩展时，快速对设计方案进行呈现和表达，而不是画大量时间绘图。

管理得好，把抽出来的组件再做成Labraries，更可以方便设计协作。

如果是在跟进一些需求迭代，那么我习惯在设计过程中即规范好Sketch源文件，把可复用、多状态的元件做成Symbol。

从这一步来看，我们就已经能发现在源文件中做Symbol习惯的好处。

从Sketch中导出到Zeplin的Symbols，会自动展示在Components中。

Designers可以像在Dashboard一样去把Symbols建立Section；每个Section还可以建立更低一级的Group。这样就非常方便组件管理，而不用在本地去花大量功夫维护设计规范Sketch源文件。

而Developers同样也可以在这里查看组件的CSS样式，以及下载设计资源。这些都是与Dashboard一致的功能。

从Zeplin官方博客更新的博文来看，Components将是它后续迭代和维护的重点。

如果条件限制，无法使用Zeplin，也可以使用蓝湖替代它的自动标注和设计资源共享功能。

搭建设计系统的协作工具，现在看到的还有Mockplus。但尝试了一下，似乎比Zeplin操作更复杂，自动标注也不生效。

但从趋势上看，优化设计流程和提高协作效率是设计工具发展的方向。

设计师从来都不只是“画图的”。在专注于画好图以外，也应当花时间思考如何优化使用工具的方式，工具的发展如何影响我们产出设计的思路。