编辑导语：需求文档的撰写在一定程度上可以帮助产品经理理清思路，推动业务项目的更快推进。然而不同场景下，需求文档的撰写往往需要针对工作中的复杂情况进行调整。本篇文章里，作者总结了几种常见工作场景中需求文档的编写技巧，一起来看一下。

在现实的PRD编写工作中，相信很多同学都有各种各样的问题。比如：时间不够用、完善度不高、历史设计文档找不到、没有一份文档能完整描述线上产品、文档太大编辑卡、页面太多开发无法快速找到更新内容……

而无论是网上的文章，还是线下的培训班，大多数都是教大家如何写一份完整细致的需求文档，但这样的文档是无法应对工作中复杂情况的。

想要解决现实中的各种问题，需要根据不同的场景制定不同的文档编写策略和技巧，本文梳理了7种工作中常见的场景及相应的文档编写技巧供大家参考。

一、场景1：从0开始/大功能改版/增加大功能模块

解决方案：word类型PRD+原型设计文档（重功能、流程和规则，弱视觉和交互）。

场景特点：功能性内容较多，重点在于介绍功能的结构、描述、逻辑和规则。所以通过word文档的纯文本内容用以描述功能，能让开发人员快速了解众多功能。

用户场景流程图可以在Axure中绘制，功能结构图可以通过脑图工具绘制（Xmind/MindManager等）后导出成图片放到原型文档中，详细的功能设计和规则通过Axure绘制原型表达。

这个阶段的设计应该弱化视觉和交互层面的设计，尽可能的减少视觉交互规则，将重心放到功能上，当功能满足需求上线后再逐步优化视觉交互。以下图片仅供提供思路，需要完整模板请留言：

二、场景2：小版本迭代

解决方案：原型设计文档（带功能需求描述+跳转）。

场景特点：需求相对较少，往往是针对某一个小点的优化，大多是在原有功能基础上修改，或增加很小的功能内容，所以不需要长篇大论，直接用Axure绘制原型文档注明修改部分，并在首页写上版本号和时间，以及相关的功能需求描述，加上页面跳转链接即可。

三、场景3：历史设计文档丢失或不全面的情况小改版/没有产品储备的项目投标

解决方案：原型设计文档（功能需求描述+截图修改、注释）。

场景特点：在历史文档不完善的情况下，需要一边对照线上系统，一边对照历史文档，进行编辑修改，费时费力，所以只需要截取线上产品图片，在此基础上修改说明即可。版本和需求描述参考场景2中的需求列表即可，如果是大改版，还是建议重新画原型吧。

对于没有产品储备的项目投标，招标文件基本都有大致的功能需求描述的，相当于命题作文，投标文件中也会详细介绍功能，所以没必要再额外写word类型的产品需求文档，需要的是快速输出demo演示方案，只需要截图修改即可。

四、场景4：体验优化迭代

解决方案：原型设计文档（重视觉交互规则描述）。

场景特点：功能层面没有改动需求，不需要功能描述，重点在于交互视觉的规则描述，仅仅需要在原型文档上结合界面详细的编写即可。故提供一种逻辑梳理框架，供大家系统性的梳理规则思路。

1. 信息&限制：描述区域内所包含的字段，以及各个字段的限制规则，例如必填、长度、字符限制等。
2. 操作：描述区域内所支持的操作行为，例如单击、向左滑动、向上滑动等，并描述操作后的反馈。
3. 状态：描述区域内包含几种状态，每种状态是如何触发的。
4. 排序：描述区域内内容的排序规则如何， 例如按时间倒序等。

五、场景5：公司有现成的模块或组件/或对接别人公司的产品

解决方案：原型设计文档（重点描述对接规则）。

场景特点：不需要过度关注各自产品内部功能的规则，重点在于描述对接部分的逻辑和数据规则。

六、场景6：完整版设计文档

解决方案：word类型PRD+功能结构图+用户场景流程图+原型设计文档（整合各个版本的设计文档，附加版本迭代记录）。

场景特点：主要用于文件归档，便于后续入职人员，能够快速对产品有整体详细的认知。“word类型PRD+功能结构图+用户场景流程图”这3块就不重复了，前面有。主要是原型设计文档如下图：

七、场景7：客户演示原型Demo

解决方案：原型设计文档（重高保真和主流程的交互）。

场景特点：主要用于客户或给领导演示系统效果，在不调用研发资源的情况下最低成本的演示产品效果，重在视觉和交互的动态编辑，而不是规则编写。

高保真原型就不多赘述了，网上一搜一大堆。只要会用Axure绘制交互效果，并把主要图片和文本内容换成贴近主题的即可。

八、总结

想要又快又好地完成产品设计工作，就需要针对各种场景，具体问题具体分析，没有任何一款PRD是可以同时满足所有场景需求的，希望本文能对大家有所帮助。

如果你也有遇到过这些问题，或有更好的方案，欢迎留言~

本文由 @无疑路 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。