各行各业都有规范，可以说我们每天都是生活在各种条条框框中，那么对我们手上的设计工作来说，如何制定设计规范来帮助我们更高质高效的完成设计工作。
最近在做工作的项目文件整理，其中一部分工作内容就是维护更新之前产出的设计规范。
一、设计规范什么时候做？做到什么程度？
先有产品还是先有规范？
听起来好像有点像先有鸡还是先有蛋，先做产品后总结规范，or先出规范再做产品，or一边出产品一边整理规范，其实每种方法都没有错。
不过在我来看，我比较中意第三种方式，即一边出产品一边出规范。
对于新的产品来说，需要在产品的初期先制定能够主导产品体验大方向性的、主要组件的设计规范，先让小车的轮子转起来，随后在产品的研发和迭代的过程中，不断去完善。
对于大部分常见的设计组件基本上在产品的一个版本的迭代中就可以全部涉及到，所以在产品从0-1的这个阶段是最合适的。
我们先来看看如果不制作交互规范的话，日常的设计工作中会遇到哪些问题：
同一类型的交互方式在不同页面显示的方式不一样
对于明明可以复用的组件，每次出交互方案时都要重新画组件，费时费力
与工作上下游伙伴的沟通效率低
……
那么设计规范做到什么程度才可以呢？
现在大部分的互联网公司都是敏捷研发的模式，所以在产品起步的初期，我们最重要的事情不是制作各种交互组件，最重要的是定义整个产品最基础的交互框架。
网易UEDC设计组对web页面的框架层级做了如下的梳理：即底层、内容层、导航层、全屏操作层、插件层和模态弹窗层（熟悉前端的同学应该知道，前端同学在写页面时会把页面划分的三层：结构层、表示层、行为层，我们制定设计的主要是围绕这三个方向展开，即页面框架、页面样式和交互动作设计）。
当我们制定好这框架之后，设计的工作就会变得更加的清晰，有条理，绝大部分的设计工作都可以依附在在这个设计框架内完成，和前端的同学沟通效率也会更高。
在制定了完善的页面交互框架之后，敏捷开发的团队中，产品的生命周期节奏很快，所以我们在设计工作的前期，只需要根据产品的定位、产品的调性去制定我们的常见的交互规范就可以了。
比如基础文字使用规范、基础控件库（输入框、对话框、搜索、导航等）、产品全局状态（加载、刷新、缺省等），能够满足初期的产品设计就行。
在产品发展突破了从0-1的这个阶段时，产品的交互规范就要随着产品的不断迭代进行更新扩充，各种复杂的、较为少见的交互组件都会慢慢的出现在产品迭代中。
在这时候我们需要对这些组件进行更加规范的分组整理，常见的分组有导航、搜索、通知、按钮、表单、提示信息、信息切换等，比如导航又会分为顶部导航、侧边导航、底部导航等，具体的内容会在下文中详细说明。
交互规范主要分为web端和移动端以及其他配合产品使用的设备端，其中移动端又分为Android和IOS两种，其他设备端如iWatch、车载大屏等，我们在制作对应的交互设计规范时，一定要在响应平台本身的设计规范之上制作。
如果要从零开始设计一套属于自己产品的设计规范，我们不妨看看一些做的非常优秀的案例，比如iview、Ant Design，Element、VUX等，这类产品已经实现了端到端的体验一致，交互组件的的丰富度能够满足绝大部分交互场景。
并且这些组件的交互、视觉、前端都做的非常优秀，这些优秀的案例在我们制作交互规范时确实可以作为有效的参考，包括交互组件的类型、每个组件的交互方式、整体色彩搭配等等，参考这些优秀的设计规范产品，对我们制作交互规范时可以起到事半功倍的效果。
上文提到了交互组件的类型、每个组件的交互方式、色彩文字使用规范等，其实比较抽象，在实际的产品中，这些开发具体要包含哪些内容呢？
首先我们把组件类型分类：页面布局类、导航类、基础组件类、表单组件类、数据展示类、提示组件类。
每一类常见的内容如下：
页面布局：栅格布局、颜色色彩、排版字体等
导航：顶部导航、侧边抽屉导航、顶部导航栏、底部标签栏、分页器、面包屑、步骤条、tab标签、分段控制器
基础组件：按钮、加载、单行文本框、多行文本框、搜索框、下拉框、段落文本等
表单组件类：输入框、单选框、复选框、滑动开关、输入校验规则、文件上传、图片上传、图片查看、日期选择器、级联选择器等
数据展示类：表格、图表、手风琴、走马灯、列表、步骤条、九宫格等
提示组件类：tip、标签、对话框、吐司提示等
业务组件：根据当前产品业务的需要而设计出的一些特殊类型的组件
值得注意的是：我们在制作一套交互设计组件时，可以把它看成一个我们设计的一个产品，它也要有自己的规范，也会有优先级，也会有版本迭代，从零到一；从先满足对基础业务的支撑开始，再逐步进行迭代。
针对交互设计规范文档本身制订一套规范，以满足在不同时间、不同人员维护这个规范文档时都能够保持整个文档的统一性，在我们制作规范文档的过程中是一件磨刀不误砍柴工的事情。
交互规范虽然能够提高工作效率，维护产品的体验一致性，也能够降低团队的沟通成本。
但是仍然需要我们做好以下几点才可以：
文字不要太多，能让项目组成员看图明白的交互方式（多状态、极限情况等）就尽量避免文字的累赘描述
必要的描述信息不能少，对于关键的交互信息最好能够辅以清晰的文字阐述
务必设计好组件多状态的情况（获取焦点前、获取焦点、失去焦点）和在极限等情况下的交互形式
文案表达形清晰一致，好的交互规范不需要太多的文字说明，团队成员直接看图即可明白这个组件的交互方式（点击前、点击后、空数据、有数据、极限情况下等的交互样式），当然有些不好通过图稿表达的信息也必须需要文字说明辅助，但相比文字而言，能用图片传达的信息尽量用图片传达。
交互规范后期有一定的维护成本，需要专门抽出时间进行整理维护，每一次的维护内容都要记录在册。
设计规范在梳理制作的过程中，主要由设计同学来主导，但是必须要与团队的产品同学、前端同学达成共识。对于因为团队内技术、业务等限制产生的特定情况下的交互产物了然于胸。
当然规范的制定一定要结合有效的落地执行才能够发挥真正的作用。在解放设计师劳动力的同时，让我们的设计工作变成真正的以不变应万变。
不过有一点必须要说明一下：实际的设计工作中也不要产生唯规范论的态度，我们真正要做的还是尽量从场景和问题的角度出发，而不是拿规范当挡箭牌。
规范是为了实现业务需求而服务的，如果某种设计方案能够更高效更有质量的解决某个问题，并不带来新的损失，那是不是可以不那么拘泥在当前的规范中。
规范不是我们的王牌，不要因为产品有了设计规范而让自己变成规范的奴隶，丧失了更多好设计和好灵感。
附1：自己整理制作的一套交互组件库
链接：https://pan.baidu.com/s/1PQ9mEaMnJqWAhHvqErwHBg
密码：z8xg
Ant Design：https://ant.design/index-cn
饿了么 Element ：http://element-cn.eleme.io/#/zh-CN
VUX UI：https://vux.li/demos/v2/#/demo
滴滴Cube UI：https://didi.github.io/cube-ui/example/#/
Ant Design Mobile：https://mobile.ant.design/index-cn
