简介：商业BRD+市场MRD=产品PRD

前言

产品需求文档Product Requirements Document,PRD是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。

产品经理对用户价值的体现，产品经理对商业价值的体现，能改变世界的产品经理，大概是四有：有理想、有情怀、有眼界、有格局，手中的产品项目已经不仅仅考虑用户价值和商业价值，而更在乎它有没有产生正向的社会价值，例如滴滴改变用户出行习惯并创造300w就业机会，淘宝推动零售业、流通业、制造业的巨变并催生各类新行业，这就是一个产品对社会的价值。

常见术语：

• UCD（User Centered Design），以用户为中心的设计。
• UC（Use Case），用例。
• UAT（User Acceptance Test），用户可接受测试，产品运营+UI客服测试。
• DAU（Daily Active User），日活跃用户量。
• MAU（Monthly Active User），月活跃用户量。
• UED（User Experience Design），用户体验设计。
• PV（Page View），页面浏览量。
• UV（unique visitor），独立访问量。
• GMV（Gross Merchandise Volume），商品交易总量。
• ARPU（Average Revenue Per User），每用户平均收入。
• IAAS（Infrastructure-as-a-Service），基础设施即服务。
• PAAS（Platform-as-a-Service），平台即服务。
• SAAS（Software-as-a-Service），软件即服务。
• LBS（Location Based Service），基于位置的服务。
• SEM（Search Engine Marketing），搜索引擎营销。
• SEO（Search Engine Optimization），搜索引擎优化。
• ASO（App Store Optimization），移动APP的SEO优化。
• ROI（Return On Investment），即投入产出比。
• CPA（Cost Per Action），每次行动的费用。
• CPC（Cost Per Click），以每点击一次计费。
• CPS（Cost Per Sale），每购买成本。
• CPM（Cost Per Mille），千人成本。
• CPR（Cost Per Response），每回应成本。
• CPP（Cost Per Purchase），每购买成本。

制造口碑带来流量，转化流量带来盈利，支持业务带来稳定。

• B2B有三宝：企业、中介、沟通好
• B2C有三宝：品牌、渠道、销售好
• C2C有三宝：你开、我买、支付宝
• O2O有三宝：线上、线下、一起搞
• LBS有三宝：签到、优惠、位置找
• NFC有三宝：近场、支付、安全好
• SEO有三宝：内容、外链、权重屌
• EDM有三宝：内容、受众、分析好
• CPA有三宝：行动、转化、站长恼
• CPS有三宝：佣金、销量、效果好
• CPC有三宝：点击、引导、作弊少
• CPM有三宝：展示、千人、不可靠

产品前期思考-自查手册

做好产品前期思考，能让你在产品制作过程中省去很多“不必要的麻烦”。B端主要关注产品功能、稳定、安全、合规等方面，前期用户访谈，调研分析工作非常重要。C端主要关注产品易用性，用户测试后的反馈与产品迭代。

以下几项内容，思考的越为详细，产出的内容就越为完善。产品背景、目标人群分析、分析用户痛点、确定产品目的、建立用户模型、用户需求场景设定、定义初步产品方案、自行验证和质疑、对已有产品进行调研、对初步方案疑问点进行调整、输出产品方案。

1、产品（功能）背景（P0）

• 该产品（功能）内容是在什么情况下需要进行输出的，推出该产品是为了获得什么？

2、目标人群分析

• 使用该产品（功能）的用户是谁

3、分析用户痛点

• 分析用户在之前使用产品（或其他产品时），遇到困难是什么，导致出现该问题最根本的原因在哪里

4、确定产品（功能）目的

• 通过分析用户痛点，确定产品目的
• 分析清楚产品（功能）在输出时需要“取舍”的内容

5、建立用户模型（P0）

• 用户模型应该是产品（功能）的目标人群
• 并在用户人群中为典型的、可行的、真实的

6、用户需求场景设定

• 用户使用该产品（功能）时会遇到哪些问题，会进行场景下进行的操作
• 用户在该场景设定下使用该产品（功能）的操作频次，分好优先级
• 根据以上两项内容建立用户场景使用 [ 故事板 ]

7、定义初步产品方案

