教你如何写PRD

教你如何写PRD（产品需求文档）

如何写PRD（产品需求文档）

产品需求文档，也叫业务需求文档。一般写这样的文档用WORD+VISIO或AXURE，建议互联网产品经理都熟悉一下AXURE这个软件的使用，能直接生成PRD，但是生成的文档是英文的，听说只有腾讯有个汉化的版本。下次哪位老兄进了腾讯给俺捎一个，在这里谢谢了哈。产品需求文档主要是描述产品功能，业务流程和LOFI。可以提供给UE，美工和项目经理执行的文档。

一般每个业务功能都按以下格式写：

1.1.1 （业务功能名称）

1.1.1.1 业务功能基本信息

1.1.1.2 业务功能

1.1.1.3 业务流程

1.1.1.4 业务规则

1.1.1.5 界面管理

1.1.1.6 数据要求

1.1.1.6.1 输入

1.1.1.6.2 输出

1.1.1.7 费用处理要求

1.1.1.8 打印单据／文件要求

1.1.1.9 参数要求

1.1.1.10 与其它界面的整合建议

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

文档分为两轮

第一轮：

1，文档使用方：UI设计师

2、内容：

.根据战略层定义出来产品功能范围，

.说明此产品的目的，方便UI设计人员更好的理解产品

.产品基本流程

.详细的设计框架图，推荐用axure,简单效率高

.详细文案

3、格式：

html，visio，或word，如果PS用的不熟练，不推荐使用，会影响工作效率。

上面是要UI设计人员出来高保真原型图，

第二轮：

文档使用方：开发人员

用高保真原型图来对开发人员写技术需求说明

有了高保真原型图，开发人员看的最明白，我们只需要写好详细的逻辑功能结构和详细的流程图

PS：个人认为在工作流程中，特别是面向UI和工程师，没有必要详细的写出来什么行

业分析，开发背景之类的内容，因为UI和工程师是在干活，不去关心这些问题，但一定要写清楚功能范围和此产品的目的，这样有助于UI设计人员的理解。

另外，上面说的是个人理想状态，可能每个公司有自己的现实情况而有不同的流程。关键是提高效率减少不必要的扯皮沟通。

2.2 产品定义Product Definition

2.2.1 What 做什么产品定义，即定义产品到底要做成什么。一般来说，比较正规的做法是撰写一份称之为PRD（Product Requirements Document）的文档，该文档一般可以包括以下内容：

该产品的远景目标（vision）

目标市场和客户（target market and customers）的描述

竞争对手分析（competitive summary）

对产品主要feature的比较详细的描述

这些feature的优先级

初步拟定的实现进度安排

用例（use cases），这可以是较粗略的大致描述，未必一定要UML Use Case图。

产品的软硬件需求

产品的性能要求

销售方式上的思路、需求（直销还是渠道？直销怎么做？渠道怎么做？）

技术支持方式上的思路、需求（提供什么样的技术服务？）

显然，PRD文档就是对产品的整体规划，应该比上述Market Research阶段的MRD文档要细化一些：

MRD文档主要侧重于市场机会的分析，得出结论“就当前市场情况而言，我们可以做什么”PRD侧重于整个产品的规划，以及business方面的需求。

PRD不同于SRS（System Requirement Specification），SRS是系统需求分析说明书，是以相当技术化的语言撰写的，主要给研发人员看的。

2.2.2 Goal 目标是什么

产品定义是产品管理的核心工作。

通过产品定义：

使得公司内部所有与业务相关的部门（高层领导、研发、销售、支持等部门）都能基本清楚我们到底要做什么产品，从而统一大家的思想和行动。

产品定义的PRD文档，为研发部需求分析组接下来出SRS文档提供了基本依据。

2.2.3 How 怎么做

产品管理部门根据市场研究结果，和各个业务相关部门沟通，发挥自己的创造力来进行产品定义工作。

2.2.4 Who 谁来做

产品经理负责牵头，主要由产品管理部门进行具体工作实施。

2.2.5 Deliverable 有无输出

比较正规的做法是输出上述PRD文档。对小公司或者小团队而言，有时可以把MRD和PRD 合并在一个文档里描述。

从“产品需求文档”（PRD）到“产品设计文档”（PDD）

传统上写产品需求文档（PRD）的做法，就是把用例、流程图和网页原型图一股脑的放到一个Word文档里。一般一个产品都包含乃几十个乃至上百用例，每个用例都有自己的流程图，每个流程图又包含了少则几个多则几十的网页原型图，结果就是产品需求文档变得庞大无比，写的人费事儿，读的人更惨。

