这次我要谈的是规范而不是产品设计。一直都在说设计需要规范，各大公司团队都有自己的规范，也会不断地更新和制定新的规范，但是执行难，效率低，力度弱却是规范的弊端。🌞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进行测试，得到较好的测试用例。

　　七、上线

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

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

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