• 根据以上分析内容产出初步产品方案内容

8、自行验证和质疑

• 对初步方案的进行逻辑验证等
• 对初步产品方案有质疑的地方进行罗列，带着这些疑问去做调研

9、对已有产品（或类似功能的非直接竞品）进行调研

• 找到直接或间接5款左右产品进行功能调研
• 调研内容
• 重点调研上面有质疑的问题点，进行相应的验证
• 看下竞品在对这类功能的设计上有什么可借鉴之处
• 根据调研结果进行分析、比较

10、对初步方案疑问点进行调整（P0）

• 对之前「初步方案」中的疑问点进行调整

11、输出产品方案（P0）

什么是产品需求文档

该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。

需求池要素

初次进入需求池的需求是通过简单筛选和评估的。需求池管理有两个原则：有进有出、宽进严出。

编号

编号就是需求列表的顺序号，主要是作为当前需求的唯一性标识。

功能模块

根据现有的产品模块进行分类，初步判定此需求属于哪个功能模块的类别，若是新增业务功能，则此项可以待定不填写。

需求描述

如果是比较简单、不复杂的小需求，直接描述要解决什么问题。如果不是小需求，则不仅需要描述要解决什么问题，还要把为什么要解决问题的原因一并记录下来。（解决问题的原因，多数情况下需要产品经理刨根问底的去问，去了解实际上用户的需求到底是什么和想解决怎样的用户需求）

需求来源

直白的理解就是此需求从哪里来，是谁提了这个需求。

以产品经理作为需求主要提出人来分类的话，可分成如下两类：

被动告知需求：

1. 主要业务部门，包括市场部、运营部、财务部、管理层等主要业务部门，需求目的是为了上线某一个新业务或者是新活动，这时候产品要做的是了解新业务或者新活动的内容，梳理出业务流程，整理涉及到的逻辑出demo等等；
2. 客服，需求目的是解决某一类用户问题，当存在一类用户频繁咨询或投诉这类问题，客服是会把这类用户问题提交给产品组，产品来评估从业务和产品角度怎么进行优化此类问题；
3. QA，针对于视觉或者交互的细节QA在测试过程中，会遇到一些细节的小问题（主要是历史遗留），这时候会提交给产品，一般此类需求等级较低；
4. 用户意见反馈，每月收集整理用户提交的意见反馈（吐槽或建议），分析用户吐槽的问题是否具有普遍性还是个例，用户的建议是否能实现，背后想解决什么样的问题；

主动收集或挖掘需求：

1. 竞品分析，主要是在研究竞品或者同类型产品中，发掘比较好的功能且适用于自己产品（能解决一部分用户的需求或者能为企业带了一定的收入）
2. 用户研究，自己在论坛、贴吧、微博等内容社区，了解社区里那些属于自己产品的目标用户或潜在用户都在吐槽或者期待产品的哪些内容，产品要做的是了解这些问题背后的原因是什么，其次是怎么能解决这些吐槽或者满足用户需求。

需求类型

需求类型主要是记录此类需求属于哪一个类别的，前期需要定义好需求类型有哪些？主要需求类型有：

新增功能、功能改进、体验提升、BUG修复、内部需求等。

（我们公司主要是按需求来源划分的需求类型，业务需求、UI优化、QA优化、技术优化、产品优化、用户建议，和需求来源整合在一起，属于需求来源的一部分）

需求添加时间

此需求添加到需求池的时间，而不是需求提出人初次提出的时间。目的统计需求明确到需求上线的周期。

优先级

需求池中的需求优先级可以用高、中、低来初步进行确定哪个需求的优先级更高。通过需求评审后的需求，优先级更应该按照1、2、3、4的顺序进行排列。假设用高、中、低来确认需求优先级，会存在什么问题呢？当确定下个版本上线5个功能点（其中2个高、2个中、1个低），由于开发进度和开发资源的问题，5个功能点中只能如期上线3个功能点，那么就需要考虑在2个中的需求中先上线哪个？这样的话，前期按照高、中、低来评审需求优先级就存在不严谨性。

优先级判断原则：（四象限法则和kano模型结合）

