产品设计-(5)需求文档

软件需求文档是软件项目由“概念化”阶段进入“图纸化阶段的最主要的一个文档。软件需求的描述应该包含：软件定位、目标市场、目标用户、竞争对手等概述内容。以及软件的结构、核心业务流程、具体用例描述、功能、内容描述等详述内容。

需求文档的主要使用对象：开发、测试、项目经理、交互设计师、运维及其他业务人员。开发可以根据需求文档获知整个软件的逻辑；测试可以根据需求文档建用例；项目经理可以根据需求文档拆分工作包，并分配开发人员；交互设计师可以通过需求文档来设计交互细节。需求文档是项目启动之前，必须要通过评审确定的最重要文档。

产品的概况

介绍项目的背景

介绍产品定位

那些人会用到本软件

项目可能涉及的角色

摘要：对于产品经理来说，撰写一份完整的产品需求文档往往需要花费很长时间，那么

如何提升产品需求文档的撰写效率呢？

对于产品经理来说，产品需求文档（PRD文档）是工作的核心产出。一份严谨、优秀的产品需求文档能够给项目的其他人员，包括设计师，开发工程师，测试工程师，运营人员等带来很大的帮助。但对于产品经理来说，撰写一份完整的产品需求文档往往需要花费相当多的时间和精力。

今天我们一起来看看，如何提升产品需求文档的撰写效率。

为什么要写产品需求文档?

对于稍微大一点的产品开发团队来说，产品经理未必能向所有团队成员准确传达产品开发需求，这时就需要一份完整的产品需求文档供项目参与人员阅读。

首先，产品经理可以根据项目的阶段运营目标提出合理需求，通过PRD文档阐述产品整体设计需求背景，设计思路，功能范围，交互逻辑，页面细节及其他信息。

其次，团队的相关人员可以快速获取自己需要的信息，节省反复沟通的时间成本，更好地开展工作。

最后，产品需求文档也是一个产品项目投入开发前的重要附件之一。团队领导可以根据产品需求文档清晰了解为什么需要开发这样一款产品。项目的其他相关方也可以随时参阅需求文档，了解项目的基本信息。

总的来说，产品需求文档有三个核心作用：

传达产品开发需求；

保证团队成员沟通顺畅；

制定产品质量控制标准。

产品需求文档的在项目中的重要性已经不言而喻。那么对于产品经理来说，有哪些技巧可以更好地完成产品需求文档的撰写呢？

产品需求文档包含哪些内容？

通过下图，我们可以简单了解产品需求文档需要呈现的基本内容。

请点击输入图片描述

1.产品概述

产品需求文档的第一部分，首先需要对整个项目的研发背景及整体规划进行说明，让阅读者可以快速理解需求背景和产品定位。其次是对产品需求文档本身进行阐述，在每一次修订后都需要进行记录，方便阅读者了解产品需求文档的修订更新。这一部分主要包括以下内容：

项目概述

词汇表

文档修订历史

版本说明等

2.功能范围

这一部分需结合用户、业务规则及市场环境，对产品的用户和市场需求进行分析梳理，找出差异性和优势，制定业务流程和需求清单。可通过业务逻辑图、流程图、产品结构图等图表，让产品逻辑和功能以最简单的方式陈列出来，团队成员可根据这一部分了解用户信息、行为信息等，也有助于对产品进行进一步的理解。

3.功能详情和原型

首先是列举功能总表，将产品功能进行逐条梳理，每一条功能都能对应前面的产品目标。

其次是功能详情展示，通过Mockplus等原型工具快速绘制原型，配合关键部分的批注说明，详细描述业务模块的展示、交互和数据逻辑，以供开发人员查看和理解。

4.全局说明

这一部分包括设计规范、数据统计、通用规则说明等信息，方便设计师和开发人员查看产品细节信息。

5. 测试需求

产品一般在正式上线前都有BETA版本或者内测版本，产品经理需要定制测试产品的功能或者性能。

6.非功能性需求

非功能需求为用户常规操作产品时的极端情况，涉及很多内容，包括产品性能、安全性、可靠性、拓展性等方面。

7. 产品运营和市场分析

完成产品开发并不是终点，产品的最终目的是要赢得市场。产品上线后如何运营？建议的推广策略是什么？产品经理和运营人员该如何协作？等等问题。

