因为最近系统课程讲到规范 ，所以针对设计规范实际创建的设计误区做一个简单的总结。帮助在职的创建同学改进工作流，也可以帮助新人更好地应对面试中的误区部分问题。
UI 设计规范在原则上是项目必备要素之一 ，创建规范的设计逻辑和方法本身也很简单 。但并不意味着规范的创建创建可以真正发挥作用 ，它会碰到下面几个问题 ：
UI 设计规范做起来容易 ，用起来难，总监明明应该是干货个常规范提升效率的工具 ，却往往变成作茧自缚的设计累赘 。
所以问题到底出在哪里 ？创建
分析其中的问题就必须理解 UI 设计规范本身的作用和价值 ，包含下面这些内容 ：
这些作用都很好理解 ，也很有说服力。但是 ，设计规范是一种自由度很大灵活度很高的文档类型，它的创建必须结合项目的实际情况 ，才能发挥出应有的作用。而很多设计师以为只要把设计规范做好了，就自动可以实现它的作用 ，这是一种错误的想法。
网上有很多设计规范的案例和素材 ，以常规逻辑来理解 ，肯定是做的越完整 、越细致、版式越有设计感的规范看起来越专业 。
这就驱使新人建立一种认知 ，专业的设计规范就应该大而全 ，内容详实 ，格式完整 ，设计精美 。于是在实际项目中，就会把这些要求转化成目标，花大量的时间来创建和制作规范本身 ，而不是以让规范发挥最大作用的方式去制作规范 。
更要命的是 ，很多设计师或设计团队 ，具有"设计洁癖" ，比如图层一定要命名得很清楚 ，所有编组必须使用自动布局，变体所有属性和状态要设置完整等等 。这些要求组合起来 ，就会让整个组件的制作时长大幅度上涨 ，虽然可以靠加班加点解决 ，做完以后看起来也很有成就感。但是 ，真的有认真考虑过这么做的收益 ？
一个文档做得越细致 ，越全面，就意味着越难调整和维护 。在传统平面行业 ，品牌 VI 规范这么处理 ，甚至能做几百页打印成厚厚一本规范手册很合理 ，因为一套 VI 的生命周期三年起步，中间最多针对一些新场景做补充增量 ，但不会大量修改 VI 的基础内容 。
但很不幸 ，我们做的是互联网产品 ，注定了迭代是频发且朝令夕改的 。你花了很大力气整理出来的规范 ，可能下个版本就要调整 ，没几个月就要大改一次。而过于精细的文档是很难维护的，除了内容本身的修改 、格式的调整 、版式的变更 ，还包括和团队成员对齐更新内容等一系列操作 。这就叫船大难掉头 ，所以很多项目规范在做完第一版以后就慢慢荒废了 。
如果有留意大厂规范如 Ant 、Arco 的话 ，往往会发现在开发端已经更新了各种新组件、样式 ，但是设计组件库却没有动静 。原因就是调整维护组件库太麻烦了 ，即使是大厂团队也受不了这种工作量 。
本质上设计规范就是一种设计团队和前端开发的规章制度，当我们越想完善规范内容，就是越往章程里添加了更多的条目 ，我相信谁也不喜欢被这些东西束缚 。但恰恰有很多设计师对制定这些套索乐此不疲 ，并希望团队成员可以兴高采烈地拿起它们把自己给绑了，且要对你的辛苦付出感恩戴德……
所以 UI 设计规范在实际项目的真正矛盾 ，是设计师没有根据实际情况考量，建立了过于理想化的目标 ，从而忽视规范本身的应用属性 ：
为了做规范而做规范 ！
下面 ，就针对规范中的几个常见问题来进行分析 ，分享相关的规范创建思路 。
1. 规范要不要认真设计和导出
规范认真设计固然看着舒服 ，但如果没有足够的时间 ，规范的格式做的很简陋并没有关系 。确保规范的内容所有人都看得懂 ，并且方便查看 、复制 、引用即可，不需要在上面添加美观的排版和一系列说明 。
目前主流的 UI 规范是直接创建在设计软件的画布中 ，文档型的规范能不做就不做 ，因为规范本身是需要直接和操作挂钩的 ，除了复用外 ，还包括查看属性参数。文档则需要直接添加文字说明 ，不仅做起来麻烦 ，而且又臭又长 、碎片化的文档注定没人想看。只有做甲方项目 ，或领导明确要求格式情况下 ，才需要进行导出 。
2. 规范中的组件应该如何处理
UI 设计规范通常也直接涵盖了组件库的元素 ，这样做起来更方便 ，找起来也更合理 。但是组件库的主要问题 ，在于如何合理的结合软件功能，创建方便引用的组件 。如果有下载过大型开源组件库的同学，就应该能看到源文件内一长溜的组件 Page，每次要找到一个自己想要的组件要花不少时间 。并且每个组件 Page 内的画布 ，又放满了密密麻麻的不同状态 ，看了都让人头秃 。
这是为了满足变体的需求 ，可以在变体面板直接操作开关、选项。看着好像很厉害 ，但必须强调，变体的实际使用价值非常低……
因为在常规项目设计环节中 ，组件的多数状态只需要保留示意稿 ，但不会在界面设计中直接引用 。为多数不需要引用的组件状态制作变体 ，除了增加工作量不会得到正面价值。并且越复杂的变体出错的概率就越大 ，维护起来就越困难 。所以不要在组件制作过程中过度迷信变体的作用，只对最常调用的组件状态制作变体 ，否则直接作为普遍分组放在画板里复制也比做变体有效。
同时一定要减少自动布局的使用量 ，因为不同组件实现自动布局的逻辑不同 ，且方法有很多种 ，这就导致你做的组件别人很难更改，或者过一阵子你自己都不知道怎么修改 。这就导致很多时候重新做一个都比修改原来的容易 ，所以设计师都不喜欢用别人的组件做设计 ，就是因为低效 。
3. 规范文件中的版本控制方法
过去我有分享过 ，一个项目内规范文件可以作为一个引用文件 ，被其它设计文件调用 。但互联网产品迭代频繁，而迭代就意味着版本的更新和变化，那么设计规范怎么应对版本的调整？
很多设计团队的做法是使用一个固定 、唯一的设计规范文件，只对设计文件的版本进行归档和管理 。
这在项目前两个版本还好 ，但随着版本增多，产生的问题也会越来越多 。那就是老的项目文件样式也会被替换掉了 ，导致无法在历史版本中查看过去的具体设计。且设计文件的迭代会对界面画布有不同的交叉 ，成为进一步混乱的根源 。
所以建议 ，每次迭代创建一个版本的文件夹 ，而这里面要复制一个独立的版本规范文件，不被其它版本引用 。
4. 设计规范做完以后没人关注怎么办
设计规范不能指望产品 、设计 、开发 、测试认真去看 ，多数设计规范创建的假设就是没人会看 ，就像没人想看产品说明书一样，你要让这个东西足够易懂 ，想要使用或查看一看就会 。要满足这个要求 ，就必须要做好前期的分析 —— 项目需要什么样的规范 ？
要分析出对应的结论，就要对下面几个问题进行思考 ：
不同的项目需要的规范是不同的 ，尤其是不同的规范使用对象对规范的需要是不一样的 ，你需要围绕团队想要的 、会用的规范类型去创建 ，而不是仅仅是追求脑海中 "完美的" 模式 。
所以为了进一步实现这个目标 ，要在规范创建前把规范的结构大纲 、前期小样给团队检查 、评审 ，商议出合适的做法。并且在规范基本做完以后，要开一个简单的培训短会 ，对设计和开发解释规范的所在位置 、内容明细 、查看方法 。总之 ，规范是结合别人的习惯去创建 ，而不是根据自己的习惯让别人适应（你是老板除外） ，才有人愿意配合使用 。
5. 规范里要不要每个细节都添加说明
网上的开源规范说明非常多，所以很多同学问过要不要写说明 ，写的话写哪些东西 ，写到什么程度 。
前面就说过，文档是反人性 ，所以说明自然是能少就得少 。开源框架中添加大量说明 ，是因为这些系统本身就是产品 ，要面向数以万计的用户进行解释 ，所以必须写得很清楚 ，对有实际查看需要的用户进行解释。而我们自己的项目通常只面向少数产品团队的成员，就不需要负担这么重的解释成本 ，写好标题或命名就够了 。只有在不写下说明就很难保证别人能看懂，或者自己过一阵子都会忘记的设计要素上做说明 。
而在我看来一定得做注释说明的地方 ，就是前面提到的组件状态 。虽然我们可以不用变体实现它们 ，但不同的组件状态切换往往包含了具体的交互过程，很多只看图是真看不明白它是怎么切换到另一个状态的 。所以我们最好将这些需要通过交互或特殊逻辑产生的状态进行说明 ，即使用交互文档的展示方法连线和备注 。
一套有效的设计规范必然是经过多方面权衡妥协后的产物 ，检验设计师的项目积累和综合能力 ，一套规范应该怎么做 ，只能靠你自己去判断 ，而没有标准的答案 。最近 UXBAIKE 在写新的规范系列新知识库 ，很快就会上线 。
超人的电话亭
关注微信
.jpg)
.jpg)
.jpg)
