在设计原型时，我的一些所思所想

wz***

　　最近参与一个项目，在前期的讨论与规划中算是一个比较复杂的项目，当我把功能拆分开，定下第一期的要做什么的时候，却发现已经没有什么难度了。不经怀疑这段时间自己到底干了些什么……是不是又打酱油了?于是，在这里简单罗列一下自己在设计原型时候的一些所思所想。本文适读对象：初级产品经理。

　　

　　产品经理属于接力的第一棒，一旦最开始的方向错了，那么即使UI做的有多出色，开发有多顺畅，结果终归是失败的。这大概是产品经理这个职位的第一重压力，在你的设计之后跟随着是UI、开发、测试多个部门，期间消耗的可不是你一个人的人月。

　　所以，在接到一个需求任务时，首先要做的不是打开axure 吭哧吭哧的开始画图。

　　第一：明确需求

　　要搞清楚需求的提出者是谁?服务对象又是谁?

　　搞清楚这两个角色，主要的目前就是搞清楚这个需求到底要怎么做。

　　提出需求的角色会有很多，boss、自己、产品同事、运营、客服……

　　不同的角色往往会从自身的角度去考虑并提出需求。想要完美解决这个需求，就需要站在同一个角度去看问题，若是角度错了，设计方案也就偏了。

　　不同行业的需求满足的对象也是不同的，to b、to c、to vc……

　　若是对内部人员，就需要优先考虑好内部的操作逻辑，提高使用效率，必要时还需要考虑各种权限控制。至于界面样式是否好看，并不是一个重点。

　　若是对外的用户，那么操作流程、交互体验、不同状态下的信息反馈，这些都是需要考虑的。

　　若是金融行业，还需考虑营造安全感、风险控制等等。

　　了解需求的紧迫程度

　　在接手需求时必须要提前了解好时间节点、紧迫程度，毕竟功能开发不是你一个人的事情。要是时间紧迫，而你又把功能设计的超级复杂，害的开发、测试需要长时间的通宵加班，这锅可就得你背着了。

　　举个栗子：运营MM想要蹭热点做活动，给你提了一个活动需求。时间紧迫，热点又不等人，这该怎么办?

　　原型设计、UI出图、前后端开发、联调、测试……一个功能开发需要经过这么多环节，除开前后端开发还可能并行开发外，其他环节基本都是线性进行的，任何一个环节失误都会导致整个项目的延期。

　　所以，在项目前期我们就应该对这些资源的调用、风险的预期，有个大概的认知。倘若加班加点的赶工，最后还是没在这个时间点上完工，这就比较尴尬了。浪费了大家的时间不说，也很打击士气，降低你的影响力。

　　既然时间这么紧迫，风险这么大，干脆不做好了?

　　当然可以，这也算是为开发的兄弟们争取到了喘息的机会。这种情况一般在讨论过程中就推掉了，开发人员可能都感觉不到到你做出的贡献。而你，则成功的在运营眼里打上了“不配合”的标签，再也没有运营MM会来找你聊天啦……

　　那么，究竟该如何做?

　　我想大家平时都会被叫做产品经理、产品，而不会被叫成“画原型的”，就是因为我们不仅仅画原型啊。产品经理不是画原型的，不是需求的传递者，而是需求的解决者，功能设计、原型方案仅仅只是解决需求的一种方式而已。

　　活动本身有没有简化的空间?现有的功能里面有没有可以利用的地方?是不是可以采用第三方去实现?若是需求本身没有问题，那么它就应该有解决的办法。

　　第二：流程设计

　　先把流程理清楚再去设计原型，这一点应该算是一种共识了，也就不在这边赘述了。就来简单说一说流程设计的好处都有啥：

　　1、拆解需求，整理思路

　　接到一个需求之后云里雾里的无从下手怎么办?画脑图、画流程图呗，一般产品岗都会要求掌握visio、脑图这些工具，这些可不是用来凑数的。

　　梳理流程，将复杂需求拆分成子需求，将子需求拆分成功能点。拆分完成，思路也就清晰了，也许连原型的设计方案都已经有大半个腹稿了。