产品需求文档撰写技巧

如何高效完成产品需求文档的撰写？我们可以从以下四个方面展开说明：

理清文档结构

详尽叙述每一个细节

语义明确，没有歧义

搭配原型图或设计稿进行说明

1.理清文档结构

一份产品需求文档的内容往往多而复杂，因此，产品经理在撰写产品需求文档时，必须理清文档的结构，才能提升产品需求文档的可读性，让阅读者可以快速了解文档的思路和查阅重要信息。

将一份产品需求文档看做一个产品，首先需要梳理出它的结构，如上文中所呈现的文档内容，然后再按顺序进行撰写，这样才能写出结构清晰，层次分明的产品需求文档。

2.详尽叙述每一个细节

当我们站在产品经理的角度思考问题时，往往会出现这样的误区：产品的这一功能模块逻辑非常简单，业内常见，开发人员也一定能懂，不用再进行单独说明。

产品经理对于产品的功能及逻辑往往非常了解，但如果从开发或测试人员的角度来看，往往对于许多产品的细节和逻辑关系都不太了解。因此产品经理在撰写产品需求文档时，一定要做到事无巨细。不仅需要详尽叙述页面逻辑、交互逻辑、数据逻辑等所有细节，还需要从开发、测试等角度检查是否有遗漏或错误，才能保证后续开发工作有条不紊。

3.语义明确，没有歧义

在撰写产品需求文档时，要做到语义明确，不能出现让阅读者产生歧义的词汇或语句，如：大概、可能、似乎等词语。另一方面，对于产品定义的表述方式，必须做到全文统一。比如在撰写一份APP的产品需求文档时，前文写了“首页轮播图”，后文就不能再使用“首页Banner”、“横幅”等名称。

4.搭配原型图或设计稿进行说明

产品需求文档往往包含大量文字描述，团队其他成员在阅读某些功能细节时，往往无法完全理解文字内容。此时如果使用原型图或设计稿进行说明，就可以补充文字内容很难描述的信息，帮助阅读者快速理解产品功能和内在逻辑。因此产品经理在撰写产品需求文档时，需要配合原型图或设计稿进行说明。

一款产品的原型图或设计稿通常会进行反复修改，产品需求文档必须同步更新，才能让阅读者及时了解到项目的最新动态。但如果每修改一次原型图或设计稿，产品经理都必须手动去替换文档中的配图内容，那效率就太低了！其实，使用高效的产品需求文档撰写神器即可解决这一难题。

产品需求文档撰写神器

随着产品开发流程的不断发展，Office等传统办公软件已无法满足产品文档的撰写需求。今天为大家推荐的，是一款专门面向产品经理的文档工具——摹客：网页链接。除了上述图文同步的难题外，摹客还能解决审阅沟通、版本管理等产品需求文档的写作困境，让产品经理可以更高效地创建专业的产品文档。一起来看看~

1.富文本撰写，充分表达产品需求

摹客全新的富文本在线写作模式，符合产品经理日常编辑习惯，可以快速完成文档撰写。撰写内容自动保存，可随时查看历史版本，方便对比修改。此外，产品经理也可以直接上传本地产品文档，会自动解析目录，并生成文档树，方便查阅。

请点击输入图片描述

2.与原型图、设计稿深度结合，相互说明论证

产品经理在撰写产品需求文档时可插入设计稿，当对设计稿进行了更新修改，可在文档中设置内容同步，无需重复插入。另外，团队成员在设计稿上打点评论时，也可以引用文档进行说明，让团队成员可以一目了然地查看相关信息。

请点击输入图片描述

3.实时审阅，高效沟通

文档编辑完成后可以通过链接一键分享给团队成员，团队成员可选中文字增加评论，对文档进行在线审阅，清晰表达项目意见，实现产品开发团队的高效沟通。

请点击输入图片描述

4.追踪修改记录，备份历史版本

通常，产品需求文档的写作不会一步到位，往往会根据团队成员的评审意见进行反复修改，因此会产生大量的迭代版本，对于产品经理来说，如何管理产品需求文档的历史版本，是一个很大的难题。在摹客

