PRD All in One

PRD = Product Requirement Document，是产品经理和开发人员之间沟通的桥梁，对于产品开发至关重要。它详细描述了产品的功能需求、用户体验要求和技术规范，确保开发团队能够准确理解并实现产品目标。

PRD 并没有统一的模板，每个人、每家公司、甚至每个项目编写方式都不一样，比如，一个产品里有单个业务流程和有多个业务流程是不一样的，只有一个核心业务流程的产品，只需要站在全局的角度来思考文档应该怎么写，怎么呈现；但是在 toB 和 toG 产品中，一个系统里往往存在多个业务，那就需要我们考虑每个业务流程的文档编写、设计思考，比只有单个业务流程的产品要复杂的多。我面向的是 toG 的业务，做的产品大部分都是具有多个业务流程，总结一下个人在被过多个项目折磨后所总结的编写思路，主要分为两部分：

1. 独立的文档：
编写一份独立的 PRD 文档，通常是面向整个团队的，包括更重要的是面向领导、客户，也是为自己打下后面设计基础。开发人员、设计师、测试人员则需要看更加详细的信息。

2. 与原型结合的文档：
主要是对交互、数据流等详细的描述，可以更直观地展示需求，便于开发团队理解和实现。

先说结论：如果公司没有特别要求，或条件不允许，只能写一份文档的话，个人更偏向于写在原型旁边，首先这样做更直观，更容易被开发团队理解；其次，其他比如数据需求、非功能性需求等也可以写在原型上，更贴近产品的真实情况，也不用在原型和文档之间来回切换。

独立文档

个人猜测，大部分公司的团队是不看这类文档的，因为这类文档往往是以纯文本方式编写，大部分人不没有仔细阅读的习惯；开发团队也需要在文档和原型之间来回切换，可能增加理解和沟通的成本；文字描述有时不如图形和交互原型直观，可能导致误解。

但是此类文档在某些程度上也是重要的，因为他可以向售前提供概要设计说明书、需求规格说明书、详细设计方案等一部分内容。

我的理解，此类文档以简为主，无需写的特别详细，尤其是在功能部分，只需要把功能框架以及功能简述写上即可，写好后可以跟项目负责人、技术负责人、甚至客户等提前过一下，让他们了解你的想法和设计思路，并提出意见。这样可以快速迭代更新文档。为后面的详细设计提供框架和思路，保证路不会走偏。也就是说，这个时候还不是真正面对开发的时候，而是为后面设计和开发打下的基础。

基于以上思路，我们来理一下这份文档应该包括哪些内容：

概述

此处明确产品名称；版本号及更新记录；介绍项目背景和目标；用户或用户群体的痛点和期望。

主要是自己或领导看，研发一般不看或就瞄一眼。

目标和范围

确定产品的主要目标和预期结果，界定产品的范围和功能边界，明确哪些功能包含在当前版本中，哪些功能会在将来版本中实现。

这个一定要做好规划，如果公司有项目经理，则一般项目经理会做好产品开发计划。从商业角度看，产品的规划决定着公司的竞争力，对于公司长期的盈利起着重要的作用。对于开发来说，产品的长期规划决定着他们用什么技术开发，以及会给以后的功能留一些空间，否则甚至会面临重构的风险。

项目风险

描述项目当前或未来可能存在的风险，风险可能一开始就有，也可能在进行中出现。

看实际情况填写，主要是给领导看，不过领导一般不看文档，有风险的话应该直接向领导汇报。

功能需求

列出产品的核心功能和特性，可以用思维导图方式呈现，更多的使用目录形式展示，可以直观的看出产品的整体架构和功能模块。此处不要过多描述，只要列出功能名称、功能描述、功能优先级等即可。

整篇文档的核心部分。此处定下了产品的基调，里面有什么功能，决定了产品的基本架构。

技术需求

技术栈、集成要求、数据库设计、服务器配置、安全性要求、性能要求等。

一般来说，产品经理无需关注，技术需求是开发团队的重点。

约束和假设

列出产品开发过程中可能遇到的时间、预算、资源等限制。

