产品需求文档PRD的写作方法.docx
《产品需求文档PRD的写作方法.docx》由会员分享，可在线阅读，更多相关《产品需求文档PRD的写作方法.docx（10页珍藏版）》请在冰豆网上搜索。
产品需求文档PRD的写作方法
.
（PRD）的写作方法产品需求文档
也是如文档）以下称无论我们做什么事都讲究方式方法，写产品需求文档（PRD文档的一些方法，而这一篇文章主此，之前我通过五篇文章分享了自己写PRD要是对之前五篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。
产品需求文档（PRD）的写作五篇章：
）
1、写前准备（信息结构图）2、梳理需求（产品结构图和用户流程图）灰模原型,交互原型,3、原型设计（手绘原型）
、撰写文档（PRD文档4）（UML用例图、流程图5、用例文档
1、写前准备（信息结构图）：
.
.
文档之前，我们需要先罗列出产品功能的信息内容，这一步是将PRD在写同时也可以想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，所以我们不需要罗列的很详辅助服务端技术人员创建数据库。
因为这是第一步，细，在之后的步骤里，我们会逐步改进和完善信息内容。
例如一篇文章的信息内容主要有：
文章标题、文章正文、文章作者、发布时但是在之后的功能规划中逐所属分类。
初始的功能需求只有这些信息内容，间、因此第一步我们不用刻意的追求信渐更加细致的考虑时，可能会增加或者删减，息的全面。
罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主因此我称这一步为信息结我最常用的方法就是思维导图，要的是能够清晰易懂，构图。
：
产品结构图和用户流程图）2、梳理需求（当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想我们首先要罗列出产品的频道及法更加结构化，因此这一步是梳理产品的需求。
，其次再基于产品结构图梳理出频道及页面中的功能，并延伸产品结构图）页面（。
（用户流程图）构建出用户的操作流程以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。
）,,（3、原型设计手绘原型灰模原型交互原型：
.
.
当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。
推演和讨论方首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，移当有一定的进展之后，我们再通过软件工具进行更深入的设计。
案的可行性，动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。
对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案抽象的语言描述导致听众理解困难和同时也是为了避免产品宣讲时，的可行性，理解偏差。
：
文档）（PRD4、撰写文档当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一很多产品经理文档的目的（PRD般情况下，通过原型加描述的方式就已经完成了PRD）。
直接使用Axure制作文档有特定的规范标准，PRD当然也会有一些个人或团队的要求不一样，对文档的目的都是PRD这类情况可能是需要存档归类。
无论什么样的规范标准，PRD相近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写文档的方式。
）（UML5、用例文档用例图、流程图：
.
.
文档中的重PRD主要讲解《产品需求文档（PRD）的写作方法》的补充文章，要辅助文档“用例文档”。
）
（–写前准备信息结构图一产品需求文档的写作（）
当我们初次接触产品需求文档时，首先会从网络上寻找产品需求文档模板，PRD希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的文档都是与实际工作不相符的，或者说是复杂的。
发来一份他写的产品需求文档目录截图前几天一位从事产品类工作的朋友，文档了，PRD而不是当时我就郁闷了，，这些类目更像是MRD文档，）（给我下图文档的见解PRD分享一些我关于PRD因此我决定写几篇讲述写作文档的文章，和写作方法。
.
.
中文的意思是产品的缩写，是英文ProductRequirementDocumentPRDMRD、文档是基于BRD需求文档，具体的名词介绍大家可以询问Google。
PRD因此阅读这份文档的人群绝大多数的延续文档，主要用于产品设计和开发使用，设计师更多依赖于原型进行交互或视觉的设是设计与技术人员。
在这类人群中，他们不太关注因此看这份文档的人就会偏向于技术人员。
相对于技术人员，计，产品的定义就已经向产品的商业需求和市场愿景，因为在进行产品讨论立项时，参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、文档是一份详细的产品功能需求说明文档，是产品文元素等等内容，因此PRD档中最底层和最细致的文档。
文档是一份没有闲话，直入主题的功能说明文档，因此我们在写作时，PRD我们需在写作这份文档前，脑海里构思的是成品产品的界面功能的逻辑线框图。
的相关需求消化并融合规划出产品的结构图。
MRDBRD、要先做一些准备，把件软维导图思使推以，类思属作备些为因这准工是于维的所我荐用进行规划工作。
（MindManager）有了信息结构我们才能继续规划产品的第一步就是梳理出产品的信息结构，.
.
是数据并且信息结构是服务端技术人员创建数据库的依据，往下规划产品结构，没有人能够比产品经理更加清楚所需对于新产品或者新功能，结构的辅助文件。
要的信息内容了，因此第一步我们就需要先将这些信息罗列出来，形成结构化。
（如下图）
这张图是以我的博客作为示例，在罗列信息结构时，我们更多的是考虑信息信息结构的因此在这一步，我们还不需要深入的考虑产品的界面与功能。
数据，考虑有面向前端的，也有面向后端的，具体视产品类型而定。
之类的程序，这类程序采用框架式开发，将功能与模板独立，因CMS例如我们在规划针对这类产品，此前端具有多变性，并且这类产品属于平台型产品。
更多的是面向后端管理员信息结构时，只需要简单的考虑一些前端的功能需求，操作进行考虑，从后端入手规划和罗列出所需要的信息内容结构。
无论是什么样的产品类型，无论从哪里入手，我们第一步都是先要罗列信息也是辅助产品人因为信息结构图不仅是辅助技术人员创建数据库的图表，结构，我们才能玩转数据，只有对信息或数据的结构了解，员进行产品功能规划的参考，玩转产品。
.
.
在信息结构转数据结构时，如果是针对已经存在的产品而增加的新功能，那已经存在的数据便直接调么技术人员就需要根据这个信息结构进行数据库对比，确定新信息的使用途径和以后的扩展方则就需要具体的讨论，用，如果不存在，（虽然产品经理不需要技术开发，以便确认是创建数据表还是创建数据字段。
向，）但是如果能够懂技术原理和数据库原理，非常有助于产品规划和技术沟通。
信息结构图是产品层面的理解，如果要入库这些信息，还需要进行数据结构还是说一条信息的存储有很多附加属性，具体是存成字段还是数据表，的讨论。
文档后和数据库技术人员共同存在中间表或者关联表，这些都需要在完成PRD以便数据库还要讲解产品原型和功能需求，讨论。
讨论时除了展示信息结构图，技术人员了解产品意图，方便他们做数据库规划时考虑到以后的扩展。
也是我们接下来几步工信息结构图是我们将概念想法形成结构化的第一步，作的辅助文件，同时在接下来的几步工作中，我们还会不断的完善信息的结构。
二（）产品需求文档的写作）
（梳理需求产品结构图和用户流程图.
.
我们将概念想法形成了信息结构，罗列出了产品的所有信息内容，现上一篇绘制出产品结构图和用户开始规划产品的功能需求，在我们就要依据信息结构，（如下图）流程图。
首先我们要规划出产品的频道及子频道、子模块或子页面。
图注：
讲解一下我对于这个思维导图的名词理解也可称为功能或内容的类别。
某一个同性质的功能或内容的共同载体，1、频道：
、子频道：
某频道下细分的另一类别2、页面：
单个或附属某个频道或分类下的界面3、模块：
页面中多个元素组成的一个区域内容，可以有一个或多个，也可以循4.
.
）
文章列表环出现（例如:
、模块元素：
模块中的元素内容，以文章列表举例：
文章标题、文章摘要、文5同时他们也是可以循环出现章发布时间，这些都是元素，都是组成模块的内容，的。
元素的类型可以是：
文字、图片、链接等等产品的模板机制，你就能够理解这些Web如果你学过网页设计，或者了解名词了。
如下图所示，这是我的博客的首页结构。
当我们规划出频道后，我们就需要以用户的视角进行一步一步的模拟操作，逐渐完善产品的结构导图。
我称为用户流程图，用于展现产品经理脑海中比较抽象的产品逻辑，也是产品经理对自己脑海中的产品想法进行梳理的一个过程。
（如下图示例）
.
.
这样做的目的就是梳理产品逻辑，让我们清楚的知道产品有几个频道，频道这些功能这些页面里又有哪些功能模块，下面有没有子频道或者有多少个页面，逐一的将产品的模块里又有哪些元素。
这样我们就模拟了用户的整个操作流程，所有功能界面操作了一遍，也列出了产品结构图和用户流程图。
有了这份结构导图，我们可以对产品进行鸟瞰式考虑和完善，当有问题时，这样的方法同样适用于移动互联网产品的规修改起来也比原型和文档方便很多。
产品更加容易梳理产品结构。
Web划，并且比起但是如果规划的是一个平台级的以上讲的都是前端面向浏览者的用户流程，.
.
之类的程序，他们采用、BBS大众化产品就不能从前端进行梳理了，例如CMS前端的界面布局仅仅是通过模板机制的标签调框架式开发，将功能与模板独立，CMS遇到前端是涉及不到的，用，因此在做产品规划时，也不应该从前端入手。
只不过是从后台入手模拟管理员的也同样使用这样的方法，类平台产品的规划，流程。
明白产品有多少个文档写前准备就是让我们先通过思维导图梳理思路，PRD频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素，逐步的但是这样的思维虽然已经明确了产品的结构，将脑海里的想法明确梳理成结构。
同时对于产品经理自导图对于设计与技术人员依旧是抽象的，他们仍然看不懂，是否符合这样的结构图也是没有经过推演的，具体是否符合产品逻辑，己来说，开始具体的因此我们接下来就要进行原型设计，都是没有深思过的，用户体验，考虑结构方案的可行性。
并说明为什么原型设计要早于产品需下一篇我将讲解原型设计的几种方法，求文档的撰写。
）三产品需求文档的写作（）
,（原型设计手绘原型灰模原型交互原型.
.
接下来我们就需要上一篇文章我们通过思维导图将想法进行了结构化梳理，进行方案的可行性推演，验证产品功能是否可行，预估项目要花多少人力物力，文档，我PRD因此我们就要通过原型设计进行相关需求的论证。
一开始就撰写并且无法直观细致们很难对产品进行各方面的评估，也无法得知方案的可行性，的考虑产品。
原型设计是帮助我们更细致的思考，并做各项需求的评估，同时也是将自己相对于通过原型设计后，我们就可以进行产品宣讲了。
脑海里的想法进行输出，设计和技术人员或者老板也原型则更加清晰产品的需求，之前抽象的文字描述，能够更加直观的了解到产品意图。
原型设计是将结构化的需求进行框架化，因此原型也被称为线框图，具体的BalsamiqRPAxure、表现手法有很多种，相关的辅助软件也有很多，例如：
等等。
、MockupsUIDesigner当到了原型设计这一步时，已经不仅仅是构思了，我们需要更加深入的了解我们就需要考虑这个按钮每个页面上的元素和这些元素的属性。
例如按钮元素，举例这个按钮是注册会员的功能，并且这个功能操作后带给后端和前端的反馈。
.
.
不合法则给出第一步逻辑是验证用户输入的信息是否合法，按钮，用户操作后，已经存在则给出前端合法则和后端通信验证是否已经存在同样信息，前端反馈；反馈，不存在则进入下一步，注册成功；注册成功后的反馈是跳转页面，还是弹当然这些更细致的思考出层提示用户完善资料，这些都是需要更详情的考虑的。
而此时我们需要做的就是把这些元素通过原型表现出是留在需求文档撰写时的，来。
原型设计的表现手法主要有三种：
手绘原型、灰模原型、交互原型、手绘原型1因为原型也被称为线框图，因此手绘是最简单直接的方法，也是最快速的表）。
如下图现产品轮廓的手法（
手绘原型在初期验证想法时非常高效，也方便讨论和重构，同时也适合敏捷开发时快速出原型。
2、灰模原型和灰模原型是由图形设计软件制作而成，我最常用的软件是PhotoShop.
.
，相对手绘原型，灰模更加清晰和整洁，也适用于宣讲，但是需要产FireWorks。
）品人员熟悉使用图形设计软件（如下图
灰模原型常用于移动互联网产品的设计，由于移动产品的交互需求复杂，原因此移动互联网产品的设计通常是灰模原型加型设计软件难以高效的表达需求，文档。
（过几天我再详情讲讲移动互联网的产品设计）PRD交互文档组合成
、交互原型3，通常情AxureRP交互原型是使用原型设计软件完成的原型，常用软件是文档，是产品经理想法推演的最后一步。
通过况交互原型的设计仅早于PRD.
.
之类的交互原型软件制作出来的产品原型，在功能需求与交互需求的AxurePR版。
表现和正式产品几乎是一致的，所以有时交互原型也被称为产品Demo然后由交互设通常情况下交互原型是产品经理与交互设计师共同讨论确定，因此这类工作最但是绝大多数的公司是没有交互设计师这个职位的，计师制作，（很多公司给视觉设计师的职称是交互设计师，但本终是由产品经理来负责的。
质还是视觉设计）制作交互原型我在这里就不多介绍了，网络上有很多这类的关于AxurePR时，随便了解一下网站模板的结构，这样可教程，我个人建议是学习AxurePR。
以帮助你更加结构化使用AxurePR以上三种方法并不是渐进的流程，而是三种原型设计的方法，具体取决于你的产品需求和团队要求。
也是为了给产品经理设计原型是为了帮助自己更细致的思考方案的可行性，同时也是为了确保产品在执别人讲解的时候，让听众能够清晰直观的了解产品，因此产品经理的原型是是按产品经理最初设想的需求和期望完成的。
行过程中，没有很高的要求的，只要对方能够听懂看懂，使用手绘原型是最高效率的方法。
.
.
）
文档–撰写文档（PRD（产品需求文档的写作四）
）（，原型前三篇文章我们逐步梳理了产品的信息结构、框架结构、界面结构这一步我们就要根据之前完成的工作，开始正式撰写产品需求文档了（PRD文档）。
通过之前的准备工作，我们更加清楚了产品的需求，并细致的考虑了方案的可行性，从而减少与避免了撰写文档时容易忽略的细节黑洞。
PRD文档没有标准的规范，也没有统一的模板，每个公司都不一样，并且每个人也不一样，这个取决于个人习惯和团队要求。
虽然PRD文档没有标准的规.
.
文档在撰写过程中，但是有两项是必不可少的，那就是文件标识和修改记录。
范，一旦我们可以自行不断的修改完善，但是如果正式发布或交给团队其他成员后，备注修改记录。
为了文档的同步，我们就需要标注出文档的修改内容，有了修改，。
（如下图）关于文件标识和修改记录，大家的格式都大同小异
、图片、交互原型文档的形式常见的有以下三种：
WordPRDWord
一、具体视你的产品要求进文档，主要有四个部分组成（PRD这是传统意义上的（在第一篇文章里我），分别是：
结构图、全局说明、频道功能、效果图。
行划分文档目的性很明PRD有讲过，PRD文档的阅读者更多是偏向于技术人员，因此文档是没有关于市场方面的描述，PRD确，就是要描述产品的功能需求，所有在能够让阅读者看懂并且了解产品意同时我也建议大家尽量减少不必要的文字，这主要是因为绝大多数人是没有足够耐心认真看完图的情况下，文字越少越好。
）PRD文档的，因此我们要尽量减化文档内容。
1、结构图：
1.1、信息结构图：
主要是辅助服务端技术人员创建或调整数据结构的参考文件.
.
、产品结构图：
主要是辅助设计和技术开发人员了解产品的全局结构，他和1.2用户流程图不一样，产品结构图只是罗列出产品的频道和页面。
、全局说明：
主要讲解产品的全局性功能的说明，例如网站产品的页面编2码、用户角色，移动产品的缓存机制、下载机制，这类全局性功能的说明。
这里我举一个移动产品的“状态维持与恢复”的例子，示例如下。
状态的维持与恢复，产品需要维持用户键、锁屏、自动关机）当用户退出产品时（误操作、Home操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。
维持状态包括流程操作、信息浏览、文本输入、文件下载。
锁屏状态时，如果用户在产品中有下载任务时，仍然保持下载。
见附件PDF）产品需求文档示例：
（、频道功能：
以频道为单位，页面为子项，分别描述产品的频道、页面及3）。
（页面模块元素的功能需求格式如下示例格式、频道名：
频道介绍及需求说明112、页面：
页面介绍及需求说明.
.
：
模块功能需求说明2.1、页面模块1：
功能说明、页面模块2.1.11-元素1：
功能说明、页面模块2.1.21-元素2：
模块功能需求说明、页面模块2.22在撰写功能需求时，我们需要考虑用户的流程，例如一个“完成”按钮，我反馈提示是什么样的形式反馈，们需要描述他完成后，系统要不要给出反馈提示（跳转到哪），或者要不要跳转页面（内容显示成什么，有没有内容需要调取数据库如果是子页面就需还是这个功能的子页面，个页面，这个页面是其他频道页面，要再描述这个子页面的模块及元素内容）。
4、效果图：
效果图是由设计师完成的产品图，和实际开发完成的产品保真度一致。
二、图片
图片形式的PRD文档是基于效果图的说明文件，将传统Word形式的功能需求说明标注在效果图上，这种方式经常使用在移动互联网领域，实际上是图文形式的交互需求文件，只是在此基础上更深入的描述出功能需求。
对于图片形式的PRD文档，我们只需要另外再描述一下全局说明，其他频道页面的需求直接以图片形式展示，这种方式相对于Word文档的纯文字更加生动易读并且直观，因此有一些产品经理非常喜欢用这种方式代替Word形式的PRD文档。
.
.
三、交互原型之类的交AxurePR这里指的交互原型就是上一篇文章讲的原型设计，使用并且原型软件还支持元素互原型设计软件制作出来的产品原型非常真实和直观，Word来代替因此很多产品经理都喜欢使用AxurePRWord标注和导出文档，文档。
完成PRD制作出产品原型后，实际上他已经是很完善的产品AxurePR当我们通过了，因此我们只需要加上元素的标注，在标注中说明功能需求，这样导Demo是非常高效的产品需求说明方式。
文件相比Word文档更直观易懂，出的HTML———最终的目的都是为了方便团队成员理解无论你采用哪种方式产出需求文档，那高效完成产品的设计和研发，因此哪种方法能够避免细节黑洞，产品的意图，么这种方法就是最有效的方法。
的写作》的介绍写完了，一共四篇文章，好了，关于《产品需求文档（PRD）希望能够帮助到你，如果觉得文章中有什么错误或者有疑问，欢迎评论留言。
.
.
五（）产品需求文档的写作）
用例图、流程图（UML用例文档
则更UML在产品和技术领域里都有UML的技能知识，而对于产品人员的第二篇PRD多的是指用例图，也就是我所称呼的用户流程图。
在讲文档写作的实际上用户流程图是我在产品规则的初期文章里，我提到了用户流程图的制作，缺少对用例图的一种结构化的表达方式，由于以结构化的方式描述用例太抽象，逻辑性表达，并且那篇文章更偏向于功能性用户流程，还不是实际意义上的用例，.
.
用例图和用例文档。
因此今天我补文一篇，细讲一下UML用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活PRD是动报名等等功能都是需要用例辅助说明的。
用例文档的写作时间在原型设计之PRD后，通常和文档同步撰写。
的一用例文档中有两个关联文件，分别是用例图和流程图。
用例图是UML并指出该用户在产品各功能中的种类图表现方式，是从用户角度描述产品功能，主要是描述操作权限。
流程图是通过线框图形的方式描述产品功能的处理过程，功能的执行顺序、分支和循环的逻辑。
，其中用例图和流程图的制作软件常用的是写用户文档的常用软件是Word软件制作的，例如下面的第三步流程图就是用RPVisio，当然也有用Axure
制作的。
AxureRP点的“用例”是3一份完整的用例文档分别是由以下三点内容组成，其中第描述功能逻辑的部分，根据功能的多少决定有多少个用例。
用例文档的大概组成部分如下：
PRD文档。
1、修改记录：
每次修改的备注记录，同2、角色介绍：
描述参与系统中的各个角色步的流4步，其中第3步中的流程图是直接插入到第3、用例：
同下方步骤的第4程图表格项中的。
在表格文档绘制表格，Word用例文档的模板格式如同以上三点内容，通过中撰写用例描述，表格的格式和样式参考以下示例图。
和角色说明参与者、撰写用例文档的第一步是注明使用产品的各个角色1（）.
.
（如下图））。
角色介绍（
、第二步是以用例图的方式注明角色在前后端的用例关系。
（如下图）2
（如下图：
第三步是以流程图的方式注明角色在各个功能环节的活动过程。
、3以活动报名为示例）.
.
、第四步则是以用例文档的方式将以上三步整合到一起，并撰写各个功能4环节的用例描述。
（如下图）
表格说明：
、用例名：
此功能环节的名称4.1、用例编号：
在此产品中该用例的编号4.2）该功能的角色（4.3、行为角色：
参与或操作执行、简要说明：
用最少的文字描述一下该用例的需求4.4）（4.5、前置条件：
参与或操作执行此功能的前提条件.
.
4.6、后置条件：
执行完毕后的结果条件图（第三步中的图））、流程图：
该功能的角色活动过程（处理过程4.7上面示范的用例描述相对简单，也是最常用和基本的用例描述内容，当然也有稍微复杂一点的用例文档，文档中会详细描述使用场景、事件流和信息字段，也有一些用例文档还会插入产品界面效果图。
根据情况或问题给出使用场景主要描述行为角色在不同情况下使用产品时，只不过是通过文字的方式描述角色的活动相应的系统反馈。
事件流类似流程图，过程。
信息字段主要是描述用例中所用到的数据字段。
最终目的都是为了描述清晰产品逻这些更多的描述内容取决于个人的习惯，（毕竟这些文档辑，因此我的原则就是用越少的文字描述清晰越多的需求说明。
）是产品开发中的执行文档，文字不在多，表达清晰即可。
.
升级会员 