产品需求文档写作方法（二）原型设计+撰写设计

三、原型设计(手绘原型,灰模原型,交互原型)

3.1 原型设计

    上一篇文章我们通过思维导图将想法进行了结构化梳理，接下来我们就需要进行方案的可行性推演，验证产品功能是否可行，预估项目要花多少人力物力，因此我们就要通过原型设计进行相关需求的论证。一开始就撰写PRD文档，我们很难对产品进行各方面的评估，也无法得知方案的可行性，并且无法直观细致的考虑产品。

    原型设计是帮助我们更细致的思考，并做各项需求的评估，同时也是将自己脑海里的想法进行输出，通过原型设计后，我们就可以进行产品宣讲了。相对于之前抽象的文字描述，原型则更加清晰产品的需求，设计和技术人员或者老板也能够更加直观的了解到产品意图。

    原型设计是将结构化的需求进行框架化，因此原型也被称为线框图，具体的表现手法有很多种，相关的辅助软件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。

    当到了原型设计这一步时，已经不仅仅是构思了，我们需要更加深入的了解每个页面上的元素和这些元素的属性。例如按钮元素，我们就需要考虑这个按钮的功能，并且这个功能操作后带给后端和前端的反馈。举例这个按钮是注册会员按钮，用户操作后，第一步逻辑是验证用户输入的信息是否合法，不合法则给出前端反馈；合法则和后端通信验证是否已经存在同样信息，已经存在则给出前端反馈，不存在则进入下一步，注册成功；注册成功后的反馈是跳转页面，还是弹出层提示用户完善资料，这些都是需要更详情的考虑的。当然这些更细致的思考是留在需求文档撰写时的，而此时我们需要做的就是把这些元素通过原型表现出来。

    原型设计的表现手法主要有三种：手绘原型、灰模原型、交互原型

1、手绘原型

因为原型也被称为线框图，因此手绘是最简单直接的方法，也是最快速的表现产品轮廓的手法(如下图)。

手绘原型在初期验证想法时非常高效，也方便讨论和重构，同时也适合敏捷开发时快速出原型。

2、灰模原型

灰模原型是由图形设计软件制作而成，我最常用的软件是PhotoShop和FireWorks，相对手绘原型，灰模更加清晰和整洁，也适用于宣讲，但是需要产品人员熟悉使用图形设计软件(如下图)。

灰模原型常用于移动互联网产品的设计，由于移动产品的交互需求复杂，原型设计软件难以高效的表达需求，因此移动互联网产品的设计通常是灰模原型加交互文档组合成PRD文档。（过几天我再详情讲讲移动互联网的产品设计）

3、交互原型

交互原型是使用原型设计软件完成的原型，常用软件是Axure RP，通常情况交互原型的设计仅早于PRD文档，是产品经理想法推演的最后一步。通过Axure PR之类的交互原型软件制作出来的产品原型，在功能需求与交互需求的表现和正式产品几乎是一致的，所以有时交互原型也被称为产品Demo版。

通常情况下交互原型是产品经理与交互设计师共同讨论确定，然后由交互设计师制作，但是绝大多数的公司是没有交互设计师这个职位的，因此这类工作最终是由产品经理来负责的。（很多公司给视觉设计师的职称是交互设计师，但本质还是视觉设计）

关于Axure PR制作交互原型我在这里就不多介绍了，网络上有很多这类的教程，我个人建议是学习Axure PR时，随便了解一下网站模板的结构，这样可以帮助你更加结构化使用Axure PR。（推荐一个我之前画的原型，网站已经关了，原型当时设计的也比较简陋，有很多缺失的页面，仅供参考看看。）

分享微世界原型Demo(源文件)：http://tangjie.me/blog/11.html

以上三种方法并不是渐进的流程，而是三种原型设计的方法，具体取决于你的产品需求和团队要求。

产品经理设计原型是为了帮助自己更细致的思考方案的可行性，也是为了给别人讲解的时候，让听众能够清晰直观的了解产品，同时也是为了确保产品在执行 过程中，是按产品经理最初设想的需求和期望完成的。因此产品经理的原型是没有很高的要求的，只要对方能够听懂看懂，使用手绘原型是最高效率的方法。

