把“规范”当作“产品”来设计

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

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

 　　先分析一下现状。

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

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

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

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

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

　　一、分析用户群

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

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

　　二、应用场景

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

　　三、需求分析

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

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

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

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

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