从零开始产品需求文档PRD撰写.docx

从零开始产品需求文档PRD撰写.docx

《从零开始产品需求文档PRD撰写.docx》由会员分享，可在线阅读，更多相关《从零开始产品需求文档PRD撰写.docx（19页珍藏版）》请在冰豆网上搜索。

从零开始产品需求文档PRD撰写

从零开始-产品需求文档（PRD）撰写

1、写前准备（信息结构图）

在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。

因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。

例如一篇文章的信息内容主要有：

文章标题、文章正文、文章作者、发布时间、所属分类。

初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。

罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。

当我们初次接触产品需求文档时，首先会从网络上寻找产品需求文档模板，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的PRD文档都是与实际工作不相符的，或者说是复杂的。

前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我（下图），当时我就郁闷了，这些类目更像是MRD文档，而不是PRD文档了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。

例如CMS之类的程序，这类程序采用框架式开发，将功能与模板独立，因此前端具有多变性，并且这类产品属于平台型产品。

针对这类产品，我们在规划信息结构时，只需要简单的考虑一些前端的功能需求，更多的是面向后端管理员操作进行考虑，从后端入手规划和罗列出所需要的信息内容结构。

无论是什么样的产品类型，无论从哪里入手，我们第一步都是先要罗列信息结构，因为信息结构图不仅是辅助技术人员创建数据库的图表，也是辅助产品人员进行产品功能规划的参考，只有对信息或数据的结构了解，我们才能玩转数据，玩转产品。

在信息结构转数据结构时，如果是针对已经存在的产品而增加的新功能，那么技术人员就需要根据这个信息结构进行数据库对比，已经存在的数据便直接调用，如果不存在，则就需要具体的讨论，确定新信息的使用途径和以后的扩展方向，以便确认是创建数据表还是创建数据字段。

（虽然产品经理不需要技术开发，但是如果能够懂技术原理和数据库原理，非常有助于产品规划和技术沟通。

）

信息结构图是产品层面的理解，如果要入库这些信息，还需要进行数据结构的讨论。

一条信息的存储有很多附加属性，具体是存成字段还是数据表，还是说存在中间表或者关联表，这些都需要在完成PRD文档后和数据库技术人员共同讨论。

讨论时除了展示信息结构图，还要讲解产品原型和功能需求，以便数据库技术人员了解产品意图，方便他们做数据库规划时考虑到以后的扩展。

信息结构图是我们将概念想法形成结构化的第一步，也是我们接下来几步工作的辅助文件，同时在接下来的几步工作中，我们还会不断的完善信息的结构。

2、梳理需求（产品结构图和用户流程图）

当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。

我们首先要罗列出产品的频道及页面（产品结构图），其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程（用户流程图）。

以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。

首先我们要规划出产品的频道及子频道、子模块或子页面。

（如下图）

图注：

讲解一下我对于这个思维导图的名词理解

1、频道：

某一个同性质的功能或内容的共同载体，也可称为功能或内容的类别。

2、子频道：

某频道下细分的另一类别

3、页面：

单个或附属某个频道或分类下的界面

4、模块：

页面中多个元素组成的一个区域内容，可以有一个或多个，也可以循环出现（例如:

文章列表）

5、模块元素：

模块中的元素内容，以文章列表举例：

文章标题、文章摘要、文章发布时间，这些都是元素，都是组成模块的内容，同时他们也是可以循环出现的。

元素的类型可以是：

文字、图片、链接等等

如果你学过网页设计，或者了解Web产品的模板机制，你就能够理解这些名词了。

如下图所示，这是我的博客的首页结构。

当我们规划出频道后，我们就需要以用户的视角进行一步一步的模拟操作，逐渐完善产品的结构导图。

我称为用户流程图，用于展现产品经理脑海中比较抽象的产品逻辑，也是产品经理对自己脑海中的产品想法进行梳理的一个过程。

（如下图示例）

这样做的目的就是梳理产品逻辑，让我们清楚的知道产品有几个频道，频道下面有没有子频道或者有多少个页面，这些页面里又有哪些功能模块，这些功能模块里又有哪些元素。

这样我们就模拟了用户的整个操作流程，逐一的将产品的所有功能界面操作了一遍，也列出了产品结构图和用户流程图。

有了这份结构导图，我们可以对产品进行鸟瞰式考虑和完善，当有问题时，修改起来也比原型和文档方便很多。

这样的方法同样适用于移动互联网产品的规划，并且比起Web产品更加容易梳理产品结构。

以上讲的都是前端面向浏览者的用户流程，但是如果规划的是一个平台级的大众化产品就不能从前端进行梳理了，例如CMS、BBS之类的程序，他们采用框架式开发，将功能与模板独立，前端的界面布局仅仅是通过模板机制的标签调用，因此在做产品规划时，前端是涉及不到的，也不应该从前端入手。

遇到CMS类平台产品的规划，也同样使用这样的方法，只不过是从后台入手模拟管理员的流程。

