首先，产品经理主要需要输出的文档有:信息结构图(***品经理自己整理信息，并与开发人员讨论数据结构的基础)、产品结构图(***品团队更清晰地管理产品的功能)、原型图(线路图，用于产品展示、设计、技术，以及老板更清晰地理解产品意图)、产品需求文档(最终执行文档，旨在
下面将说明这些文档的含义以及使用的制作工具。

产品需求文件(PRD)

产品设计的最终表现形式称为产品需求文档，业内也常称为PRD文档，是英文Product Requirement Document的缩写。
PRD文档是基于BRD和MRD的延续文档，主要面向管理层人员，其中大部分是设计和技术人员。在这类人群中，设计师更多的是依靠产品原型进行交互或视觉设计，所以看这份文档的人主要是技术人员。与技术人员相比，他们并不太关注产品的商业需求和市场眼光，因为在讨论和建立产品的时候，产品的定义就已经被宣讲给参与设计和R&D的人了。所以技术人员更注重界面，功能，交互，元素等等。所以产品需求文档是详细的产品功能需求规格文档，是产品文档中最底层也是最详细的文档。主要介绍功能描述。目的是一样的。需要能够定义产品的功能需求，这样执行人员才能理解任务需求。—产品策划和设计后的最终执行文件。

1。列表信息(信息结构图)

在写产品需求文档之前，我们应该首先列出产品功能的信息内容。这一步是我们逐步理清思路的第一步，也是帮助我们下一步设计功能的辅助资料，也可以帮助服务技术人员创建数据库。因为这是第一步，所以不需要详细列举。在接下来的步骤中，我们将逐步改进和完善信息内容。

列出信息内容的方式有很多种，比如文本形式、思维导图形式等。最重要的是可以清晰易懂。我最常用的方法是用MindManager把它列成一个结构图，所以我把这一步叫做“信息结构图”。

i***ge.png

上图是以博客系统为例的信息结构图。信息结构图是接近数据库结构的图。在列出信息结构时，考虑了更多的信息数据，但并不是真正的数据库结构。信息图是提供给产品经理自己整理信息内容的结构图，也是方便产品经理和服务技术人员沟通数据结构的参考图。技术人员会根据这个图的内容结合产品原型或者需求文档，然后规划设计真正的数据库结构。

信息结构图中关于友情链接功能的信息数据只有两个内容:名称和链接。但在实际的功能需求中，友情链接也有两个功能，即“显示或隐藏”和“打开新窗口”。这两个功能会在产品原型和需求文档中详细描述，但在信息结构中没有体现，因为从产品层面来说，这两个功能只是功能，不是信息内容。但是在真实的数据库中，友情链接的这两个函数也是有字段参数的。程序读取参数后会知道友情链接的属性，然后处理友情链接是显示还是隐藏，是打开一个新窗口还是打开这个窗口。通过友情链接的例子我们知道，在实践中，数据结构和信息结构是不一样的，信息结构只是产品层面的数据内容。

无论是什么样的产品，无论从哪里入手，我们的第一步都是先列出信息结构，因为信息结构图不仅是辅助技术人员创建数据库的图表，也是产品人员规划产品功能的参考。只有了解信息或数据的结构，才能更好地设计产品。信息结构图是我们构建概念和思路的第一步，也是我们下一步工作的辅助文档。同时，在接下来的步骤中，我们将不断完善信息结构。

2。整理需求(产品结构图)

当我们知道了产品的信息结构后，我们需要在头脑中对产品需求进行规范，让自己的思路更加结构化，所以这一步就是对产品需求进行梳理。在设计产品原型之前，首先要列出产品的功能结构，包括频道、页面、模块、元素。这一步仍然使用mind***nager，把产品的结构绘制成类似于一个楼盘的鸟瞰图的结构图，所以我把这一步叫做“产品结构图”。

产品结构图是以结构化的方式展示产品原型的图表。结构内容和产品原型一样，从渠道到页面，再细化页面的功能模块和元素。所以产品结构图是产品经理在设计原型之前整理思路的一种方式，并不是给其他工作人员看的文档。一个鸟瞰式的结构图可以让产品经理对产品结构有一个清晰的认识，便于思考。

i***ge.png

如上例所示，“活动书”的产品结构是:产品-->:渠道-->:页面-->:页面-->:运营-->:元素我们换个角度来看例子。产品结构图实际上是结构化的产品原型。这样做的目的是为了梳理产品结构的逻辑，让我们清楚的知道产品有多少个频道，频道下面有没有子频道或者有多少个页面，这些页面里有哪些功能模块，这些功能模块里有哪些元素。
在我们第一步的“信息结构图”基础上绘制的“产品结构图”。有了这个结构图，我们就可以鸟瞰产品并加以改进。有问题的时候修改比原型和文档方便多了。比如后续策划中，我们发现文章图片等附件上传后管理不方便，可以在结构图中增加一个“附件管理”通道。如果使用产品结构图，添加和修改附件管理的功能会比原型工具更加方便和高效。

产品结构图的方法同样适用于移动互联网产品的设计，比Web产品更容易梳理产品结构。

产品结构图是一种让产品经理通过思维导图整理思路的方法。通过这种方法，可以明确一个产品有多少个频道、页面、功能模块、元素，逐步将自己头脑中的想法整理成结构。虽然这种方法可以理清产品的结构，但是这样的思维导图只有产品经理自己才能理解，因为对于设计师和技术人员来说是一种抽象的表达，没有详细的解释很难理解。

产品结构图是将产品原型具体化的一种方式。只列出了产品的频道页面和功能，没有详细的推演。细化是符合产品逻辑还是符合用户体验还没想好。因此，我们接下来将设计原型，并开始具体考虑可行性。

3。原型设计(接口线路图)

当我们逐渐了解产品需求，梳理出产品的各种渠道和页面，那么这一步就开始验证这些想法的具体界面表现和方案的可行性。

原型设计是帮助我们更仔细思考和评估需求的一种方式，也是输出自己想法的一种方式。原型设计完成后，我们就可以宣讲产品了。与抽象的文字描述相比，原型更直观地展现了产品的需求，设计和技术人员或者老板可以更直观地知道产品的意图。

原型设计是为了构建结构化的需求。所以原型也叫线框。还有很多具体的表达方式和相关的辅助软件，比如Axure RP、Balsamiq Mockups、UIDesigner等。

说到原型设计，不仅仅是构思。我们需要更多地了解每个页面上的元素及其属性。比如按钮元素，我们需要考虑这个按钮的功能，这个功能会给后端和前端带来反馈。比如注册会员按钮，用户操作后，第一个逻辑步骤是验证用户输入的信息是否合法，如果不符合法律，给予前端反馈；然后法务和后端沟通验证是否已经存在相同的信息，如果是，则给予前端反馈，如果不是，则进入下一步，注册成功；注册成功后，反馈是跳转到页面，或者弹出层提示用户完善信息，

这些都是需要更多细节的考虑。当然，这些更细致的想法是留给需求文档的写作的，这时候我们需要做的就是通过原型来展现这些元素。

原型设计的表现方法主要有三种:手绘原型、灰色原型和交互原型。从工作效率的角度出发，我强烈建议用手绘的方式在纸莎草纸上快速画出产品的原型，并对方案的可行性进行推导和讨论。方案可行性验证后，我们会根据个人习惯或团队需求，通过软件工具进行更深入的设计。

①手绘原型———便于讨论和重构。第一次采用手绘

。

因为原型也叫线框，手绘是最简单直接的方法，也是表达产品轮廓最快的方式。

i***ge.png

手绘原型在最初验证想法的时候效率很高，也方便讨论和重构。同时也适用于敏捷开发中的快速原型。

②灰色模型原型

灰色原型由平面设计软件制作。最常用的软件是Photoshop和Fireworks。相比手绘原型，灰色原型更加清晰整洁，也适合在正式场合做PPT演示。

i***ge.png

灰色原型也可以叫平面原型，所以如果不能用图形软件，也可以用Axure RP设计。与交互原型相比，灰色原型只是缺少交互效果，仅以线框结构展示产品需求，使得产品需求更加规则直观。

i***ge.png

③交互原型—-产品的演示版，耗时且逼真

交互原型是由原型设计软件完成的原型。常用的软件是AxureRP。通常交互原型的设计早于产品需求文档，是产品经理推导思路的重要一步。AxureRP等交互原型软件制作的产品原型，无论是功能需求还是交互需求，都与正式产品相差无几，所以有时候交互原型也被称为产品演示版。

通常交互原型是由产品经理和交互设计师确定，然后由交互设计师制作。但是大部分公司都没有交互设计师这个职位，所以这种工作最终还是由产品经理负责。

以上三种方法不是循序渐进的过程，而是原型设计的三种方法，看你的产品需求和团队需求。

对于产品经理来说，原型设计是帮助我们仔细考虑方案，论证其可行性。同时也是

让观众在产品展示过程中清晰直观的认识产品，避免抽象的语言描述导致观众理解困难和产生偏差

。产品原型也是为了保证产品在执行过程中，按照产品经理最初设想的需求和期望完成。

所以对产品经理的原型要求不高，只要对方能看懂就行，所以用手绘原型是最高效的方法。

4。需求文档(PRD文档)—强调

产品需求文档有多种形式，

包括Word、图片、交互原型

。文档的内容通常包括信息结构图、接口线路图、功能流程图和功能描述文档。产品需求文件虽然没有标准规范，但有两项必不可少，即# #文件标识和修改记录。在写文档的过程中，我们可以自己不断修改完善。但是如果是正式发布或者交给团队其他成员，一旦修改，为了文档同步，我们需要把文档修改的内容标注出来，并在修改记录上做批注，方便大家查看和了解修改的内容。

i***ge.png

①单词

这是一份传统意义上的产品需求文档，主要由四部分组成(具体根据产品需求划分)，分别是:结构图、全局描述、通道功能和效果图。

因为产品需求文档的读者主要偏向于技术人员，所以文档的目的很明确，就是描述产品的功能需求，所有的产品需求文档都没有关于市场的描述。

为了保证需求的执行效率，建议您尽量减少不必要的文字。在读者能够理解和明白产品意图的情况下，字数越少越好。这主要是因为大部分人没有足够的耐心仔细阅读产品需求文档，所以要尽量减少文档的内容。

①-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文档中包含了一些交互说明。

& ltmeta charset = & # 8221utf-8 ″& gt

②图片—-产品文档的最佳代表

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

对于图片形式的产品需求文档，我们只需要描述整体描述即可。其他渠道的要求直接以图片的形式展示，比Word文档的纯文本更生动、易读、直观。所以有些产品经理非常喜欢用Word的形式来代替产品需求文档。

i***ge.png

③交互原型—–演示，具有更好的交互式演示

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

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

i***ge.png

无论你用哪种方式写需求文档，最终目的都是为了方便团队成员理解产品的意图。因此，哪种方法可以避免细节黑洞，高效地完成产品设计，R&D是最有效的方法。