• 重要且紧急（基本型需求） —— 必须g抓紧时间做。比如会影响到用户主流程使用的功能。（高）
• 紧急但不重要（魅力型需求） —— 只有在优先考虑了重要的事情后，再来考虑这类事。（中）
• 重要但不紧急（期望型需求） —— 只要是没有前一类事的压力，应该当成紧急的事去做，而不是拖延。比如节日优惠相关的需求，但是现在距离下一个节日还有3个月。（中）
• 既不紧急也不重要（无差异型需求） —— 有时间再处理，比如IOS和安卓视觉个别小按钮视觉不太一致。（低）

状态

待讨论、暂缓、拒绝、已明确。已明确的需求基本上下一步就是进行版本规划了，这时候需要重新评估需求优先级（用1、2、3、4数字标识），定哪个版本上线、版本啥时候发布。

备注

其他任何信息，如：需求期望完成时间、被拒绝原因、暂缓原因。

需求池有什么作用

需求容器

直白的来说，需求池就是个需求容器，不同来源的各种需求都可以进入（简单评审），进来之后的需求进行再次的评审，最终决定这个需求的去留。

缓冲地带

一段时间内来了较多的需求，而自己没法第一时间进行评估需求的合理性，这时候可以将需求先放进需求池内，后期自己再慢慢消化，再严格的评估需求的合理性。

版本规划

经过再次评审后留下来的需求，可作为下个版本发布的内容或下几个版本迭代的内容，目的是确保在做版本规划时有足够的素材来源，而不仅仅的靠自己盲目的规划。

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

​

产品需求文档的要素

文档的命名和编号

文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。

文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。

​

文档的版本历史

包括，编号、文档版本、章节、修改原因、日期、修改人。

编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改，一次修改一般为一个版本)，章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。

​

日期是指需求文档修改的时间，修改人是指需求内容的修改者。

目录

不需要自己新建，文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的。

引言

这部分的内容有：产品概述及目标、产品Roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明。

​

1. 产品概述：解释说明该产品研发的背景以及核心功能。
2. 产品Roadmap：为产品规划的蓝图，每个关键阶段完成的核心任务。产品研发是个不断迭代的过程，需要经过若干个版本的迭代，，对一个功能点做了N个迭代后最终又回归到了第一个迭代是很常见。产品经理需要做好心理准备。产品Roadmap并不需要全部规划好所有的阶段目标，但是对产品未来发展趋势的一种预估，要达到目标，需要更多的更新和迭代。清晰的呈现产品的Roadmap可以帮助产品经理把握产品的全貌，更好的控制研发过程。
3. 预期读者：文档的使用对象
4. 成功的定义和判断标准：旨在说明产品的目标
5. 参考资料：PRD的参考资料
6. 名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。

需求概述

需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等。

​

1. 需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。
2. 用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。
3. 运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。设计和实现上的限制：比如控件的开发环境、接口的调用方式等等。
4. 项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等等。
5. 产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。

功能需求

功能需求一般是由功能详情和主流程说明两大部分。

​

功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：

1. 简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。
2. 场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件。
3. 业务规则：每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。
4. 界面原型：如前所述，涉及到页面交互的部分，产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是，产品经理可设计一个页面框架，将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。
5. 使用者说明：对产品使用者做出说明，可融入简要说明中。
6. 前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。
7. 后置条件：操作后引发的后续处理。
8. 主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(这是非常重要的)。

看过很多的PRD，文档中对既没有前提条件，也没有后置条件，只对主流程做了说明，但是在描述主流程时却没有描写主流程中每个功能流程的各种走向，只有一个主走向，让人感觉prd成了操作手册。

以普通的前端展示页面来说，需要写清楚如下五点：

1. 流程说明，主流程、分支流程、异常流统统写明；
2. 跳转说明：点击返回/编辑/保存/取消等，分别触发什么。弹框是怎么进入怎么消失的。toast显示几秒，停留在当前页还是返回上一页；
3. 显示规则，这个页面包含哪些元素，都是哪些字段，格式大小要求是什么，是否换行全部展示，过长或过短怎么展示，异常输入怎么显示、空态页显示什么等等；
4. 排序规则：第一排序优先级是什么，第二排序优先级是什么，正序还是倒序排列等等；
5. 分页规则：一页最多展示几个，一次拉取几个。下拉还是上滑刷新，是全页刷新还是半页还是指定区域刷。

