产品经理应该先撰写产品需求文档(PRD)，而不是先绘制原型图。为什么呢?
这是因为原型图只是 PRD 文档中的一部分内容。一个完整的 PRD 文档涵盖了多个方面，如产品概述、产品架构、流程梳理、规则说明、功能交互、数据埋点等。
如果在撰写文档之前就直接开始绘制原型，可能会导致需求考虑不周全、功能无法闭合，甚至可能存在逻辑缺陷。
此外，一些新手产品经理由于缺乏系统的产品知识，撰写的 PRD 文档可能存在逻辑混乱、条理不清的问题，从而遭到领导和开发团队的批评。
那么，如何避免这种情况呢?什么样的需求文档才算优秀?撰写 PRD 时应该抓住哪些重点呢?
产品需求文档(Product Requirement Document)是产品经理必须掌握的基础技能，它主要用于记录当前版本的需求背景、产品方案、原型界面等内容。
我通常使用的需求文档模板包括以下九个部分：产品概览、产品结构、UML 相关、流程梳理、文档相关、消息推送、原型界面、功能交互、废纸篓。
接下来，让我们逐一探讨这些内容。
产品概览
产品概览主要包括以下四个模块：版本封面、版本日志、版本背景、更新内容。
版本封面：位于需求文档的第一页，展示了“项目名称、版本编号、版本开发时间、版本发布时间、版本相关负责人”等信息。封面的主要作用是装点文档，使其看起来规范而高大上，提升团队成员的参与感。
版本日志：撰写版本日志的目的是让相关利益相关方了解版本的迭代过程，以及帮助理解版本的更新内容。因此，版本日志需要用通俗易懂的语言描述，避免使用过于技术化的描述。
版本背景：版本背景是文档的说明书，明确告知读者当前版本的开发目的和必要性。
更新内容：更新内容主要是对相关开发人员开放的。它主要指出当前版本的关联需求，让前后端知道开发范围。
产品架构
产品架构分为产品结构、功能结构、页面结构三个部分。
产品结构：主要呈现产品的模块分布。
功能结构：以一个功能或模块为主题，展示该功能的组成。
页面结构：描述一个版本的相关页面及页面之间的从属关系。
UML 相关
UML 的模块包括类图、用例、状态图、活动图、时序图等，我通常使用较多的是类图和状态图。
类图：主要用于呈现不同对象及其之间的关系。
状态图：描述一个对象在周期内的状态及其变更条件。
流程梳理
该模块主要针对“业务、功能、页面”等相关流程进行系统梳理。
业务流程：描述某业务涉及的各个角色、规则和环节等关系，帮助产品深入思考业务场景。
功能流程：研究的主体通常为一个功能，并梳理出该功能涉及的相关系统条件和流程变化等。
页面流程：指的是用户进行某些操作时，相关的页面跳转过程。
文档相关
文档相关模块，用来存放一些概念说明、数据相关等内容。具体包括以下内容：
版本排期：当一个业务需求较复杂时，我们会将功能模块拆分为多个版本，此时就要进行多版本排期，以供需求方参考。
名词解释：对系统、业务名词进行解释，帮助读者快速了解、掌握相关概念知识。
角色权限：定义不同角色在系统中的操作权限。
全局说明：对系统的设计规范、规则要求进行统一说明，确保相关人员理解。
数据实例：针对某些数据表，进行数据模拟，提升读者对相关功能的进一步理解。一般涉及数据创建的需求，也可以在该模块说明，用作部分功能的自定义配置。
数据埋点：如版本涉及数据跟踪和数据埋点要求，可在此进行补充。
消息推送
消息推送的类型主要有：短信、邮件、APP 推送、订阅消息、模板消息等。消息推送主要告知开发，当前版本涉及的消息内容、消息规则，及其他推送的注意事项。
原型界面
原型分为高保真原型和低保真原型，如果不需要演示给客户看，我建议你为了工作效率(偷个懒不过分吧~)，绘制低保真原型就可以了。一些常用的原型界面有：异常页、结果页、对话框、原型页。
异常页：用于存放部分页面的异常状态，例如“搜索商品为空、订单列表为空”等。
结果页：当用户完成某项操作后，展示的操作结果页面，例如“订单交易完成”。
对话框：将当前版本的所有对话框提示，单独存放在一个“对话框”页，以便开发便捷查询。
原型页：指具体的版本功能涉及页面。
功能交互
功能交互模块，一般用于撰写版本迭代中，涉及相关功能的交互规则。例如”用户注册“的功能流程，就可以用”用户注册交互“的单独页面进行撰写。
交互一般可分为动态交互和静态交互。
动态交互：顾名思义即包含了自动化或触发式的一系列变化的交互效果。
静态交互：是指将这种动态交互效果，通过一张张页面、组件铺开组成的交互流程图。
需求文档作为产品的基础能力，本质是一种沟通工具。它主要用来承载产品方案、原型界面等内容，一般有 9 个部分：产品概览、产品架构、UML 相关、流程梳理、文档相关、消息推送、原型界面、功能交互、废纸篓等。每个模块都有特定的作用，撰写时要注意规范性、易读性，前后端查阅时，才能快速抓住重点。
