超详细！一份涨薪 3 倍的需求文档撰写指南

扫一扫
官方手机版

扫一扫
AI创作程序

扫一扫
木子公众号

扫一扫
AI公众号

初学的产品小白，你是否对产品经理的相关工作毫无概念，不知道别人常说的 PRD、需求文档是什么而苦恼？

还想要一个模版，学习和动手模仿一份，期待面试加分？

又或者你是一名已入职的初级产品经理，由于自学或培训入行，没有系统的产品知识，撰写的需求文档逻辑混乱、毫无头绪，还常常给领导各种挑剔、开发各种怒怼呢？

到底什么是产品口中的需求文档？什么样的文档才算是优秀的 PRD，构思时需要抓住哪些重点进行撰写？

作为资深的产品老油条，文档撰写 300+ 起，版本迭代更是数不胜数。写个 PRD 就和喝水那么简单，我想我可以分享一些经验给你~

更多文档撰写指南：

B端的交互文档如何写？这篇保姆级教程收藏起来！

今天要分享的，是后台和社群里几乎每天都有人问的交互文档该怎么写的问题。

什么是需求文档

需求文档（Product Requirement Document）作为产品经理的必学基础技能，主要是用来承载当前版本的需求背景、产品方案、原型界面等内容的产品说明文档。

我常用的需求文档模版，一般由产品概览、产品结构、UML 相关、流程梳理、文档相关、消息推送、原型界面、功能交互、废纸篓等 9 个部分组成。

接下来，我们就对这些内容展开聊聊。

一、产品概览

产品概览，主要包含了版本封面、版本日志、版本背景、更新内容等 4 个模块。

1. 版本封面

版本封面在需求文档的第一页，用于展示“项目名称、版本编号、版本开发时间、版本发布时间、版本相关负责人”等相关内容。

你说这封面有什么用？一般是用来装 B 的，显得文档规范高大上，提升团队成员参与感~

2. 版本日志

撰写版本日志，主要是为了让相关需求方了解版本的迭代过程，以及帮助其了解版本的更新内容。

所以版本日志的撰写需要通俗易懂，避免通过系统视角，对更新内容进行生硬的描述。

（悄悄告诉你~现在为了偷懒，都用 ChatGPT 自动生成版本日志了，还别说效果真的顶！）

版本日志还有一个作用是，你可以翻看之前的迭代内容，为数据分析提供依据。

3. 版本背景

版本背景可以说是文档的说明书，它明确告知了读者当前版本的开发目的和必要性。

版本背景的内容，一般包含“版本背景、版本目标、需求说明、相关功能”等几个部分。

什么情况可以不写？

1. 你领导；
2. 懒得写。

4. 更新内容

更新内容一般是给相关开发人员看的。主要指出当前版本的关联需求有哪些，让前后端知道开发范围。

你说版本迭代那么快，每次都要写更新内容，太麻烦了不写行不行？

当然可以，只要你能忍受这些：

1. 开发阶段前后端同事轮番轰炸你微信，问你这次开发内容是啥；
2. 当你打开尘封已久的文档，由于不清楚当时迭代了什么，又因为涉及内容太多，而要梳理相关规则时，一脸懵逼生无可恋，简直无从下手。

二、产品架构

产品架构分为了产品结构、功能结构、页面结构等三个部分。

1. 产品结构：主要呈现一个产品或系统的模块分布；
2. 功能结构：以一个功能或模块为主题，展示该功能的组成；
3. 页面结构：描述一个版本的相关页面及页面之间的从属关系。

说实话，由于团队版本迭代的节奏较快，我基本上文档内已经很少附上这些内容了。

除非是在进行新系统设计、年度规划、系统重构等情况时，我才会花点时间构思产品结构。

所以，你可以视实际情况，考虑删减部分。

三、UML 相关

UML 的模块包含了类图、用例、状态图、活动图、时序图，我一般用的比较多的是类图和状态图。

1. 类图：主要用来呈现不同对象、对象之间关系的一种模型；
2. 状态图：描述一个对象在周期内，相关状态及其变更条件的过程。例如一个电商订单从待付款到已付款的变化。

有童鞋就问了，UML 是啥东西听都没听过，是不是和技术相关阿？那技术的东西我又不是开发，学来干啥？

UML 是一门图形语言，它代表了面向对象的思想，我曾经就踩过不懂 UML 的坑，说多了那都是泪。

感兴趣可以看：《3 本进阶产品必备书籍，带你快速入门 UML 建模》。

四、流程梳理

该模块主要针对于“业务、功能、页面”等相关流程进行系统梳理。

