需求文档/产品文档是每位产品总监的必经之路，优秀的产品文档可以防止部份项目的重复沟通和编撰无效代码，提升项目开发效率。

“这里是不是少了功能按键？”“这段话是哪些意思？”“不行呀！你的文档须要补充，不然如何测试？”“口头的需求文档不算数，开发要见文字版文档”。

关于产品文档，我们总会碰到这样的对话。这么怎样防止呢，下文将仔细说到。

本文送给0-1岁的产品总监，从需求文档的目的、与用户指南的区别、需求文档的构成的维度对需求文档进行整体介绍，希望诸位PM都可以输出高效精简、清晰明了的文档。

一、目的

写需求文档前，首先要确定的是文档的受众群体和时间要求。受众群体（谁去看）确定了文档的框架构架和排版要求；时间要求限制了需求文档的精细度和美观度。

1.1受众群体

通常来说，需求文档有三个受众群体：

（1）开发团队：包括产品团队、UI、UX、技术和测试；这也是最常规的受众群体，虽然需求文档是要探讨项目要实现的功能和实现的方式、规则。

（2）企业内部：如老总、商务团队、运营团队等；一般这部份群体不会在意产品规则，她们只关心项目实现的功能和疗效。

（3）其他：比如公司制度要求留档、公司上市审计流程所需。我还见识过另一种过程：笔试。假如在笔试时递交的作品是需求文档，这么请看“商用文档”部分。

1.2时间限制

假如只是开发团队使用的需求文档（以下简称开发用文档），框架会比较简单，排版也没有特别严谨的要求，只须要做到逻辑闭环优秀产品设计，场景尽善，抒发清晰即可。假如是企业内部或其他用途的需求文档（以下简称为商用文档），不仅开发用文档的内容外，还需补充项目概述、需求剖析等栏目，这部份将在下文“商用文档”再详尽解释。

在写文档前，PM心里必需要有时限和计划，合理安排文档的进度，不能在项目前期就发生延后的情况。

假如时间急迫，首先要把关键的逻辑写清楚，其他的细节可以在开发时或项目结束后补充，比如搜索功能、填写数组的字符宽度、页面确定、关闭和返回等交互。非常是当项目团队已有一定的合作经验，构建了一定的工作默契时，这种细节在时间不容许情况下是可以省略，虽然PM也有好多更值得做的事情。

然而，假若时间充沛或则是新的开发团队，个人还是建议需求文档尽量精细，虽然见过好多设计师、开发和测试吐槽需求文档不清不楚，工作未能举办。此外，详尽的需求文档，可以大大地降低开发团队的理解误区，一定程度上，既能防止无效设计和无效代码，能够防止产品总监在投入下一个迭代工作时被开发“咨询”过多。

二、题外话：使用指南

有些-1到0.5岁的产品不是很清楚需求文档和用户指南的区别。我当初让0岁的助理写2B项目的用户指南，因为时间急迫，加上他对项目还不算熟悉，我就把需求文档的原文件发给了他，希望起帮助作用，结果最后交过来的作业却是一个简化版的需求文档。

需求文档描述的是项目的功能和产品逻辑、规则，偏向逻辑描述；而用户指南是描述项目的功能和使用流程，偏向操作流程说明。二者间都须要告诉各自的读者，功能是哪些、有哪些用；但出于目的不同，所以主题内容和详尽程度也会不一样。瞧瞧家里的家电使用说明书，就晓得如何写使用指南了。

三、PRD的构成

前文提到，因受众群体不一样，PRD可分为开发用文档和商用文档，不仅在排版、美观等有区别外，在内容上也有一定的区别。文终将会放上这两个类型的文档作为样例给诸位读者参考。

3.1开发用文档

开发用的文档只有一个宗旨：把需求说清楚说明白优秀产品设计，你们晓得要做哪些功能，做到哪些程度。

我个人也是写开发用文档比较多，渐渐产生了自己的框架规范。之后随着经验的积累，也会继续优化这套方式论。

版本迭代记录

主要是记录一个项目各个产品版本的迭代情况，如V1.0，V1.1……V2.0……。这儿指出的产品版本，主要是指产品功能的迭代。假如一个迭代只单纯涉及到bug修补、交互优化、性能优化，记不记录都可以，看个人意愿。

须要记录的内容包括：版本号、更新日期（文档初稿日期或则版本上线日期，个人更建议用版本上线日期）、主责产品总监、迭代的功能简介（从业务场景出发，一句话描述一个功能模块）。

版本更改记录

主要是记录单个版本（划重点）的更改记录。由于每位需求文档就会经历定稿、产品评审、技术评审、开发过程中N次细节调整、终稿这几个过程，须要把每次更改的地方记录出来，非常是当文档早已对项目团队公开后发生的更改。

须要记录的内容包括：更新日期（每次文档更改的日期）、产品总监（不等同该版本的主产品总监，非常是大项目有一个主产品总监，多个中学级产品总监）、修改说明（动了什么逻辑，什么页面）。

