这篇文章分为三个部分：

一般规范包含什么内容

如何通过规范省时省力

如何评估规范的合理性

为什么要写这些内容。首先第一部分让大家大概了解设计规范有什么内容，日后制定规范可以直接套用；了解第一部分就会发现，现在很多设计规范的内容都大差不差，每次一个新项目都有一个新规范，规范以及是一个累赘的负担，没有起到最初的作用：省时省力，当前我们团队也没有完全解决，这里我就先假定某些解决方案仅供参考；第三部分则是花费了大量精力制定的规范如何评估它的合理性，依据有哪些，只有这样，设计的合理性才可站稳脚跟。

一、规范包含什么内容

设计规范一般分为：视觉规范和交互规范。交互规范会更注重整体的层级关系、逻辑、流程方面的定义，对于已确认会用到的常用组件也会有概念定义，由于业务的不确定性，所以交互规范更多的是起到框起某个范围的作用，设计师可以在该范围中进行设计；而视觉规范则会事无巨细的制定字体、颜色、边距等等非常具体的规范，这是一个明确且不可变更的规范，除非有新的组件出现，已有的内容则基本都要按照规范去实现。

交互规范大体上包含：结构、布局、公用组件、业务组件、反馈、公用流程（编辑等）、业务流程（下单等），再从上述几个大类中去细分，就构成了一个规范。

视觉规范在交互规范的基础上增加：颜色、字体、间距的规范即可。

制定规范的初衷也是为了解决一下问题：

团队内部协作

可追溯的更新版本

组件化设计，可复用性强

通过组件化设计，提升可复用性，来提升开发效率

如果是多个业务线并行，统一的规范能够起到统一的作用

二、如何通过规范省时省力

身为懒人，在如何偷懒的道路上深有研究，那么对于设计师而言偷懒偷得名正言顺的规范怎么能放过呢。如何通过制定规范达到省时省力的目的，这里就详细说一说。

制定规范分为以下几个阶段：

项目前期：结构层级，以及某些常用的公用流程和组件方便初始的交互设计搭建

项目中期：对出现的新组件的定义，某个元件是否能被定义为组件取决于该元件出现的频率、普适性以及可扩展性

项目后期：收尾工作，查看新组件和之前的是否有冲突、重合，是否有某些地方可以成为新的组件，并进行迭代更新

如果设计师处于多个项目中，就会出现要维护多套规范的情况。

这里来说说以下的情况：

整个公司围绕一个产品为主，那么规范只存在一套；

公司N个产品并行，类似但不是同一个产品，这些产品还要有定制性，统一的规范不可行，那么有多少个产品就会有多少套规范；

公司多个产品但是这些产品是互补的，那么可以有一定的共同性，那么就会存在一个统一的规范，然后各个产品根据具体业务需求看是否要制定支线规范；

第一种情况很简单，大家共同维护好一套规范，按部就班的迭代就好；第三种情况也简单，由于产品互补，那么整体的交互方式一致即可，相同、类似的操作可以采用统一的规范，至于业务流程部分则可从主规范中演变出来，那么这时候设计目标、原则就起到了指向性作用。而第二种情况则比较复杂，产品不同、产品基调不同，规范不同也是情理中的事，但是如何维护，如何使用就成了问题。

第二种情况很难碰到，但每个公司生存肯定是有一个主线产品，不论外表产品形式如何更改，都无法改变核心业务。那么可以参考第三种情况的方式，针对核心业务整理核心流程并组件化，这样可以适配各种类型的产品，那么剩下的工作就是针对项目做差异化设计了。

上图（Xmind试用模式忽略忽略）是一个完整的交互规范可能有的内容：结构、布局、流程、组件。结构主要是针对整体产品架构、结构层级的定义，这是一个产品的底层逻辑定义，而且设计原则也起到了设计指导的作用，当出现新组件、新流程时，如何制定最终方案还是要依据设计原则进行。

所以省时省力的做法就是：公用组件、流程提炼出来作为统一规范，而结构、布局、业务流程和组件作为差异化的部分，以项目为纬度分别进行维护和迭代。

三、规范制定的合理性

现在的规范系统都比较成熟，有经验的人在项目初期就可以列出一个大概的规范出来，但是规范列出来了，如何评定这个规范的合理性呢？

这个组件在项目中出现的频率是否很高，如果仅出现过一次是否可以考虑作为特案处理

这个组件在项目中其他模块的设计中是否可以复用，复用率如何，如果不可复用那么更换样式是否可以提高组件复用率

如果这个组件实在不可复用，那么通过简单的增删是否可以复用；或者说通过多个组件之间的组合达到目的