2.6、需求文档（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.渲染：

效果图是设计师完成的产品图纸，与实际开发产品的逼真度一致。

这个例子是一个移动产品(iPad)需求文档，其中部分隐私内容已经过滤隐藏，只保留了首页和地图搜索频道的需求描述。因为工作环境中没有交互设计器，所以Word文档中包含了一些交互说明。

图片

图片形式的产品需求文档是基于效果图的描述文档，功能需求的描述以传统Word的形式标注在效果图上。这种方法在移动互联网领域经常使用，但实际上是一种图文形式的交互需求文档，只是在此基础上对功能需求进行了深度描述。

对于图片形式的产品需求文档，我们只需要重新描述全局描述即可。其他渠道页面的需求直接以图片的形式展现，比Word文档的纯文本更加生动、易读、直观。所以有些产品经理喜欢用这种方式把产品需求文档以Word的形式替换掉。

交互式原型

这里的交互原型是指上一章提到的原型设计。使用Axure PR等交互式原型设计软件制作的产品原型非常真实直观，而且原型软件还支持Word文档的元素标注和导出，所以很多产品经理喜欢用Axure PR代替Word完成产品需求文档。

我们通过Axure PR做了产品的原型之后，其实已经是一个完美的产品Demo了，所以我们只需要在注释中加入元素注释来解释功能需求，这样导出的HTML文件比Word文档更加直观易懂，是一种非常高效的解释产品需求的方式。

src=”https://p5.toutiaoimg.com/origin/1459/4337839822?from=pc”>

无论你采用哪种方式撰写需求文档，最终的目的都是为了方便团队成员理解产品的意图，因此哪种方法能够避免细节黑洞，高效完成产品的设计和研发，那么这种方法就是最有效的方法。

产品需求文档(PRD文档)系列导读