教你如何写PRD教学教材Word文档格式.docx

1、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设计人员出来高保真原型图，第二轮：文档使用方：开发人员用高保真原型

2、图来对开发人员写技术需求说明有了高保真原型图，开发人员看的最明白，我们只需要写好详细的逻辑功能结构和详细的流程图PS：个人认为在工作流程中，特别是面向UI和工程师，没有必要详细的写出来什么行业分析，开发背景之类的内容，因为UI和工程师是在干活，不去关心这些问题，但一定要写清楚功能范围和此产品的目的，这样有助于UI设计人员的理解。另外，上面说的是个人理想状态，可能每个公司有自己的现实情况而有不同的流程。关键是提高效率减少不必要的扯皮沟通。2.2 产品定义 Product Definition2.2.1 What 做什么产品定义，即定义产品到底要做成什么。一般来说，比较正规的做法是撰写一份称之为

3、PRD（Product Requirements Document）的文档，该文档一般可以包括以下内容：该产品的远景目标（vision）目标市场和客户（target market and customers）的描述竞争对手分析（competitive summary）对产品主要feature的比较详细的描述这些feature的优先级初步拟定的实现进度安排用例（use cases），这可以是较粗略的大致描述，未必一定要UML Use Case图。产品的软硬件需求产品的性能要求销售方式上的思路、需求（直销还是渠道？直销怎么做？渠道怎么做？）技术支持方式上的思路、需求（提供什么样的技术服务？显然，P

4、RD文档就是对产品的整体规划，应该比上述Market Research阶段的MRD文档要细化一些：MRD文档主要侧重于市场机会的分析，得出结论“就当前市场情况而言，我们可以做什么”PRD侧重于整个产品的规划，以及business方面的需求。PRD不同于SRS（System Requirement Specification），SRS是系统需求分析说明书，是以相当技术化的语言撰写的，主要给研发人员看的。2.2.2 Goal 目标是什么产品定义是产品管理的核心工作。通过产品定义：使得公司内部所有与业务相关的部门（高层领导、研发、销售、支持等部门）都能基本清楚我们到底要做什么产品，从而统一大家的思想

5、和行动。产品定义的PRD文档，为研发部需求分析组接下来出SRS文档提供了基本依据。2.2.3 How 怎么做产品管理部门根据市场研究结果，和各个业务相关部门沟通，发挥自己的创造力来进行产品定义工作。2.2.4 Who 谁来做产品经理负责牵头，主要由产品管理部门进行具体工作实施。2.2.5 Deliverable 有无输出比较正规的做法是输出上述PRD文档。对小公司或者小团队而言，有时可以把MRD和PRD合并在一个文档里描述。从“产品需求文档”（PRD）到“产品设计文档”（PDD）传统上写产品需求文档（PRD）的做法，就是把用例、流程图和网页原型图一股脑的放到一个Word文档里。一般一个产品都包

6、含乃几十个乃至上百用例，每个用例都有自己的流程图，每个流程图又包含了少则几个多则几十的网页原型图，结果就是产品需求文档变得庞大无比，写的人费事儿，读的人更惨。自从我受到了这样文档的折磨，我就一直都在琢磨怎么才能把文档写得更简单一点，让阅读的人通常是设计师和程序员能够在最短的时间内领会产品的设计。原来做UI设计师的时候，我创造了一种用流程图来表示产品交互的办法，这个方法受到了很多人的欢迎，这篇文章也引起了一定的反响。其实当时在实际使用的时候，我不仅产出这样一份流程图，还利用网页热区，把流程图中的界面元素（蓝色的元素）和原型网页（HTML文件）给结合起来了，这样设计师和程序员在看流程图的时候，只要

7、用鼠标点一下界面元素，就可以连接到原型网页，非常方便！这个办法我一直都在用，只是当时没有写在文章里罢了。后来随着工作性质的变化，我需要越来越多地考虑产品的整体和功能、而不是像原来一样只在特定需求内围绕界面做文章，我就开始寻找把用例整合进前述方法的可能。在经过了一段时间的摸索和实践后，我逐渐形成了自己特有的一套产品需求文档的写法，为了表示区别，我称之为“产品设计文档”，简称PDD。本文就是对PDD的介绍。PDD的组成部分PDD有三个组成部分，它们分别是用例、流程图和原型图。用例用例从整体脉络上定义了产品所具有的功能。比如对于一个邮件系统来说，“写邮件”、“发邮件”和“删除邮件”等功能都是用例。用

8、例比较流行的写法，是在每一个用例中标明它的前后置条件和异常情况等属性。不过在PDD中，我完全放弃了上述属性，只保留用例的名称和简要描述。因为“用例”的出发点就是“用户”，如果你站在一个用户的角度来思考产品的功能，你会发现那些属性你根本就不会考虑。并且，各种前后置条件和异常情况，完全可以放在流程图中，这样更清楚。流程图流程图是对用例的细化，它可以清晰地表现一个用例所有相关的前置、后置和分支条件。流程图的画法我在“画Web流程图的一点心得”一文中已经说得非常清楚了，在此不再赘述。唯一值得注意的是，我以前并没有意识到流程图本身也是有ISO标准的，因此“画”中使用的流程图元素并不符合ISO标准，也和一