撰写产品文档，每一次修改都可以自动生成历史版本，可以随时跳转查看和恢复，管理便捷。

请点击输入图片描述

5.在线预览、分享更便捷

在摹客中在线撰写或上传的产品需求文档，可通过链接快速分享给团队成员，团队成员获得链接后可自由查看，当产品需求文档有修改时，团队成员仍可通过链接查看最新版本。

请点击输入图片描述

使用摹客等高效便捷的产品文档撰写工具，可以简化产品文档撰写流程，提升产品经理的文档撰写能力，让产品经理事半功倍。

总结

产品需求文档作为产品开发团队的重要沟通文档，文档的质量好坏会直接影响到各部门是否能够明确产品的功能和逻辑。一份简洁易懂、逻辑清晰的产品需求文档，可以让团队沟通更加高效，从而有效提高产品开发团队的工作效率。

首先告诉你产品需求文档肯定是有的！一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板，肯定是已经吸收了各类人的偏好、意见，固化了很多符合实际业务必须的内容要求，能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式，可以让你在编辑文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础，减少额外的沟通成本，提高效率。

不过，在享受别人智力和经验梳理好的模板进行需求编写的同时，还是应该了解模板形成的原因，并在此过程中形成自己对于模板的理解，进而形成对于产品需求文档的理解，在理解中使用，裁剪和优化。

要理解和分析模板，理解和分析产品需求文档，可以运用以下几个方法：

一、描述-解释-预测-监控

描述，是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异，其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉，以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。

解释，是回答 “为什么”，是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机，内容中各部分之间的相关，依存、依赖和影响关系等进行说明，以便对于描述内容有更清晰、更细致、全面的了解。

预测，根据以因果关系为内容的内在联系，相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系，准确地表达内在联系，从中推导出正确的预测。

监控，是对于预测行为、现象的观察和监督，包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生，以及因此而采取的对应的反映动作；这些反映动作是预测过程中根据内在联系制定的“响应”机制，并任其自然发生或者通过提供“系统”的自制能力来实现。

二、需求准备、编写和检查

回归到产品经理的日常工作中，在时间占比上较为集中的就是产品需求管理了，包括了需求的准备、分析、编写和检查过程。在这个过程中，描述——解释——预测——监控这个通用的科学分析过程也同样使用，且可以贯穿其中，并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。

1. 描述

描述的过程是客观的进行“需求向”描述的过程，是一个“背景”信息的补充，用来说明，这个需求文档的源出是什么，是针对什么问题，这个问题是在具体什么领域，在怎样的范围内，涉及到的是那些人；在需求相应的功能设计实现之前，当前的解决方案存在的问题是什么，参与者是怎么解决的，解决的情况怎么样，是好，还是不好，还是勉强可以，对于新的需求的紧迫性是什么样的。此外，描述的过程还需提供一个基础的概念和流程的解释，用来统一作为背景去理解一个现实的业务场景和“沟通字典”，避免在沟通中因为误解而产生不必要的偏差。

需求准备的过程：了解需求来源（管理部门、市场部门、运营部门等），需求背景（行业、同业规则现状等）；

需求分析的过程：了解需求目标、预期效果（时间、结果等）、使用者习惯、相关人影响；

需求编写的过程：描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围；

需求检查的过程：需求的背景、目标、过程、干系人、结果预测和预防的完整性检查；

2. 解释

解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题，同时还加入了“是什么”和“怎么样”的部分。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题，这个新的解决方法需要要做什么，对于原有的业务过程有哪些改变，会提升什么，会降低什么，会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分，是需求文档的最主要、最核心的内容部分，也是在内容上占比最大的一部分。

这里的解释根据产品需求面向的要解决的问题不同，而可能存在多个层面，多个维度的层面，比如对于运营的影响，对于前端市场的影响，对于用户的影响，对于财务、法务的影响；从技术开发、技术实现维度，比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响，还可能涉及到对于运维资源的影响等；因此对应到实际的产品需求工作中：

需求准备的过程：了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑；了解面向的内外部用户的产品使用水平、学习能力和使用习惯；

需求分析的过程：选择和制定最有效的，满足时间、资源投入等要求的方案；

需求编写的过程：详细描述需求的业务流程，通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品，产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出；每个业务节点明确的输出物和节点标志，重要性和优先级；系统架构、干系人角色和影响范围；

