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

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

第三：原型文档

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

关于原型绘制工具

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

是否需要高保真原型？

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

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

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

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

如何写文档？

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

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

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

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

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

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

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

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

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

你是否已经想明白了？

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

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

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

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

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