自从我受到了这样文档的折磨，我就一直都在琢磨怎么才能把文档写得更简单一点，让阅读的人－通常是设计师和程序员－能够在最短的时间内领会产品的设计。

原来做UI设计师的时候，我创造了一种用流程图来表示产品交互的办法，这个方法受到了很多人的欢迎，这篇文章也引起了一定的反响。其实当时在实际使用的时候，我不仅产出这样一份流程图，还利用网页热区，把流程图中的界面元素（蓝色的元素）和原型网页（HTML 文件）给结合起来了，这样设计师和程序员在看流程图的时候，只要用鼠标点一下界面元素，就可以连接到原型网页，非常方便！这个办法我一直都在用，只是当时没有写在文章里罢了。

后来随着工作性质的变化，我需要越来越多地考虑产品的整体和功能、而不是像原来一样只在特定需求内围绕界面做文章，我就开始寻找把用例整合进前述方法的可能。在经过了一段时间的摸索和实践后，我逐渐形成了自己特有的一套产品需求文档的写法，为了表示区别，我称之为“产品设计文档”，简称PDD。

本文就是对PDD的介绍。

PDD的组成部分

PDD有三个组成部分，它们分别是用例、流程图和原型图。

用例

用例从整体脉络上定义了产品所具有的功能。比如对于一个邮件系统来说，“写邮件”、“发邮件”和“删除邮件”等功能都是用例。

用例比较流行的写法，是在每一个用例中标明它的前后置条件和异常情况等属性。不过在PDD中，我完全放弃了上述属性，只保留用例的名称和简要描述。因为“用例”的出发点就是“用户”，如果你站在一个用户的角度来思考产品的功能，你会发现那些属性你根本就不会考虑。并且，各种前后置条件和异常情况，完全可以放在流程图中，这样更清楚。

流程图

流程图是对用例的细化，它可以清晰地表现一个用例所有相关的前置、后置和分支条件。流程图的画法我在“画Web流程图的一点心得”一文中已经说得非常清楚了，在此不再赘述。唯一值得注意的是，我以前并没有意识到流程图本身也是有ISO标准的，因此“画”中使用的流程图元素并不符合ISO标准，也和一些已经成型的系统（比如这篇“描述信息结构和交互设计的图示词汇表”）有出入，因此元素在使用上还存在一些问题。在日常工作当中我已经对元素使用做了修改，以后有时间我会更新“画”一文的内容，也有可能直接把模板放出来。

原型图

原型图是对流程图中“界面元素”的展现。这个东西没什么可说的。

PDD的表现方式

用例、流程图和原型图一般都是产片需求文档（PRD）中已有的东西，PDD在这点上和PRD 没什么区别。而下面要说的表现方式，则是PDD的精髓。我比较孤陋寡闻，还没看到过有人像我这样组织这三块内容，所以姑且认为这是我的首创吧。

用例和流程图

首先把用例和流程图整合起来。方法很简单，利用网页的frame标签，新建几个帧：

1.index.html－另外两个帧的容器，不用解释吧

2.navigation.html－导航帧，用于存放用例列表

3.main.html－默认情况下的主帧，用于存放文档简介、作者、版本和更新日志一类的

东西

然后新建一大堆网页，把所有的流程图都放在这些网页里，每个流程图（即每个用例）放在一个网页里，最后修改navigation.html，把用例名称和其对应的网页链接起来。完工以后，页面应该是下面这个样子：

PDD文档首页

左侧为用例，右侧为流程图

好了，左侧为用例，右侧为流程图，这样就把用例和流程图整合了起来，并且结构清晰，查看方便。

流程图和原型图

整合流程图和原型图的重点在于，提供一种方便的方式，以让读者能够在看流程图时方便的看到其中包含的原型图。为了达到这个目的，我的做法是：

1.在用OmniGraffle画流程图时，选择界面元素（蓝色的那个），然后在“检查器”－“属

性：动作”中选择“打开文件”，然后按“选择文件”，找到你的原型图文件并按“确定”，这样你这个元素就和原型图链接起来了。如下图所示：

2.在OmniGraffle中输出这个流程图文档时，不是选择图片，而是选择“HTML图像映射”，

这样在生成出来的网页上，蓝色的界面元素都是可以点击的，点了以后就链接到原

型图。很方便对吧？但这还不够；

3.用Lightbox，把所有图片链接都改成弹出图层，这次再点刚才那些链接看看，效果

是不是更棒？

好了，通过这样的方法，产品设计文档（PDD）就将用例、流程图和原型图这三块内容有效的整合了起来。