一般是由产品或项目负责人来写，如果产品经理自己是负责人的话，则可以提出基于当前已知信息的假设。

原型文档

这里就要描述的非常详细，包括交互设计、交互说明、数据流设计、业务流程设计、界面设计、功能模块设计等等。每个页面的说明、每个字段的义、每个按钮的功能，都要详细地写清楚，很多产品和开发的矛盾就起源于此，不把这里描述清楚，开发就不知道怎么做或者做错，如果不同的模块有交互或数据的关联，很可能牵一发动全身，会耽误研发进度，导致交付延误等严重问题。很多产品经理就是偷懒、省事，只保留在自己脑子里，以为研发也会考虑到，但其实研发是以实现的角度来考虑问题的，产品则是以交互和用户的角度来考虑问题的，很多地方理解的不一样。如果说产品没有在这里描述清楚，那么乖乖站好，有错就要认，挨骂要立正。

我们来看下应该有哪些内容，并逐步分析：

全局交互说明

对于整个产品通用的交互流程、规则等信息进行前置说明，方便统一管理，我一般是在原型最开始新建一个页面，然后将其描述出来。

导航：包括主导航栏、侧边栏、面包屑等，每个导航都需要描述包括但不限于名称、位置、功能、跳转链接等。
搜索栏：搜索栏的功能、位置、输入提示、交互方式等。
缺省页描述与设计
加载状态：全局加载、局部加载，均需在相应的位置显示加载动画
操作反馈：包括成功提示（页面顶部或操作按钮旁显示绿色成功提示）、错误提示（显示红色错误提示，并附上错误原因）、警告提示（操作有风险或不完整时，显示黄色警告提示）
对于移动端或带触控的设备：需要加上手势操作说明，比如下拉、滑动、点击、长按等。

页面描述

对于每个页面的功能进行详细描述。可以在原型图的旁边添加文字说明，或者在原型工具中嵌入注释。包括如何进入、大体功能、页面权限等。并且以下需要编写的文档，均是在某个页面或某个功能下完成的。

权限说明

列表的权限，包括查看权限、数据权限、操作权限等，如果有特殊权限，则说明。权限一般在角色中配置。权限类可查看文章 🔗一文看懂权限管理

UML 图

对于有业务流程的产品或者功能模块，可以用 UML 图来描述业务流程，下面是经常用到的 UML 图

流程图：描述业务流程，包括各个环节的角色、任务、条件、交互等
状态机：对于有各种状态的流程，可以用状态机来描述状态的变化
类图：描述类之间的关系，包括继承、关联、依赖等

具体的概念和用法，请查看 🔗 UML 入门指南

ER 建模

对于有复杂的关系设计，可以用 ER 建模的方式来描述，包括实体、属性、关系、主键等。体现了实体、属性以及实体间的联系，以图形化方式抽象出业务的核心特征；对开发人员来说，实体关系图显示数据库中的实体（表）以及该数据库中的表之间的关系，奠定了整个系统的框架基础。

了解 ER 建模的概念和用法，请查看 🔗 ER 建模入门指南

筛选框字段及交互

筛选框一般有 Select、Date / Time、Search 三种类型，也有 Checkbox、Radio 等不常用形式。查询条件一般会跟列表字段相呼应，有些会把筛选条件放在列表头部，下面是具体的描述：

Search：描述搜索的范围有哪些，包括从哪里取值等
Select：描述下拉框的选项，包括选项的名称、值等，是否可多选，是否可搜索等，是否有默认值
Date / Time：这种一般涉及到范围选择，需要说明范围有多大，比如往前最远能选到什么时候，往后最远能选到什么时候，是否有默认值等
查询：一般有查询和重置两个按钮，查询和重置按钮分别触发的事件是什么。也有一种情况，就是没有查询按钮，那么在搜索框中可以直接按回车键触发搜索，以及在下拉选择后立即查询
高级查询：如果查询条件很多，可以把不常用的查询隐藏在高级查询里，只显示常用的查询条件

列表字段及说明