PRD文档写前准备就是让我们先通过思维导图梳理思路，明白产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素，逐步的将脑海里的想法明确梳理成结构。

虽然已经明确了产品的结构，但是这样的思维导图对于设计与技术人员依旧是抽象的，他们仍然看不懂，同时对于产品经理自己来说，这样的结构图也是没有经过推演的，具体是否符合产品逻辑，是否符合用户体验，都是没有深思过的，因此我们接下来就要进行原型设计，开始具体的考虑结构方案的可行性。

3、原型设计（手绘原型,灰模原型,交互原型）

当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。

移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。

对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。

上一篇文章我们通过思维导图将想法进行了结构化梳理，接下来我们就需要进行方案的可行性推演，验证产品功能是否可行，预估项目要花多少人力物力，因此我们就要通过原型设计进行相关需求的论证。

一开始就撰写PRD文档，我们很难对产品进行各方面的评估，也无法得知方案的可行性，并且无法直观细致的考虑产品。

原型设计是帮助我们更细致的思考，并做各项需求的评估，同时也是将自己脑海里的想法进行输出，通过原型设计后，我们就可以进行产品宣讲了。

相对于之前抽象的文字描述，原型则更加清晰产品的需求，设计和技术人员或者老板也能够更加直观的了解到产品意图。

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

AxureRP、BalsamiqMockups、UIDesigner等等。

当到了原型设计这一步时，已经不仅仅是构思了，我们需要更加深入的了解每个页面上的元素和这些元素的属性。

例如按钮元素，我们就需要考虑这个按钮的功能，并且这个功能操作后带给后端和前端的反馈。

举例这个按钮是注册会员按钮，用户操作后，第一步逻辑是验证用户输入的信息是否合法，不合法则给出前端反馈；合法则和后端通信验证是否已经存在同样信息，已经存在则给出前端反馈，不存在则进入下一步，注册成功；注册成功后的反馈是跳转页面，还是弹出层提示用户完善资料，这些都是需要更详情的考虑的。

当然这些更细致的思考是留在需求文档撰写时的，而此时我们需要做的就是把这些元素通过原型表现出来。

原型设计的表现手法主要有三种：

手绘原型、灰模原型、交互原型

1、手绘原型

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

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

2、灰模原型

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

灰模原型常用于移动互联网产品的设计，由于移动产品的交互需求复杂，原型设计软件难以高效的表达需求，因此移动互联网产品的设计通常是灰模原型加交互文档组合成PRD文档

3、交互原型

交互原型是使用原型设计软件完成的原型，常用软件是AxureRP，通常情况交互原型的设计仅早于PRD文档，是产品经理想法推演的最后一步。

通过AxurePR之类的交互原型软件制作出来的产品原型，在功能需求与交互需求的表现和正式产品几乎是一致的，所以有时交互原型也被称为产品Demo版。

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

（很多公司给视觉设计师的职称是交互设计师，但本质还是视觉设计）

关于AxurePR制作交互原型我在这里就不多介绍了，网络上有很多这类的教程，我个人建议是学习AxurePR时，随便了解一下网站模板的结构，这样可以帮助你更加结构化使用AxurePR。

（推荐一个我之前画的原型，网站已经关了，原型当时设计的也比较简陋，有很多缺失的页面，仅供参考看看。

）

分享微世界原型Demo（源文件）

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

产品经理设计原型是为了帮助自己更细致的思考方案的可行性，也是为了给别人讲解的时候，让听众能够清晰直观的了解产品，同时也是为了确保产品在执行过程中，是按产品经理最初设想的需求和期望完成的。

因此产品经理的原型是没有很高的要求的，只要对方能够听懂看懂，使用手绘原型是最高效率的方法。

4、撰写文档（PRD文档）

当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的（很多产品经理直接使用Axure制作PRD）。

当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范标准，这类情况可能是需要存档归类。

无论什么样的规范标准，PRD文档的目的都是相近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写PRD文档的方式。

前三篇文章我们逐步梳理了产品的信息结构、框架结构、界面结构（原型），这一步我们就要根据之前完成的工作，开始正式撰写产品需求文档了（PRD文档）。

通过之前的准备工作，我们更加清楚了产品的需求，并细致的考虑了方案的可行性，从而减少与避免了撰写文档时容易忽略的细节黑洞。

PRD文档没有标准的规范，也没有统一的模板，每个公司都不一样，并且每个人也不一样，这个取决于个人习惯和团队要求。

虽然PRD文档没有标准的规范，但是有两项是必不可少的，那就是文件标识和修改记录。

文档在撰写过程中，我们可以自行不断的修改完善，但是如果正式发布或交给团队其他成员后，一旦有了修改，为了文档的同步，我们就需要标注出文档的修改内容，备注修改记录。

关于文件标识和修改记录，大家的格式都大同小异（如下图）。

PRD文档的形式常见的有以下三种：

Word、图片、交互原型

一、Wor