一、为什么要写设计规范？设计规范是为谁服务的？

谈这个话题之前，我们先了解一下什么是设计规范？设计规范是指对设计的具体技术要求,是设计工作的规则. 一般包括总体目标的技术描述、功能的技术描述、技术指标的技术描述,以及限制条件的技术描述等．

那我们为什么要用设计规范？第一，可以让我们清楚项目的规则，以减少犯错误的机率；第二，加强团队之间的合作，责任明确，提高工作效率．第三，锻炼我们整体全面的思维能力．

规范最终是为项目服务的．我们所做的一切都是为了优化项目，提高我们的工作效率．但是，设计规范也是一种设计团队文化．最终受益的不止是项目，还有我们自己．当我们形成这种文化，我们会配合的更默契；我们不需要在工程师加班的时候，一定留守在那里陪着；我们不需要在调别人设计的源文件时，一遍一遍的询问．当你不再因为别人的事情而加班的时候，心情是否好一些呢？

设计规范渗透在整个软件工程里．不同的工程模型对规范的要求也不一样，并非详细全面的设计规范就是最好的，因为规范是要有生存环境的，小公司的快速开发适合变通，大公司的瀑布模型适合严谨．如果不考虑自己本身的工程模型，而一味的追求全面，详细，其结果不但不能真正帮我们提高工作效率，反而会因为过多的其它作业而延误项目周期．

规范要有概括性和引导性，不应该扼杀设计师的创造力．我曾经见过一份图标的设计规范：必须要45度角侧视角度．我觉得很好笑，完全没有必要这样限制嘛．我们可以这样规范：要有统一的视角，统一的倒角，颜色数量不要超过三种，统一的材质等等，这样即可以统一图标的风格，又可以引导设计师．

二、设计规范分哪些种类？都有哪里内容？

1.　产品级战略方向规范．

最稳定的设计规范，适应于长时间不变更的内容．大至可以分成二大部份：

第一部分：整个公司产品的设计方向．比如：是使用公司中VI定义作为我们的主产品色，还是在某种限制上随意发挥？整体风格以硬朗的表达方式还是圆润一些？怎么打造和延续一个品牌的气质，以增强用户的归属感等等．

第二部份： 达成共识的，恒定不变的内容．比如基本控件的设计规范，基本交互的规范，文档书写的规范等等．

2.　项目中单个设计规范（交互规范，视觉规范）．

是项目中最为详细的规格说明书，整个项目都是按照这些设计规范完成的，也是最后测试评审的依据．该规范被细分为Ｎ多份不同的方向．比如：流程说明；交互模型；交互规范；图标设计规范；界面设计规范；界面实现规范；控件设计规范等等．这些内容应根据每个公司软件工程的模型不同而有所变化．比如：瀑布模型软件工程的侧重点可以细致而全面，但这些只适用于大公司，能承受较长的项目周期的公司；而使用极限编程的侧重点在流程说明，交互模型和项目需求变更上；还有一些不使用软件工程的小公司，在定义的时候，侧重点则在界面的设计规范和实现规范上．大家在定义的时候还是要根据自己公司的实际情况出发，真正做到优化自己的工作即可，这一点会在＂如何定制设计规范＂中详细说明．

3.　接口的输出规范．

这里是指我们输出至工程师的文件规范．我们需要输出什么样的内容才可以帮助我们减少和工程师的沟通摩擦，我们的工作范围在哪里？记得自己刚来现在这家公司的时候，有一个很不错的设计师抱怨说，这个坐标我已经告诉过他十几次啦，每次他都说自己忙，没空改，现在老大说我们设计的界面有问题，我们设计师做事不认真，其实这个责任根本不在我．我想了一下，这确实不是他单个人的问题，是我们的输出接口没有规范，没有细化，从而造成范围不清楚，责任不明确．如何避免呢？我们需要去定义输出规范，定义我们需要提供什么样的实质的内容给工程师，比如坐标图，效果图等．在这个过程中，在提高工程师工作效率的同时，大量的减少这种摩擦的发生．

接口的输出规范大至可以分为以下几个方面：需要提供的元素定义，比如：切图，坐标图，效果图，流程图，架构图，文档等；切图的规范，比如：图片格式，图片共用部分的划分，切图的位置，多种状态等；文件命名的规范；文件夹的存放分类规范；文档书写的规范；等等．

4.　设计文档的管理规范．

当多个设计师相互配合完成一个项目的时候，设计文档的管理规范就显的尤其重要．我们来想象几个场景：场景一，你需要调用一个同事设计好的界面里的子模块，打开PS的源文件一看：哇，几百个图层，无文件夹管理，无命名．场景二，同事请假了，临时要用一个他设计好的界面，打开他的电脑，找了一个小时没有找到，火大呀，感觉自己重新画都画好了．场景三，老大跑过来找你要某个文件，就站在你身后，你找来找去就是找不到，那个急呀．我想这三个场景应该是大部份设计师都经历过的，还记得当时的心情吗?