事实上，对分支的介绍是非常重要的，开发和测试中提出的各类问题均与对分支的定义不明有关。

把该强调的细节都强调了，文档要写的条理分明，评审要讲的逻辑清晰。例如：这个页面涉及哪几个功能，需要哪些开发支持，主流程是什么，异常分支是什么，特殊的规则和要求是什么。建议：自己讲完可以邀请关系好的开发复述一遍，就知道哪些地方要着重再讲一遍。

一个合格的PRD不仅要描述主流程，同时对分支流程所出现的各类问题都要做详细阐述并给出解决办法。PRD的特征一定是明确的、全面的阐述需求及各类异常情况的处理而不是等到开发和测试阶段发现问题后再给以答案(虽然PRD不可能百分之百的覆盖所有的可能，但是最大化的思考所有的业务问题是编制PRD时必须遵守的原则)。另外，在描写功能需求时给出的办法中不能出现“可能”、“或者”等词，一定是明确的，准确的描述。如果有别的方案，建议写入“可选方案”，在产品构建的早期可选方案可以为功能实现提供更多的选择，当方案确定后可在文档中注明本次使用了哪种方案。

沟是方式，通是结果。结果不对，方式肯定错误。好的沟通方式，发自内心的尊重，耐心聆听的理解，相处自然舒服不添乱，做一个靠谱的产品经理。一个优秀的产品经理不需要会写代码，但要清楚技术的实现方案，以及，能够从业务角度，专业的回答很多个为什么。

看看API文档；看看数据库表结构，以及表中有哪些字段，这些数据的调用、流转、更新是怎么样的；看看架构图；听听开发讲各系统的依赖关系。

推荐一个方法：“用例”，在面向对象的产品设计模型中，用例是一个被阐述的内容，用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。

效益成本分析

通过这一点上能看出产品经理必须是个全才，不仅要具备行业知识，还需要有财务知识。一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。

一个需求上线后能产生多大价值，完成这个需求需要多大的成本。成熟期的前端型产品优先级可能会根据运营的阶段和规划，即使是运营的规划，也是这次运营活动能带来多少数据，而数据就能折算成收益，上线运营活动的人力时间就是成本。

效益预测是指所提供的功能在未来能产生的效益，可通过对比以往的产品或者竞争对手的产品来做预估，效益预测的指标，如每个功能点的潜在用户数、使用频率，吸引到的新的用户特征及数量。产品技术成本是指研发设计以及上线后的运营需要的资源需求，包括人力，软硬件(带宽、服务器、机房)支出。当有项目经理时可以由项目经理来协调这部分需求，如果没有项目经理，产品经理得挑头了，召集开发经理去找运维等部门落实此事。其他的成本还包括支持成本，比如上线后的运营资源投入、市场推广投入以及客服服务投入等。

项目成功的决定性因素就是“产品做得好”。

此处建议产品经理们都去学习一门课《非财务人员的财务管理》体验下财务的过程管理，如果能亲历沙盘训练，记录财务明细账目，核算资产负债、现金流量、利润率的计算，对成本和利益的核算非常有帮助，而且财务上要求的一丝不苟、精益求精也是每个产品经理需要长期坚持和遵守的。

整合需求

产品整合能力是产品经理很重要的一个能力，业务合作通常是不可避免的，将隶属于两个不同来源的业务功能做整合也是常见需求，比如系统登陆使用公司的域用户登陆，或者付款使用财付通、支付宝付款，解决好整合需求也是体现产品经理核心竞争力的一大重要表现。

BETA测试需求

很多产品在正式上线前都有BETA测试版或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或者性能。这部分内容不是必须的，但如果需要，需要给出在此阶段要实现的目标或测试、衡量标准。

非功能性需求

一般情况下非功能性需求包括以下几个部分：产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。

​

​

​

这些信息构成了产品上线的完整内容，也很好的体现了产品经理的综合素质。

​

运营计划

