产品需求文档(PRD)的写作方法.doc

产品需求文档(PRD)的写作方法 无论我们做什么事都讲究方式方法，写产品需求文档(以下称PRD文档)也是如此，之前我通过五篇文章分享了自己写PRD文档的一些方法，而这一篇文章主要是对之前五篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。 产品需求文档(PRD)的写作 五篇章： 1、写前准备(信息结构图) 2、梳理需求(产品结构图和用户流程图) 3、原型设计(手绘原型,灰模原型,交互原型) 4、撰写文档(PRD文档) 5、用例文档(UML用例图、流程图) 1、写前准备(信息结构图)： 在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。 例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。 罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。 2、梳理需求(产品结构图和用户流程图)： 当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。 以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。 3、原型设计(手绘原型,灰模原型,交互原型)： 当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。 首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。 对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。 4、撰写文档(PRD文档)： 当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的(很多产品经理直接使用Axure制作PRD)。 当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范标准，这类情况可能是需要存档归类。无论什么样的规范标准，PRD文档的目的都是相近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写PRD文档的方式。 5、用例文档(UML用例图、流程图)： 《产品需求文档(PRD)的写作方法》的补充文章，主要讲解PRD文档中的重要辅助文档“用例文档”。 产品需求文档的写作(一) – 写前准备(信息结构图) 当我们初次接触产品需求文档时，首先会从网络上寻找产品需求文档模板，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的PRD文档都是与实际工作不相符的，或者说是复杂的。 前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我(下图)，当时我就郁闷了，这些类目更像是MRD文档，而不是PRD文档了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。 PRD是英文Product Requirement Document的缩写，中文的意思是产品需求文档，具体的名词介绍大家可以询问Google。PRD文档是基于BRD、MRD的延续文档，主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术人员。相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。 PRD文档是一份没有闲话，直入主题的功能说明文档，因此我们在写作时，脑海里构思的是成品产品的界面功能的逻辑线框图。在写作这份文档前，我们需要先做一些准备，把BRD、MRD的相关需求消化并融合规划出产品的结