版本迭代记录是为了给予后的项目团队使用，无论是产品还是开发，便捷新成员或项目交接时快速了解项目的前世此生；版本更改记录是给当前的开发团队使用，便捷快速了解产品又改了什么逻辑，降低了什么需求（温情提示：投入开发后真不要轻易加需求）。

流程图

通常写在文档里的流程图包括两种：业务流程图和逻辑流程图，都是“非必填项”，视实际情况判定是否须要用流程图进行说明。由于在开发用文档内，任何元素都是为了帮助产品总监清晰说明需求，假如业务很简单，能用线框图或则文字即可说明清楚，这么就没必要吃力气去弄一个流程图了。

业务流程图：通常单个任务模块从0-1的时侯须要使用，帮助开发理解任务的每一个环节。一般会涉及到多个角色协作。反例见文末开发用需求文档。

逻辑流程图：单个任务或则单个环节涉及多重逻辑判定时使用，帮助开发梳理ifelse后的操作行为。假如单纯用文字描述这些逻辑判定，开发还没绕晕，产品自己可能就先绕晕了。

全局说明

在同一个系统内，在多个场景或则页面内需要使用到相同的组件或则交互，把这类组件/交互的需求说明归纳到全局说明内，在正文内出现时做相关引用即可。

【举个反例】

列表的排序规则，假如多个页面的列表排序规则都是一样，则在全局说明内新增一个版块对其进行详尽说明，而在正文的相关页面标明“排序规则请参照全局说明XXXX”即可。

又如系统管理后台，编辑页面的保存/取消功能，直接在全局说明内说明，点击保存/取消时会出现XXX提示，确认后系统的执行结果；虽然在实际页面中，保存/取消属于不同的内容编辑页面，但其交互几乎都是一致的，就没有必要在多个页面重复说明。假如遇见特例，与全局说明内的需求不一样，在对应的页面再另行说明。

构建全局说明蓝筹股，除了能在写需求文档是节约重复劳动的时间，并且在更改需求文档过程中也能省掉好多冗长的事，就如Axure中“母版”一样方便，改一处即把相关的地方都完成更改。

正文

就是每位页面的需求细节，包括线框图/高保真，逻辑说明和交互说明。

关于交互说明，通常大公司就会有专职的交互设计师并撰写交互文档，其他公司一般由产品总监和UI设计师一起承当交互设计。但无论是否有专职的交互设计师，我觉得作为一名产品总监，在需求文档内也要明晰强调部份交互说明，提供一个大方向给设计师工作，非常是对于系统的空白页或类空白页。

【举个反例】

前段时间在处理一个小功能：在非电话客服工作时间内，用户点击电话客服按键时，需弹出提示并引导用户在线留言。

以下是第一版和第二版设计的疗效：最终使用的是第二版。

因为当时需求内没有详尽说明交互意图，UI设计师被线框图欺骗，出了第一版本；我看了设计后不太满意，与UI设计师沟通看法后，最终更改为第二版并投入开发。

两个版本的信息内容是一样的，但因为信息优缺相反，因而这两个提示的功能也不一致。第一版注重于告诉用户“当前客服不在线”；第二版注重于引导用户在线留言。产品是要为用户提供解决方案，而不是把问题抛回给用户。

3.2商用文档

相对于开发用文档，商用文档几乎是面面俱到，尽善尽美，能摆到桌面上的需求文档，以下列举了两者的框架对比。

写商用文档无形中也会给产品总监降低特别大的工作量，因而可按公司要求和个人习惯结合去选择即可。

封面

每一份商业化文档，就会要求有一个封面，简单列举系统名称、文档名称、文档设计者（企业或则个人）、定稿时间即可。

目录

目录的细度，须要细致到哪级标题，按需设置即可。

概述

包括项目背景、项目介绍，用一两段话简略说明。

使用人群

给谁看就列明谁，如系统开发团队，相关行业设计师等。

需求剖析

主要写项目前期举办的督查和剖析而得出的推论，包括产品定位——项目核心用户群、市场竞争优势，和用户故事——用5W1H方式表明解决的痛点。

系统字典

对系统或则文档内的一些专业用词进行解释，或对同一事物进行命名规范。系统字典除了是一个项目内使用，甚至每位部门或每间公司都可以用相关概念，非常当团队刚才成立时，使用系统字典概念才能解决好多沟通上的误解。

【举个事例】

就如上文的“全局说明”，这儿用“全局”代指整个系统的概念。但实际，更多的公司/团队用“全域”来指代整个系统。但因为公司是旅集会业，“全域”一词是行业内的专有术语，而且也是公司的业务术语，假如用“全域”来表示整个系统，在沟通时往往会造成误会，为此公司内部都习惯使用“全局”来指代整个项目系统。

结语

以上便是从大框架层面介绍优秀的产品文档须要囊括的内容，后续将在系列（二）中，从需求文档——正文的角度介绍本人写产品文档的小方法和tips。整个系列均属作者本人的看法，欢迎交流。

另附样例作为参考：

开发用文档：

商用文档：（提取码：rqff）

（备注：商用文档为“当年”自学改行产品时的作业，相对孱弱，你们瞧瞧框架即可，何必较真哈）