默认排序方式：一般是按照创建时间、更新时间、重要性等排序，如果有默认排序，则说明默认排序的字段
每页默认展示数据量，比如 10 条、20 条、50 条等
列表中每个字段的数据类型
每个字段的数据从哪里取值，数据来源是哪里
对于 Date / Time 类型字段，需要说明日期格式、是否展示到秒等，这种一般在原型体现即可
对于 Textarea 类型字段，需要说明当文本超过最大宽度后，是否自动换行，最多显示多少行，是鼠标悬停时显示完整内容，还是点击弹窗展示完整内容
对于图片、文件等可点击的字段，需要说明打开方式，比如是在线预览、还是下载等
如果是超链接，需要说明链接打开方式，比如新页面打开、当前页面打开等

详细的表格设计，大家可以查看 🔗 Table 表格，比详细中的复杂

按钮的含义和交互

点击不同的按钮，或者其他可点击的事件，会触发不同的事件，比如提交表单、删除数据、修改数据、跳转等，都要详细说明。比如，点击提交按钮，会触发表单验证，如果验证通过，则提交表单，如果验证不通过，则提示错误信息，并禁止提交。

不同状态下的交互

对于会根据实际情况变化的字段，比如状态，需要详细说明变化的规则，比如状态为“已完成”的任务，需要在哪些情况下会变成“已完成”，变成“已完成”后会触发什么事件，像弹出提示、按钮操作权限等

新建表单说明

需要详细描述表单的每个字段，包括字段名称、字段类型、字段说明、是否必填、默认值、选项、最大长度、是否支持换行等

每个字段都要描述是否必填，可在原型上体现
每个字段都要描述字段类型，是 Input、Select、Textarea、Number、Date 等
对于日期、时间等字段，需要说明日期格式、是否展示到秒等，以及是否有选择范围，比如只能选择今天之前的日期等
对于 Input / Textarea 类型字段，需要说明支持的最大字数
是否需要校验：对于需要校验的字段，需要说明校验规则，且在用户输入错误时需要提示用户错误信息，一般用在邮箱格式、手机号、身份证号等
对于 Select 类型字段，需要说明选项的名称、值等，若值有来源，需要说明是从哪里获取数据
Number 类型字段，需要说明最大值、最小值、精度等，并考虑是否需要将范围说明提现在原型上
如果表单在新建过程中被中断，比如新建过程中返回到上一页，是否需要保存已填写的内容。甚至断电、系统崩溃这种极端情况，是否需要保存已填写的内容。（极端情况一般情况下不做考虑）
Upload 类型字段，需要说明上传文件类型、大小限制、上传数量限制
其他更多的字段类型，比如颜色选择、Switch 开关、单选/多选框、滑动输入条等，都需要详细说明

非功能需求

如果有非功能性需求，比如性能、可用性、可靠性、可扩展性、可维护性、安全性等，都需要说明。比如，产品的可用性要求是 99.99%，那么就需要考虑到服务的高可用、服务的容灾、服务的监控、服务的降级等。这个一般写的不多，除非有特殊的需求。

数据需求

包括数据模型、数据结构设计、库表字段等，这种产品经理一般不写，都是后端开发人员来做。

第三方服务

涉及的外部 API 或服务，需要描述清楚，包括参数、返回值等。不过作为产品经理应该要能看懂接口文档，这样才能知道第三方服务的功能、使用限制等信息，方便我们做下一步设计，不会设计出接口不提供的功能；若接口方提供的信息不全，则可以给服务商提要求，让他们补充接口信息。

结尾

在设计过程中，产品经理会构思出多种方案，最终的设计结果可能并不是最优解。因此，在设计完成后，务必与开发团队一起讨论，召开评审会，集思广益并收集反馈意见。这不仅能优化设计方案，还能确保各方理解一致，减少后续开发中的沟通成本和误解。

此外，在开发推进的过程中，可能会发现很多功能和交互其实可以舍弃或者找到更优解，从而提高开发效率（在严格的开发流程下不可取）。精简需求，专注于核心功能，不仅能加快产品的开发进度，还能提升产品的可维护性和用户体验。通过这种方式，团队能够更高效地交付高质量的产品。