我们常常听到BRD、MRD、PRD，很多人可能不知道这3者到底是什么意思，三者的区别和联系又在哪里？
1、BRD、MRD 和 PRD 是什么
BRD：商业需求文档 ，全称 Business Requirement Document
一般都是针对老板或CEO或者项目总负责人，浓缩了商业模式、盈利模式、资源投入、市场优势等等，主要是为了产品的战略规划。
文档主旨：
- 要做什么样的产品
- 需要什么样的资源
- 最终做成什么样子
MRD：市场需求文档 ，全称Market Requirement Document
一般都是针对商务、运营、市场人员，浓缩了产品模式、业务模式、运营模式、市场模式等等，主要是为了明确客户及市场方向。
文档主旨：
- 我们要找什么样的客户，进行资源合作
- 找到客户后，我们该怎么和他们说
- 产品针对什么样的用户群体
PRD：产品需求文档 ，全称Product Requirement Document
一般都是针对项目组、开发组、测试组、设计组、交互组人员，浓缩下就是产品界面、产品流程、功能需求、测试需求、体验需求等，主要是为了产品能够落地实现。文档主旨：
文档主旨：
- 产品具体是什么样的呢？
- 我们该怎么实现呢？
- 什么样的成品才能投入到市场？
产品经理主要写的还是PRD文档，我们下面就详细的说说怎么写好一份PRD文档。
2、什么是高质量 PRD
PRD的目标人群是开发、测试、交互、UI，高质量的文档就是要让他们能看懂，顺利开发，最终完成一个预想的产品。
可以从这几方面来评估：
1、没有逻辑错误
逻辑错误指前后对不上，闭环走不通，这是最致命的问题，开发会不知道怎么做，即便勉强做出来了，用户也用的云里雾里的。比如大一点的：微信端提交了订单，后台没有显示的地方：小一点的：微信端显示的自定义字段，后台却没有地方设置。
2、逻辑清晰
逻辑要有条理，这样开发可以按着思路一步步的做下来。如果逻辑比较混乱，这边写一点，那边写一点，写的又不清晰，开发实现起来就很困难，就像一团麻线一样，不知道哪里是头，要从哪里下手，也不知道下一步要做什么。
3、少细节疏漏
要想完全避免细节疏漏是不可能的，特别是当系统做的很复杂时，一个功能点往往和其他的点有着直接或间接的联系。我们能做的是尽可能的想到所有的影响点，没有大的疏漏，小的疏漏可以在开发过程中再补充。
4、可读性强
我一开始接触的PRD文档是用word写的，一个系统能写上3-4万字。每次看文档都特别累，要上下来回的翻原型，看规则。而且一旦发生内容变更，需要重新发送给所有人，协作极其麻烦。
现在公司大多会用AXURE直接来写PRD。原型旁边附上规则，可读性就强多了。产品内部通过AXURE协作写文档，然后上传到服务器上，还能随时更新。其他人员每次看一份文档就可以了，涉及到页面间的跳转关系都能直接点击，大大提高了工作效率。
3、如何产出高质量 PRD
不管是word形式还是AXURE形式，PRD中包含的内容是一样的，但上面也说了AXURE形式可读性更强，我们还是用这种形式来说说，怎么写一份高质量的PRD。
PRD结构
1、修订记录
在开发过程中，变更功能点是很正常的，但在几十个甚至几百个页面中让团队人员找到那个改动点，就像是大海捞针，必须明确的指出。而且改动点比较小，比较零散，今天几个，明天几个，团队人员很容易遗漏，最后产品发现功能和预想的不一样。
如果我们每次在修改需求后，记录一下变更时间，内容，页面链接，修订原因等，团队就知道这一次版本在开发、测试过程中，都修改些什么内容，有纠纷时能够追溯到源头，也有利于产品进行复盘思考。
2、项目介绍
如果直接丢给开发一个原型，开发可能就懵了，看完整个原型才明白，哦，原来是要做这个啊。如果原型写的逻辑混乱一点，开发看完可能也不知道要做什么。但如果我们先进行一个简单的项目介绍，团队人员就能快速了解功能，知道要做什么，目标是什么。这能节省沟通成本，内部先就目标达成一致，方便后面沟通具体页面和细节。
可以从这几方面来介绍：
2.1 目标用户
指明功能的实际使用人。如果是给B端做的，要具体到某个岗位的人，比如说医生，护士。如果能进行一个简单的用户画像描述，会更好。因为团队人员可能不了解用户，简单画像的描述能够让他们更容易理解功能。
2.2 场景描述
描述目标用户在什么场景下进行什么行为。可以用一个具体的例子来描述，这样比宽泛的说会更好理解。我们重点在于让团队人员理解场景，不需要像我们做需求分析时那样详细和覆盖完整。
2.3 需求/痛点描述
描述目标用户在场景下操作的时候遇到了什么问题。抛出的问题已经是我们筛选过的，真实、合理，本次目标解决的问题。
2.4 可解决方案
简单描述下提出的解决方案。可能方案不只一个，把想到的方案都写上，并列上优缺点。然后标注下这次选择的方案。后面复盘的时候，也能知道当时选这个方案的理由。
举个拼团的例子，这是一开始描述的项目情况：
3、功能框架
还是站在整体的角度，来描述下功能的流程和结构框架，这2部分都在上面2节中进行了详细的描述，这边把他们放进来。
3.1 流程图
比如说拼团，涉及到多个平台，需要一个总流程图，梳理下各平台之间的流转规则：
然后针对核心功能，列出详细的流程图，比如说拼团活动创建流程：
如果异常流程对功能设计影响较大，可以单独拿出来说明一下，比如客户拼团时商品详情页发生的异常情况：
3.2 结构图
我们在最开始写结构图时会写的比较仔细，包括每个页面的字段，重点规则，这样画原型时就不会遗漏了。但在文档里面附上结构图时，不用细致到每个字段，到页面及功能点即可，主要是让团队人员知道本次的范围。
比如拼团结构：
4、全局说明
整体说明一下产品认为的重要事项，可能会被遗漏的问题点，还有一些通用规则，以减少沟通成本，减少重复描述，提高产品写文档的效率。
4.1 明确名词含义
每个人的用词习惯不一样，而且同样的名词在不同的场景下定义也可能不一样，所以一些重要名词先要明确下含义，否则多方沟通时会发生误解，产品在实现时就会出现偏差。明确含义可以从这2方面入手：
名词解释确定。明确定义名词指代的具体事物和规则。比如对新用户的定义，可能在电商是首次注册的用户；在O2O是线上或线下首次注册的用户。
同一事物名词一致。文档前后，不同的产品经理之间对同一事物的指代用同一个名词，否则其他人就会有疑问，到底是不是指那个呢？到底用哪个名词呢？比如说订单状态，待付款、待付钱，其实是一个意思，那就统一都叫待付款。全局替换下就可以。
4.2 重要规则
我们会把产品业务规则写在对应原型页面上，但这样就会导致规则比较零散，重要规则和普通规则混杂在一起，看起来比较累。可以把一些重要的规则提炼出来，首先和团队人员强调一下，这样大家都有了一个大的规则框架，后面沟通细节时也会比较容易。
比如这是拼团写的重要规则：
4.3 通用规则
一般是一些交互规则，在原型中，会遇到很多共用组件的情况，比如弹窗，角标。如果在每个涉及到的地方都写一遍交互规则，会让页面规则看上去很多，重点规则容易被忽视。可以在文档前面就描述通用的交互规则，后面用到的地方加个链接就可以了。
比如这是拼团的交互规则：
5、原型图
有的产品经理一上来就画原型图，然后画着画着就画不下去了，感觉逻辑走不通，前后对不上，页面上的字段也不知道放什么，画完后又发现很多细节都没有考虑到。
其实原型图是承接上面的项目介绍，功能框架和全局说明来的，这些事情都想清楚了，计划好了，原型画起来就简单了。这步主要是结合用户的特征和行为习惯，把功能用页面形象化、可视化地表现出来，告诉大家最终的成品大概是这样的。
有的产品可能会有疑问：要不要画高保真原型？如果是给内部人员看，不要！高保真原型会浪费很多的时间，实际上对于开发的帮助却很小，不如把时间花在其他值得地方。如果要给用户演示，可以视情况做的美观，详细一点。
有的公司交互配备比较好，产品只需要理出结构图，就可以交给交互出原型图了。但我还是建议产品画个大的框架，不用很美观、很详细，把页面结构，重点内容，页面间的联系画出来。因为很多时候交互没有直接深入过用户，没有产品了解用户的习惯，特别是B端产品。
5.1 原型规则
5.1.1 一个页面一个原型图
有的产品会把很多原型图都画在一个页面里面，用箭头标识页面之间的跳转关系。这样看上去原型图之间的联系是清楚了，但别人看的时候，要往旁边或者下面拉动，图一多都不知道哪里是终点，很容易遗漏一些页面。比如下面这样的：
建议一个原型图放一个页面，这样不会有遗漏的情况，开发一看侧边栏，就明白涉及了几个页面，也好评估工作量，合理安排时间。
5.1.2 站点地图
页面之间的跳转关系，可以加上跳转链接，AXURE里面直接拖动侧边栏到页面里面即可。如果觉得整体页面跳转情况不清晰，可以整体画个页面地图，只要说清楚页面之间的关系即可，不用画得很详细。
5.1.3 原型不要用截图
这是我踩过的一个很大的坑，因为在原来的功能上进行优化，图个方便，直接把线上的页面截图下来，放在页面上，然后写上改动点。当时是节省时间了，但下次再优化这个页面的时候，发现改动起来特别麻烦。所以长久来考虑，尽量用组件画原型。
5.1.4 页面旁边即标注规则
我们已经一个页面一个原型图了，旁边有很大的空间可以写上规则。原型上用数字标上注释点，旁边写上对应的规则。
要注意包含这2方面的规则：
功能规则
功能点名称及说明。功能点名称可以用醒目的大标题写明，就像上图的紫色主标题。这样在看原型图标注的时候，能立马明白功能点的目的，下面写上对应的总规则，这样看起来比较清晰，可读性强。
字段说明。建议把页面上的字段用表格的形式列出来，表格里面的字段可以根据业务需求来调整。这样子页面就不会乱乱的都是字了，看起来简洁明了，也不会遗漏一些字段规则的说明。
3 .异常校验。也可以用表格的形式来显示，表格里面的顺序也是校验的优先级，开发可以按着这个顺序来进行校验，看起来比较直观。
5.2 交互规则
交互即界面和用户的互动，我们需要考虑点击按钮时，会出现什么；hover时，有什么效果；报错信息的样式等等。我们很想和功能规则分开来，这样会看起来更加的清晰，但会发现有时候挺难的，比如说报错时就会写上用什么形式来报错。如果真想区分明显一点，可以用颜色来标识一下。
注重用户体验
我们在画结构图时，只考虑功能的合理性，只是保证产品能用，但要想产品好用，必须注重用户体验。差的用户体验会让用户使用时浪费时间，心情烦躁，最终弃用产品。
好的用户体验有几点原则呢？
1.所见即所得
最好的体验就是用户一看就懂，一点就会，不要学习成本。C端产品做到这个不难，因为市场上的产品已经高度教育过用户了。B端产品完全没有学习成本不大可能，但我们可以尽可能的表述清楚。能用文字表述的，不要放个看不懂的按钮。能在页面上看见的地方放下的，不要隐藏、hover、收起。尽量做到所见即所得。
2.符合用户习惯
不同的用户在不同的场景下，使用习惯不一样，我们需要考虑的是使用的那个人。比如说年纪大的人使用，需要字体加大加黑，按钮够大好点击，不要纯从美观的角度去考虑，好用比好看更重要。
3.交互一致性
整个系统的交互规则要统一，比如页面中点击出现的弹窗效果，hover效果。不要这个页面是一个规则，下个页面是另一个规则，用户在使用时会觉得很跳脱，莫名其妙。
4.新手引导
B端产品很需要新手引导，但不是每个地方都需要，重点要说明下图标、隐藏操作等这类用户可能不知道的操作。简单明了的新手引导，能让用户轻松上手，减少很多培训成本。
5.灵活高效
要方便、高效的帮助用户解决问题。比如说历史使用过的记录能排在前面，这样用户在搜索时可以直接选择，不需要再找了。一些这样的细节提升，能节省用户的很多时间。
6.友善提示
我们都见过最不友善的页面：404。用户出错了，需要明明白白的告诉用户原因，能提供解决方案更好。包括一些空页面，也需要提示下是什么原因，不然用户看着白白的一片，以为电脑坏了呢。
7.容错机制
用户很容易点错，我们常见的容错机制：删除时让用户二次确认。但还需要考虑一些流程上的容错，比如用户一不小心点击了开始，能不能回退？一不小心点击了结束，填写的内容能不能修改？不能修改的地方，都要考虑一下出错后的解决方案。
4、如何持续提高 PRD 质量
从最开始word版的PRD，到后面AXURE版的PRD，不仅是功能设计上要提高质量，表现形式上也要提高质量。以便团队人员能减少沟通成本，提高开发质量。
给几点提高的小建议：
一、自我成长
不同角色看待问题的角度是不一样的，比如开发会关心细节，甚至一句提示语怎么写；测试会关心异常流程，看文档中有没有漏洞。
记录开发过程中不同角色提出的问题，然后归类是什么类型的问题：
逻辑问题。在前期设计流程和结构的时候多下点功夫，可以和团队人员深入沟通，让其他人来帮助自己完善产品逻辑。
业务细节问题。设计完后可以多和用户沟通，完善细节地方。这类问题比较细，比较杂，要靠多积累，后面会慢慢变少。
交互问题。多观察用户的操作，和交互一起解决。
文档管理问题。定一个标准，大家都按一样的规范来。后面有问题的时候及时修订标准。
二、交流学习
除了完成自己的工作，还要多和别人交流，有时候确实是：与君一席话，胜读十年书。多交流学习会进度的很快。可以找这些人多交流：
部门内产品。这是最方便的，可以经常分享一些设计思路，遇到的坑，互相评审PRD书写。
其他部门的产品。多做一些跨部门的产品交流，公司有组织的话，可以积极参与。没有的话，可以自己发起。
外部交流。和前同事，外部机构讲座、培训等多交流分享，开拓眼界，取长补短，提升自己思维能。
5、总结
PRD是产品经理最终交付给开发、测试等人员的文档，是产品开发的直接依据。一份高质量的文档，能节省沟通成本，提高开发质量。
高质量的PRD要做到：没有逻辑错误，逻辑清晰，少细节疏漏，可读性强。
高质量的PRD需要包含这些内容：修订记录，项目介绍，功能框架，全局说明，原型图。
可以通过自我成长和交流学习的方式来持续提高PRD质量。
产品交付完文档，是不是工作就完成了？当然不是，产品还需要关注整个项目流程，和不同角色的沟通合作，请看下章的讲解。