如何正确的写产品需求文档（PRD）附常用工具

宗旨：通过工具—把思想有逻辑、有细节的合理的组织到一起！

互联网行业，蓬勃兴起，很多从事产品工作。不管是生手、新手、老手还是高手，我也想和大家分享一下产品需求文档的一些心得，希望能帮助大家(pa/pm)更好的提高自身水平、提高工作效率。我这里只是简单的从需求的实施环节进行描述。之前的需求的调查、需求的获取、需求的比较分析取舍等等都不再阐述了。

1、熟悉项目发生的相关业务行为。

言下之意，就是说：我们要做的是什么项目，我们这个项目主要是做什么业务，具体业务我们怎么通过更合适的框架、平台去实现它、支撑它。

简而言之，得要求：

面向业务（对象），进行业务行为（设计），也是需求的开始，

推荐工具：Ration rose ★★★★

说明：

通过use case 可以很容易，很清晰的将整个业务员系统直观、规范的表达出来，按照模块建立各个package,从而将复杂的业务通过case直观的表现出来。

工程师看的明白、产品人员也看得明白。

2、将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一

很笼统的说，就是；流程问题

流程就是逻辑，你只有制定合理的、符合业务实际情况。符合系统实现（可实现、容易或稳定实现）的流程，才会更好支持日后的业务系统和管理系统服务实际的业务。

不管是进销存、还是SAP原理其实都是相通的。

推荐工具：Visio 2007 ★★★★★

说明：

Visio是个老掉牙的工具了，从微软手里出到了07版本，它该有的模型都有了，通过visio 你可以直接的把整站流程框束在文档上。不论你开发怎么样的系统，需求什么样的环境，都

可以一一标明出来。你的流程图的好坏直接会影响工程师实现你指定产品的实现方式。

所以强调一点，产品人员要熟悉计算机开发，熟悉人机交互，熟悉一些常用的开发方式，这样有助于很好的和团队做融合，更好的框架更容易扩展。

3、把项目条目化，条理化，目录结构具体规定好。

有了上面主要的CASE和流程的保障，接下来就应该要从系统的功能方面做条目化的规划制定了。功能怎么排列，设置更符合业务的使用逻辑，怎么样让使用者更容易、直观的入手，怎么样一个很好的B/S或C/S的功能界面呈现到前台。

推荐工具：Mind manager ★★★★

说明：

mind manager是一款可视化思维导图软件，它可以智能的建立各个模块，各个主、次、平级目录。同时也当便做调整、做对外的功能结构的报告演示。更值得一提的是通过它可以导出到word中，方便您对word进行完善。

4、前台结构布局，合理规范的将系统脱去朦胧的华纱。

众所周知开发者和使用者是不知道这个地方应该有哪些功能，到了这一步了有哪些功能，数据提交失败有什么提示，不会使用有什么帮助或提示操作、入口。

所以做为产品人员我们要充分的考虑到上述到这些东西，对于从业人员来说这也是我们最基本的素要体现。很多人都说，要符合业务系统，要符合使用习惯，要符合浏览或人机传播，口碑，品牌形象习惯，总是就是人性化的去把这个东西设计的更合理，更易用，更有亲和。

所以，我接下来要说的这款工具，就很好的帮助了前台的布局

推荐工具：Axure rp ★★★★★

说明：

Axure是一款特别好用的产品模型设计软件，可视化操作，ajxa能直接生成页面需求，更独特的它可以实现：div onmouse onclick等很多交互事件，UI和工程师看到页面能直接看到你要设计的效果，而不是很头痛的看没完没了的文字描述了。同时他们还可以在第一时间给我良好的建议做最初的UI UE的确定，LucidSpec我觉得也不错(*^__^*) 嘻嘻……

5、穿针织网，把需求综合起来，整理成最终的产品需求文档

该做的做了，然后开始做到一个文档里，写明项目名称，把CASE/l流程、目录放近去，把项目背景、需求的各个约束、规则的界定、文字的补充说明交代清楚，同时把模块的字段，状态，对应该操作。所以模块设计的页面地址整理好，一份色香味齐全的文档就出炉了。最

后你要是不嫌弃不好，冠名—“某某某解决方案”，再做一套漂亮的PPT带着一些所谓的行业、项目数据分析，你可以直接去找风投去了。

推荐工具：Word 2007 ★★★★★

说明：

没有word我觉得是件很可怕的事情，因为我觉得很多替代文档编辑软件都没有它来的让我喜欢，不知道大家有没有同来感觉，