　　2、优化流程，减少不必要的返工

　　我们最开始的想法往往不是最优的解决办法，最优解总是需要经过多次思考、辩证之后才形成。若是什么都没理清楚，就草率画原型的话，等自己想明白了可就得返工重新画了。

　　所以，比起后续重新花费精力去返工画原型，还不如前期多思考、多画画流程。

　　3、直观，容易表述

　　现在也有很多原型图通过连线来表明跳转流程。这种方式在逻辑不复杂的功能上使用还可以，能够直接看的懂。若是功能复杂一点，线条多了，自己都不一定搞得清哪跟哪。

　　流程图可以作为一个大纲，不至于讲着讲着就把话题带偏了，表述的逻辑也相对会清晰些。在需求评审中，先将整体流程讲明白，可以流畅的引出详细的功能说明，也有助于开发人员理解整体项目。

　　就个人的习惯来说，与设计原型相比，前期的准备、流程的设计往往需要花费更多的时间。(PS：也可能是拖延症的错觉)

　　第三：原型文档

　　原型、文档这两部分就不刻意拆开了写了，这两者的边界已经变的有些模糊。目前很多PRD文档都在用axure进行编写，而axure8更是自带了一个便签的控件，用于在原型上添加说明描述。

　　关于原型绘制工具

　　目前我接触的原型主要是通过axure、墨刀去设计的，当然也有使用sketch去画，更有甚者是直接在excel上画的。只要能将一个需求表述清楚，就算是画在白板上也是可以。

　　是否需要高保真原型?

　　曾经有人问我axure里面轮播图的效果怎么实现?

　　说来惭愧，虽然我一直用axure画原型，但是对axure里面的功能却是只学了点皮毛。诸如中继器之类的，甚至连玩都没玩过。于是，先问了一句：“这个制作了是给谁看的?”

　　在我看来，原型的使用对象有两种：boss、开发人员。若是给boss用来宣讲等用途的，无可厚非，原型当然是越精致越好。而我们接触较多的一般都是开发人员，他们更多关心的是如何实现、而不是盯着原型看动态效果……如何快速的制作、如何将功能说明清楚才是其中的关键。

　　所以轮播图怎么实现?做再多动画效果，远不如将这一块注明成轮播图，并写明轮播频率、方向。

　　如何写文档?

　　我一直把产品文档当做是迷你的产品在做。文档的主要目的是将一个需求拆解成实际可开发的东西，它的需求就是能够让开发清楚的知道该做什么。

　　写文档其实没有什么固定的规范，几乎每家公司都会有自己的一套模板，只要能够让开发人员看的明白就是优秀的文档。现在网络上可以找到很多的文档模板，已经提供了丰富的大纲和编写思路，剩下的就是根据公司的实际情况和流程去做些调整。

　　下文为我在编写文档过程中的一些简单归纳：

　　文档中的用词、描述应该统一口径，并使用专业名称。

　　文字描述应该简洁，不要有冗余的对话。

　　一段描述最好只用来说明一个功能点。

　　通过编号等形式，使文档有条理，不容易遗漏一些规则。

　　做好版本管理，及时增加修改记录，保留历史版本。

　　完成文档之后，可以时常接受一些开发人员的反馈，进一步完善编写方法，毕竟这个迷你产品的服务对象就是这些开发人员。

　　你是否已经想明白了?

　　心理学里面有一种叫——墨菲定律，放在这里大概意思就是：自己没有想明白的地方，最后一定会出问题。

　　仅管我们画了原型图，但这也许只是这个功能的冰山一角，判断条件是什么、数据怎么处理、异常状态怎么提示……完整的功能远没页面上显示的那么简单。

　　很大程度上，原型并不是独创出来的，而是多个app样式拼凑出来的。在拼凑页面的同时，就需要考虑对方为什么要这么做?内部有怎样的操作逻辑?把这些想明白了，才能在评审、开发过程中对答如流，真正实现你想要的功能。

　　切记不要说：“参考XXX app就好了”，开发人员不是产品经理，你才是。

　　以上，是一个野生产品经理对于原型的一些不成熟的想法，若有不正确的地方，还望指正。