这次我要谈的是规范而不是产品设计。一直都在说设计需要规范，各大公司团队都有自己的规范，也会不断地更新和制定新的规范，但是执行难，效率低，力度弱却是规范的弊端。Angela提出了“理想设计规范的三条状态”，她指出规范的作用是满足使用者需要、满足协作需要以及提高团队效率，但是通常这些是制定者的理想，却是执行者的痛苦。

 　　规范越复杂，流程就越复杂，执行起来就越困难。为什么会缺乏执行力？反过来想想，是不是我们制定的规范缺乏用户体验，让执行规范的“用户”感觉很难用。所以我提出来，要把规范当作产品来设计。

 　　先分析一下现状。

　　现在的规范不外乎时间上的控制、流程上的把握、人员上的配合以及看上去的可行性。所以规范不是来制定某个设计需要多少注释和说明，而是让使用者能够有更多的时间关注更重要的东西，能够让协作来的更加轻松甚至是能够提高整个团队的效益比。如果你的规范是要求你的产物需要用绿色框来做标注，那么请停止，你的规范只会让使用者叫苦，却不会给团队带来太大的效益比。

　　再从执行方面来讲，规范是制定容易执行难。通常管理者和制定者不是同一个人，所以管理者会忽视制定者的主要意图，最后使规范荒废掉。之前提过的DQA的角色，TA是控制质量和效率的重要角色，TA是规范的执行者。但不是有了DQA我们就高枕无忧了，而且实际上DQA的角色对于很多公司来讲是一种负担，很多公司都把DQA的责任交给了设计总监，毕竟是总负责人，即有权又有能力。也就是说在没有规范的时候，设计总监就是规范！但我觉得把规范应该交给人文环境进行控制，而不是某个人来亲自执行。就像国家的禁塑令，在推出前很多人报以怀疑的态度，但是现在你去超市看看，大部分人都拎着自己的袋子，你还好意思去买塑料袋吗？这就是人文环境的影响。

　　最后现在的规范有一大块是关于文档等的记录。至少我就有很多文档模板，而且在做每件事的时候都会想到在文档里面应该怎么记录。周报日报一大堆，说是记录你所做的事情，但是回头看看，写了也就写了没有什么大的作用，最后久而久之就慢慢荒废了。文档要用的恰当好处，有些实在无法描述的说明还是需要进行相应的沟通，就好比网站的某些功能实在没法使用的时候还是需要客服电话，如果这时硬要用户去发邮件描述并安静等待的话，用户肯定会发疯。规范不是需要刻意记录的文档，大部分文档是在执行规范时的产物，类似于日志一样，只有部分输入输出物必备的文档才是需要去关注的。

　　现在我再次提出，把规范当作产品来做。通过分析使用人群和应用场景，对其进行投入产出比的配置规划，并且合理设计流程上的体验，在规范上线之后有效地制定升级包的计划和远期规划，以此来得到对执行者有更好体验的规范。

　　那么我们来试试看吧！拿我们的团队作为背景来进行规范的设计。

　　一、分析用户群

　　按照横向维度分，使用人群主要有产品设计师、视觉艺术家、内容策划师、前端开发工程师、用户测试员以及团队管理者，外围人群包括产品业务经理、需求分析师、系统分析师、系统开发工程师、项目经理、测试工程师、系统平台发布管理员等等。

　　按照垂直维度分，可分为被动接受（新手）、被动接受并有反馈（熟练）、主动执行（精通）、主动执行并推动产品升级（高级）、全力推行并负责升级（管理）。

　　二、应用场景

　　主要有业务相关项目、自发项目、日常需求三个。

　　三、需求分析

　　工作中每个角色间都有互动的关系，但并非是如下图的垂直传递互动。

 图 1-1 垂直传递互动的关系

　　角色间的关系应该是互补的形式，下图是在业务相关项目下的范例：

  图 1-2 互补型的互动关系

　　图中蓝色文字是互动的内容，蓝圈是UED团队的开发核心，红圈是业务方，黄圈是系统地层，橘圈是测试及产品发布服务。

　　从上图可以看出在完成一个项目，产品设计师是产品的核心，也就是说产品设计师是最终产品的决定者，TA除在完成本职任务以外，还肩负着协调和执行各方角色工作的任务。所以从规范来看，应该从产品设计师入手，并且散发到和每个触角的互动中去。

　　下面简单分析一下团队里面的产品设计师角色需求如下：

　　1、 根据项目（需求）的大小来灵活控制输出物；

　　2、 能够及时了解发展规划方面的行为动向；

　　3、 输入物的格式能够成为设计师的资源而不是阻碍；

　　4、 输出物可以让其他角色一目了然，尽量减少沟通的成本；

　　5、 在申请资源的同时希望能够及时落实并得到资源的反馈；

　　6、 能够清晰明确项目的进展等相关情况；

　　7、 对于产出物可以得到合理的评价体系支撑；

　　8、 对产品的远期有规划和标准执行方案；

　　9、 其他。

　　四、流程设计

　　这一步在传统的产品设计中是主要部分，当然在设计规范时也是最重要的部分，它决定了最后规范如何被执行，也预见了规范在执行时所遇到的问题和解决办法。

　　这里要做的就是把产品设计师的互动流程进行规范。分为三大块，分别是产品业务项目、自发项目、日常需求。

　　1、 产品业务项目：

　　由业务方发起的互动中需要包含一些市场数据和业务分析以及期望值，有明确的产品规划和目标，最后需要有BRD和详细产品描述资料。

　　接着在产品设计师的互动中，需要明确设计资源和时间点，明确产品内容、视觉以及前端的需求，并有能够直接指导开发工程师来完成产品概念的指导文档。最终要得到可用性评估测试的反馈和改进方法，以及产品规划方向的标准制定。

　　2、 自发项目：

　　由产品设计师自主发起的项目，在与业务方互动时，主要是得到一些现有数据，并且得到一些业务支持，在和其他角色合作时与产品业务项目时类似。

　　3、 日常需求

　　由需求方发起的日常需求，互动时需要双方遵守传递统一化的方式，并且在和前端、视觉、内容策划互动时，主要是确定资源和时间点的问题。

　　这里的流程没有细讲，主要是把关系和内容简单的整理了一下，在设计具体规范时还需要细化每个点的流程，特别是遇到问题的解决方法。

　　五、原型设计

　　这一步就是实施规范的撰写，方法有很多，但是我建议先从全局的出发，通过发散思维和流程设计的结果，再慢慢细化每个环节。除了文档以外，规范还需要角色间的培训和认知，并由管理者统一进行意见反馈和收集。

　　六、测试

　　也就是规范的试运行，尽量不要大面积使用，会使执行者产品疲倦感，最好使用AB test进行测试，得到较好的测试用例。

　　七、上线

　　经过一系列的反复测试和修改，最终的规范就发布上线，并由管理者来监督规范的执行情况，但管理员并不是来执行规范的主要角色，执行规范的永远是使用规范的“用户”以及相应的人文环境。

　　通过产品设计的方法出来的规范是符合个性化团队需求的，它也会像很多互联网产品一样成为每个公司团队独特风格的产品。百家争鸣只是第一步，最终的目的是希望能够在众多产品化规范中有一个能够成为整个行业的规范，把难执行的规范从封闭的团队中释放出来，让更多的人参与并得到行业标准解决方案才是产品化规范的最终目的。

　　原文：http://www.jojobox.cn/blog/article.asp?id=139