需求检查的过程：需求的流程、用户交互动作、系统信息交互等完整性检查；

3. 预测与监控

预测与监控在产品需求文档的管理上是联动的，是对于预测的事件发生的时候，进行管理的机制，监控=预测+干预。在产品需求文档的管理上，对于设计好的业务流程、使用功能，在实际过程中可能会出现这样或者那样的 “非规划”的使用，也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品，而且，往往相反。”因此，这部分内容很大的比例需要来对于用户的行为进行预测和监控，并提供“预防”或者“解决”方案。其中：

预防在于，预测产品的用户在使用的过程中，可能会进行的一些超过产品使用半径的操作，一旦进行这些操作，操作的任务流程会中断，掉出，进入其他业务流程中且无法回滚，从而使得操作无法进行下去，功能使用失败，使用者会感觉产品、功能没有包容性，缺乏引导性，导致了最后操作的失败，预想的结果没有实现，而且造成了一定的挫败感，甚至造成了一定的损失。预防的具体方法多采用导航、提示等，不同的系统都有各自标准化的控价，我们在这里不做展开。

解决在于，预测产品的用户在使用产品的过程中，因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下，需要提供额外的流程和控制来“回转”用户的操作，来帮助用户回到预先设定和他所需要的流程上来。解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中：

需求准备的过程：了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度；

需求分析的过程：选择和确定需求实现方案，评估行为管理方式和管理机制；

需求编写的过程：详细描述需求的业务流程和交互过程中可能出现的用户异常操作，相应异常操作中系统反应，系统对应的控制和引导；

需求检查的过程：需求“异常”流程和相应引导、控制地完整性检查；

在需求管理的过程中，就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤，是需求文档内容的组成部分，也是需求编写完成之后的检查。

四个模块构成了需求文档的完整性，且同时有各自独立，有对应的说明，引导、要求和标准。所谓标准文档，就可以按照这四个模块作为框架、内容和格式。

写在最后

产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体，我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认，并最终达成多方理解和共识的产品需求文档，能够最大限度的还原产品、功能的设计，保证产品、功能的实现，最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。

1、初步沟通

这个是最为重要的一步，双方都在选择，有的公司会为此专门抽人出来做这一步。我个人认为专业和效率是第一步的关键词，而不是什么价格、关系等，没有专业，都是空谈。

2、前期准备

这一步最重要的是签合同。没有合同绝对不要开始设计，那样的设计是没有价值的，客户也不会把你放在眼里。因此我认为原则是关键词，价格和首期款甚至都可以谈，但款是一定要先收的。

3、设计阶段

执行是这一步的重点，所有的工作都必须为此事提前和优先进行，服务时间上要占得主动。

4、后期执行

主要是结款，前面的步骤进行的流畅，后面的款就好收。如果涉及到制作的话，则需要双方配合和协调。

以下是具体流程说明：

（其中涉及到标准的7个表格）

一、初步沟通

充分了解客户需求客户可以先在企业自身内部形成统一的意见，明确需要设计的项目、设计的要求和项目预算，指定项目的负责人，协调好相关的资料收集工作。

对企业背景、产品背景、目标市场环境、竞争企业和竞争产品进行初步分析客户可以利用自身的行业优势，向广告公司提供尽可能多的背景资料，以便于广告公司对设计项目进行系统的专业分析。

向客户介绍此类项目的常见设计风格以供参考广告公司可以向客户提供项目相关的实际案例以便于客户进行风格和形式的筛选。

了解客户预算以便在设计时采用适当的印刷工艺和材质预算的多少对设计方案最终是否能够顺利执行有很大的影响，好的方案如果没有预算的支持，只会浪费双方的时间和精力，所以应尽可能在项目开始前就确定好大致的预算。

提出初步的设计解决方案在与客户充分的沟通后，根据掌握的资料，经过内部分析，向客户提出初步的解决方案即设计简报1，并取得客户的认可。

二、前期准备

根据设计的要求、数量和难度，向客户提出报价

设计费根据不同的要求和难度，价格有所不同，通常由广告公司提供整合解决方案时(如由广告公司同时承接前期设计和后期制作执行)设计费可以有一定的浮动空间。