产品上线后如何运营，目标受众是什么，建议的推广策略、问题反馈途径、风险监控、亮点宣传等等，以及与运营人员的协作方式。作为产品的设计人员不是开发完产品就能画句号的，让产品用起来、用得好，有口碑更为重要，所以非常建议运营计划的制定上有产品设计人员的参与。

项目成功的决定性因素是“产品运营做得好”。

再次，说下需求变更，需求不是一成不变的，在产品研发过程中需求变更是正常的，产品团队成员需正确的看待需求变更，并要控制好变更。这里的建议是在做需求分析时，尽可能把每个问题都考虑透彻，提前做好需求变更的预估及应对方案，必要的情况下和团队成员提前沟通存在变更的内容。

在与团队沟通变更时，需要以一种开放的心态，从团队成员的角度、产品未来的发展趋势、市场格局的变化正确的提出变更需求，始终保持产品方向的正确和团队成员目标的一致。

项目成功的决定因素是“产品模型要搭建得好”。产品模型=商业模式+产品架构+运营体系。产品生命周期的上限，盈利能力的上限，产品数据的上限，基本都已经敲定了。产品运营最多只能优化到无限接近于这个上限的理论值，除非市场发生突变或新技术产生，否则绝无可能超过这个上限理论值。而这个上限理论值就是由项目的商业模式决定的。

举个例子：小米手环毛利薄，79元的售价几乎接近工业成本。需求强度低，核心功能是计步和睡眠，还有心率、来电提醒、闹钟等辅助功能，不算强需求。需求频次低：长期带手环超过一个月的人很少，所以小米运动APP留存低，用户粘度差。市场小，竞品和可替代产品多。所以这个产品项目永远也无法成为独角兽，甚至无法依赖自身而完成商业闭环，只能依附小米手机以及其他智能家居，成为整个棋盘里某一颗棋子，有点像是“兵”，“帅”需要时“兵”要冲锋，必要时就牺牲。

这里想强调的是，产品模型最核心的是商业模式，其次才是产品架构运营策略，而这个才是优秀产品经理真正的价值。

产品需求文档的相关内容

文档意义

该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。

文档撰写

在该文档中，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求本身是在MRD中有所体现的，区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

文档核心

该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing & Product Requirements Document”。

产品需求文档的写作方法

写前准备

在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。

例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。

罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。

梳理需求

当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。

以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。

原型设计

当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。

对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。

撰写文档

当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的(很多产品经理直接使用Axure制作PRD)。

当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范标准，这类情况可能是需要存档归类。无论什么样的规范标准，PRD文档的目的都是相近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写PRD文档的方式。

用例文档

《产品需求文档(PRD)的写作方法》的补充文章，主要讲解PRD文档中的重要辅助文档“用例文档”。

《产品设计方案-自查手册》简介

在产品设计过程中，难免会出现遗漏特殊态说明等一些内容。为了最大化避免这一问题，让产品设计方案在移交开发时更为完整，《产品设计方案-自查表》，可以帮你从产品设计方案的各种形态进行 PRD 文档回测，下面是详细的自查表目录列表内容：

• 前置条件

• 账户 / 角色相关

• 数据

• 内容展示

• 内容排序

• 内容输入与选择

• 内容刷新和加载

• 状态/交互

• 操作时

• 操作后

• 动效说明

• 硬件和网络

• 硬件设备与交互

• 网络和缓存

• 其他

• 通知机制

• 模式

• 兼容性

• 数据埋点

• 用户体验

• 产品整体框

• 流程设计

• PRD阅读体验

《产品文案内容-自查手册》简介

优质的产品文案，是会使用清晰、准确的语言进行表述，让用户更容易理解，更轻松与用户间建立信任感。《产品文案内容-自查表》，能帮你不断的优化文案内容，给用户带来更好的产品体验。下面是详细的自查表目录内容：

• 产品文案

• 语言

• 基本语言表述
• 内容
• 常见说明
• 层次性、引导性

• 语气

• 英文、阿拉伯数字使用和标点规范

• 英文、阿拉伯数字的使用
• 标点符号
• 关于撰写PRD文档

• 基本语言表述

• 内容



参见：

PRD自查手册 (xiaopiu.com)