四、撰写文档(PRD文档)

    PRD文档没有标准的规范，也没有统一的模板，每个公司都不一样，并且每个人也不一样，这个取决于个人习惯和团队要求。虽然PRD文档没有标准的规范，但是有两项是必不可少的，那就是文件标识和修改记录。文档在撰写过程中，我们可以自行不断的修改完善，但是如果正式发布或交给团队其他成员后，一旦有了修改，为了文档的同步，我们就需要标注出文档的修改内容，备注修改记录。关于文件标识和修改记录，大家的格式都大同小异(如下图)。

    PRD文档的形式常见的有以下三种：Word、图片、交互原型

一.Word

    这是传统意义上的PRD文档，主要有四个部分组成(具体视你的产品要求进行划分)，分别是：结构图、全局说明、频道功能、效果图。

    PRD文档目的性很明确，就是要描述产品的功能需求，所以PRD文档时没有市场方面的描述的。而且我们要减少不必要的文字说明，因为很少有人去认真阅读word文档的说明的。

1、结构图：
1.1、信息结构图：主要是辅助服务端技术人员创建或调整数据结构的参考文件
1.2、产品结构图：主要是辅助设计和技术开发人员了解产品的全局结构，他和用户流程图不一样，产品结构图只是罗列出产品的频道和页面。

2、全局说明：主要讲解产品的全局性功能的说明，例如网站产品的页面编码、用户角色，移动产品的缓存机制、下载机制，这类全局性功能的说明。这里我举一个移动产品的“状态维持与恢复”的例子，示例如下。

状态的维持与恢复
当用户退出产品时（误操作、Home键、锁屏、自动关机），产品需要维持用户操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。
维持状态包括流程操作、信息浏览、文本输入、文件下载。
锁屏状态时，如果用户在产品中有下载任务时，仍然保持下载。

产品需求文档 示例：

  

3、频道功能：以频道为单位，页面为子项，分别描述产品的频道、页面及页面模块元素的功能需求(格式如下)。

示例格式
1、频道名：频道介绍及需求说明
2、页面1：页面介绍及需求说明
2.1、页面模块1：模块功能需求说明
2.1.1、页面模块1-元素1：功能说明
2.1.2、页面模块1-元素2：功能说明
2.2、页面模块2：模块功能需求说明

在撰写功能需求时，我们需要考虑用户的流程，例如一个“完成”按钮，我们需要描述他完成后，系统要不要给出反馈提示(反馈提示是什么样的形式反馈，内容显示成什么，有没有内容需要调取数据库)，或者要不要跳转页面(跳转到哪个页面，这个页面是其他频道页面，还是这个功能的子页面，如果是子页面就需要再描述这个子页面的模块及元素内容)。

4、效果图：效果图是由设计师完成的产品图，和实际开发完成的产品保真度一致。

二、图片

图片形式的PRD文档是基于效果图的说明文件，将传统Word形式的功能需求说明标注在效果图上，这种方式经常使用在移动互联网领域，实际上是图文形式的交互需求文件，只是在此基础上更深入的描述出功能需求。

对于图片形式的PRD文档，我们只需要另外再描述一下全局说明，其他频道页面的需求直接以图片形式展示，这种方式相对于Word文档的纯文字更加生动易读并且直观，因此有一些产品经理非常喜欢用这种方式代替Word形式的PRD文档。

三、交互原型

这里指的交互原型就是上一篇文章讲的原型设计，使用Axure PR之类的交互原型设计软件制作出来的产品原型非常真实和直观，并且原型软件还支持元素标注和导出Word文档，因此很多产品经理都喜欢使用Axure PR来代替Word完成PRD文档。

当我们通过Axure PR制作出产品原型后，实际上他已经是很完善的产品Demo了，因此我们只需要加上元素的标注，在标注中说明功能需求，这样导出的HTML文件相比Word文档更直观易懂，是非常高效的产品需求说明方式。

 

来自为知笔记(Wiz)