9、些已经成型的系统（比如这篇“描述信息结构和交互设计的图示词汇表”）有出入，因此元素在使用上还存在一些问题。在日常工作当中我已经对元素使用做了修改，以后有时间我会更新“画”一文的内容，也有可能直接把模板放出来。原型图原型图是对流程图中“界面元素”的展现。这个东西没什么可说的。PDD的表现方式用例、流程图和原型图一般都是产片需求文档（PRD）中已有的东西，PDD在这点上和PRD没什么区别。而下面要说的表现方式，则是PDD的精髓。我比较孤陋寡闻，还没看到过有人像我这样组织这三块内容，所以姑且认为这是我的首创吧。用例和流程图首先把用例和流程图整合起来。方法很简单，利用网页的frame标签，新建几个帧：

10、1. index.html另外两个帧的容器，不用解释吧 2. navigation.html导航帧，用于存放用例列表 3. main.html默认情况下的主帧，用于存放文档简介、作者、版本和更新日志一类的东西 然后新建一大堆网页，把所有的流程图都放在这些网页里，每个流程图（即每个用例）放在一个网页里，最后修改navigation.html，把用例名称和其对应的网页链接起来。完工以后，页面应该是下面这个样子：PDD文档首页左侧为用例，右侧为流程图好了，左侧为用例，右侧为流程图，这样就把用例和流程图整合了起来，并且结构清晰，查看方便。流程图和原型图整合流程图和原型图的重点在于，提供一种方便的方式，

11、以让读者能够在看流程图时方便的看到其中包含的原型图。为了达到这个目的，我的做法是：1. 在用OmniGraffle画流程图时，选择界面元素（蓝色的那个），然后在“检查器”“属性：动作”中选择“打开文件”，然后按“选择文件”，找到你的原型图文件并按“确定”，这样你这个元素就和原型图链接起来了。如下图所示： 2. 在OmniGraffle中输出这个流程图文档时，不是选择图片，而是选择“HTML图像映射”，这样在生成出来的网页上，蓝色的界面元素都是可以点击的，点了以后就链接到原型图。很方便对吧？但这还不够；3. 用Lightbox，把所有图片链接都改成弹出图层，这次再点刚才那些链接看看，效果是不是更

12、棒？好了，通过这样的方法，产品设计文档（PDD）就将用例、流程图和原型图这三块内容有效的整合了起来。如何正确的写产品需求文档（PRD）附常用工具宗旨：通过工具把思想有逻辑、有细节的合理的组织到一起！互联网行业，蓬勃兴起，很多从事产品工作。不管是生手、新手、老手还是高手，我也想和大家分享一下产品需求文档的一些心得，希望能帮助大家（pa/pm）更好的提高自身水平、提高工作效率。我这里只是简单的从需求的实施环节进行描述。之前的需求的调查、需求的获取、需求的比较分析取舍等等都不再阐述了。1、熟悉项目发生的相关业务行为。言下之意，就是说：我们要做的是什么项目，我们这个项目主要是做什么业务，具体业务我们怎

13、么通过更合适的框架、平台去实现它、支撑它。简而言之，得要求：面向业务（对象），进行业务行为（设计），也是需求的开始，推荐工具：Ration rose 说明：通过use case 可以很容易，很清晰的将整个业务员系统直观、规范的表达出来，按照模块建立各个package,从而将复杂的业务通过case直观的表现出来。工程师看的明白、产品人员也看得明白。2、将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一很笼统的说，就是；流程问题流程就是逻辑，你只有制定合理的、符合业务实际情况。符合系统实现（可实现、容易或稳定实现）的流程，才会更好支持日后的业务系统和管理系统服务实际的业务。不管是进销存、还是S

14、AP原理其实都是相通的。Visio 2007 Visio是个老掉牙的工具了，从微软手里出到了07版本，它该有的模型都有了，通过visio你可以直接的把整站流程框束在文档上。不论你开发怎么样的系统，需求什么样的环境，都可以一一标明出来。你的流程图的好坏直接会影响工程师实现你指定产品的实现方式。所以强调一点，产品人员要熟悉计算机开发，熟悉人机交互，熟悉一些常用的开发方式，这样有助于很好的和团队做融合，更好的框架更容易扩展。3、把项目条目化，条理化，目录结构具体规定好。有了上面主要的CASE和流程的保障，接下来就应该要从系统的功能方面做条目化的规划制定了。功能怎么排列，设置更符合业务的使用逻辑，怎么样让使用者更容易、直观的入手，怎么样一个很好的B/S或C/S的功能界面呈现到前台。Mind manager mind manager是一款可视化思维导图软件，它可以智能的建立各个模块，各个主、次、平级目录。同时也当便做调整