1. 业务流程：一般描述某业务涉及的各个角色、规则和环节等关系，帮助产品深入思考业务场景；
2. 功能流程：研究主体为一般为某个功能，并梳理出该功能涉及的相关系统条件和流程变化等；
3. 页面流程：指的是作为用户进行某些操作时，相关的页面跳转过程。

作为初级产品，入门时一般会进行功能级的设计（例如一个动态发布功能），这时候需要你掌握“功能流程图、页面流程图”的基础绘制，辅助理清设计过程中将遇到的各类问题。

当积累了不少功能设计经验后，你可能会接到一些业务优化的需求，而业务优化的前提是完全理解业务场景。

通过针对某个具体业务，绘制相关的业务流程图，便能帮你搞清楚业务难题和优化方向，从而辅助相关功能设计落地。

五、文档相关

文档相关模块，用来存放一些概念说明、数据相关等内容。

具体有“版本排期、名词解释、角色权限、全局说明、数据实例、数据埋点”等。

1. 版本排期：当一个业务需求较复杂时，我们会将功能模块拆分为多个版本，此时就要进行多版本排期，以供需求方参考；
2. 名词解释：对系统、业务名词进行解释，帮助读者快速了解、掌握相关概念知识；
3. 角色权限：定义不同角色在系统中的操作权限；
4. 全局说明：对系统的设计规范、规则要求进行统一说明，确保相关人员理解；
5. 数据实例：针对某些数据表，进行数据模拟，提升读者对相关功能的进一步理解；一般涉及数据创建的需求，也可以在该模块说明，用作部分功能的自定义配置；
6. 数据埋点：如版本涉及数据跟踪和数据埋点要求，可在此进行补充。

这个模块的内容，可视具体情况酌情删减。

并非每个版本文档都需要这么细的规则说明，有些小版本仅需“全局说明”就够了。

六、消息推送

消息推送的类型主要有：短信、邮件、APP 推送、订阅消息、模板消息等。

消息推送主要告知开发，当前版本涉及的消息内容、消息规则，及其他推送的注意事项。

有些时候对旧推送改版的时候，作为产品文档的撰写人也会回顾，以便于进行规则迭代。

试想下，如果你手上负责的系统，当前的推送规则包含了好几百条，而又没有相应的文档留存写明推送规则，这时你该提桶跑路呢还是提桶跑路呢？

所以，建议你有精力的话可以做个消息推送的总文档，以便应对上述场景发生。

七、原型界面

原型分为高保真原型和低保真原型，如果不需要演示给客户看，我建议你为了工作效率（偷个懒不过分吧~），绘制低保真原型就可以了。

一些常用的原型界面有：异常页、结果页、对话框、原型页。

1. 异常页：用于存放部分页面的异常状态，例如“搜索商品为空、订单列表为空”等；
2. 结果页：当用户完成某项操作后，展示的操作结果页面，例如“订单交易完成”；
3. 对话框：将当前版本的所有对话框提示，单独存放在一个“对话框”页，以便开发便捷查询；
4. 原型页：指具体的版本功能涉及页面。

八、功能交互

功能交互模块，一般撰写版本迭代中，涉及相关功能的交互规则。

例如”用户注册“的功能流程，就可以用”用户注册交互“的单独页面进行撰写。

交互一般可分为动态交互和静态交互。

动态交互，顾名思义即包含了自动化或触发式的一系列变化的交互效果。

而静态交互，是指将这种动态交互效果，通过一张张页面、组件铺开组成的交互流程图。

有些人就要问了，为什么要用静态交互呢，使用动态交互不是更酷炫吗？

沟通的本质，是减少信息差。——好夕雷

文档本质是一种沟通方式，需要方便开发查阅和理解。

如果使用动态交互，一个稍微复杂的交互效果，做的人效率低不说，查阅的开发同事，要重复点击多少次，才能完全理解其中的逻辑，换我也崩溃~

所以，使开发一目了然、快速抓住交互重点才是文档的核心，那么静态交互在这种情况，就成了最优解。

九、废纸篓

废纸篓，顾名思义就是放一些已废弃、暂时不用的文档内容。

一个版本文档内，一般涉及到新逻辑变更，我的习惯是顺手复制一份放入废纸篓，兴许变更内容不理想，还可以从废纸篓中恢复当前文档内容。

总结

需求文档作为产品的基础能力，本质是一种沟通工具。

它主要用来承载产品方案、原型界面等内容，一般有 9 个部分：产品概览、产品架构、UML 相关、流程梳理、文档相关、消息推送、原型界面、功能交互、废纸篓等。

每个模块都有特定的作用，撰写时要注意规范性、易读性，前后端查阅时，才不至于怼你太狠~

随手点个赞，谢谢你喜欢~