设计文档的管理规范挺重要的，它不论是团队合作还是个人，都能很有效的提高工作效率．一般包含以下几点内容：文件的存放，比如：工作文件目录的分类，本机的存储模式，服务器的存储模式，资源文件的存储等；文件的命名，比如：切图的命名格式，源文件的命名格式，需要输出的架构图的格式，多版本的命名格式等；源文件的管理，比如：图层的命名，分件夹的分类，源图的处理等；文件的变更管理(版本管理)等．

三、如何定制设计规范？

定制规范不是某一个设计师的职责．现有的中小企业老板在受到外界影响下，总是这样下达一个命令：某某设计师，请把我们公司的设计规范写一下，什么内容，什么方向一概不讲，我个人认为这种方式是完全错误的．规范的定制并非只是上行，更要下行．取得上司支持的同时，更要得到同级和下属的接纳，这份规范才有意义，才有执行的力度．在戴维迈尔斯的社会心理学里讲过：态度依从行为．全民参于有利于提高全部设计师的积极性，加强承诺后的执行力才会更高一些．

中国一直在讲中庸之道，什么是中庸？就是要取平衡点．物极必反，过量的行为并不是达到目的好方式．记得周陟说过一句话：小细节改变大流程．我灰常的赞同这句话，任何公司的改制都不应该全盘否定而重新定制，就像一艘大船想要转弯也要走一个抛物线，如果一定要急转弯，那就要有能力去承受翻船的可能性．没有最好的规范和流程，只有最合适的．别人的东西看着再好，那未必适合自己．微软的规范好吗？腾迅的流程好吗？如果你只是一个五人以下的设计团队，那就坚决不要采用他们的流程，否则繁杂的工序只会延误项目周期从而拖死这家公司．

以上讲这么多，无非是告诫大家不要盲目的去抄袭别人的规范和流程．在明确了自己当前公司的设计规模和流程体系之后，根据实际情况定制出有助于项目和设计团队合作的规范，这才是最有意义的．那么，我们要该如何定制规范？在这里，我把自己的经验和大家分享一下，做个参考：

1.由上到下．从流程上来讲，我们必须要先取得上司的支持，再和同级或下属共同定制．我们有很多规范需要设计师和工程师共同完成的．举个例子，切图文件的命名规范，如果只是设计师按照规范命名，而工程师做不到的话，那最终工程的切图资源一定还是乱做一团，很难定位想要的图片，结果这份规范就失去了意义．取得上司的支持很重要，他是规范执行力度的一个保障．

得到上司的支持以后，我们开始列出大致的方向和范围，开始和同级或者下属进行讨论．毫无目标的讨论是没有意义的，所以一定要有范围，比如，今天我们只讨论输出的规范．我们需要交付给工程师的都有什么？切图，坐标图，效果图，架构图，还需要有什么呢？我们的切图目录该如何存放？等等，大家畅所欲言，在会议时就要定下大家的建意和想法，总结整理，最后大家签名．给上司过目之后签名，这就是一份生效的规范了．

2.由团队到个人．先定制团队合作的规范，再定制个人操作上的规范．

团队合作的规范很重要，规范定制的好，很容易提高工作效率．比如说源文件的管理规范，在多个设计师相互配合一个项目的时候，如果每个人设计师都有自己的风格和管理方式，那将会是一种灾难．每个人在相互调用文件时，都要找对方询问Ｎ遍，次数多了，双方都不会有好心情做事，您是否经历过这样的场景而深有同感呢？个人操作规范相比团队的要轻一点，自己管理的混乱影响的是个人的效率，做不完自己加班，但不会影响到整个团队．但是，如果团队沟通不好，那就一起加班吧．所以，团队合作上的规范一定要先做好，再去规范个人的操作．

3.由大入小．先定制大的设计方向，再定制项目中单个详细的说明．

我们在设计产品的时候，一定要有设计方向，有一个统一的产品设计规范．像苹果的产品，迅雷的产品，腾迅的产品一样，不论他们出了什么样的新产品或者新软件，大家都能感觉到这就是他们公司出的，这就是我说的大的设计方向．现在是品牌的年代，我们必须要有这样的一份规范来建立我们的品牌气质．但是，这份规范不可能定义某个界面应该使用什么样的文字或者使用多大的字号这种细小的问题，这明显不适用于所有项目．那么我们就需要针对每一个项目都要写一份规范，来定义这些细小的问题．单个详细的规范是从属于大的设计方向的，是大的设计方向上的一个分支．大的设计方向一般短期不会改变，单个详细的规范说明，我们可以专门定义一个模板，在每次项目开启时填上即可． 所以，我们需要先定义大的方向，再定制项目中单个详细的说明．

4.由交互到视觉．先定制交互规范，再定制视觉规范．我想这个不用我多说啦，大家都明白的．交互永远都是走在视觉的前端，视觉是在交互的基础上做产品效果．如果交互没定义就开始定义视觉，我想多半也是废纸一张啦．