一文搞懂BRD、MRD和PRD,让你交付高质量原型

我们常常听到BRD、MRD、PRD,很多人可能不知道这3者到底是什么意思,三者的区别和联系又在哪里?

一文搞懂BRD、MRD和PRD,让你交付高质量原型

1、BRD、MRD 和 PRD 是什么

BRD:商业需求文档 ,全称 Business Requirement Document

一般都是针对老板或CEO或者项目总负责人,浓缩了商业模式、盈利模式、资源投入、市场优势等等,主要是为了产品的战略规划。

文档主旨:

  1. 要做什么样的产品
  2. 需要什么样的资源
  3. 最终做成什么样子

MRD:市场需求文档 ,全称Market Requirement Document

一般都是针对商务、运营、市场人员,浓缩了产品模式、业务模式、运营模式、市场模式等等,主要是为了明确客户及市场方向。

文档主旨:

  1. 我们要找什么样的客户,进行资源合作
  2. 找到客户后,我们该怎么和他们说
  3. 产品针对什么样的用户群体

PRD:产品需求文档 ,全称Product Requirement Document

一般都是针对项目组、开发组、测试组、设计组、交互组人员,浓缩下就是产品界面、产品流程、功能需求、测试需求、体验需求等,主要是为了产品能够落地实现。文档主旨:

文档主旨:

  1. 产品具体是什么样的呢?
  2. 我们该怎么实现呢?
  3. 什么样的成品才能投入到市场?

产品经理主要写的还是PRD文档,我们下面就详细的说说怎么写好一份PRD文档。

2、什么是高质量 PRD

PRD的目标人群是开发、测试、交互、UI,高质量的文档就是要让他们能看懂,顺利开发,最终完成一个预想的产品。

可以从这几方面来评估:

1、没有逻辑错误

逻辑错误指前后对不上,闭环走不通,这是最致命的问题,开发会不知道怎么做,即便勉强做出来了,用户也用的云里雾里的。比如大一点的:微信端提交了订单,后台没有显示的地方:小一点的:微信端显示的自定义字段,后台却没有地方设置。

2、逻辑清晰

逻辑要有条理,这样开发可以按着思路一步步的做下来。如果逻辑比较混乱,这边写一点,那边写一点,写的又不清晰,开发实现起来就很困难,就像一团麻线一样,不知道哪里是头,要从哪里下手,也不知道下一步要做什么。

3、少细节疏漏

要想完全避免细节疏漏是不可能的,特别是当系统做的很复杂时,一个功能点往往和其他的点有着直接或间接的联系。我们能做的是尽可能的想到所有的影响点,没有大的疏漏,小的疏漏可以在开发过程中再补充。

4、可读性强

我一开始接触的PRD文档是用word写的,一个系统能写上3-4万字。每次看文档都特别累,要上下来回的翻原型,看规则。而且一旦发生内容变更,需要重新发送给所有人,协作极其麻烦。

现在公司大多会用AXURE直接来写PRD。原型旁边附上规则,可读性就强多了。产品内部通过AXURE协作写文档,然后上传到服务器上,还能随时更新。其他人员每次看一份文档就可以了,涉及到页面间的跳转关系都能直接点击,大大提高了工作效率。

3、如何产出高质量 PRD

不管是word形式还是AXURE形式,PRD中包含的内容是一样的,但上面也说了AXURE形式可读性更强,我们还是用这种形式来说说,怎么写一份高质量的PRD。

一文搞懂BRD、MRD和PRD,让你交付高质量原型

PRD结构

1、修订记录

在开发过程中,变更功能点是很正常的,但在几十个甚至几百个页面中让团队人员找到那个改动点,就像是大海捞针,必须明确的指出。而且改动点比较小,比较零散,今天几个,明天几个,团队人员很容易遗漏,最后产品发现功能和预想的不一样。
如果我们每次在修改需求后,记录一下变更时间,内容,页面链接,修订原因等,团队就知道这一次版本在开发、测试过程中,都修改些什么内容,有纠纷时能够追溯到源头,也有利于产品进行复盘思考。

一文搞懂BRD、MRD和PRD,让你交付高质量原型

2、项目介绍

如果直接丢给开发一个原型,开发可能就懵了,看完整个原型才明白,哦,原来是要做这个啊。如果原型写的逻辑混乱一点,开发看完可能也不知道要做什么。但如果我们先进行一个简单的项目介绍,团队人员就能快速了解功能,知道要做什么,目标是什么。这能节省沟通成本,内部先就目标达成一致,方便后面沟通具体页面和细节。

可以从这几方面来介绍:

2.1 目标用户

指明功能的实际使用人。如果是给B端做的,要具体到某个岗位的人,比如说医生,护士。如果能进行一个简单的用户画像描述,会更好。因为团队人员可能不了解用户,简单画像的描述能够让他们更容易理解功能。

2.2 场景描述

描述目标用户在什么场景下进行什么行为。可以用一个具体的例子来描述,这样比宽泛的说会更好理解。我们重点在于让团队人员理解场景,不需要像我们做需求分析时那样详细和覆盖完整。

2.3 需求/痛点描述

描述目标用户在场景下操作的时候遇到了什么问题。抛出的问题已经是我们筛选过的,真实、合理,本次目标解决的问题。

2.4 可解决方案

简单描述下提出的解决方案。可能方案不只一个,把想到的方案都写上,并列上优缺点。然后标注下这次选择的方案。后面复盘的时候,也能知道当时选这个方案的理由。

举个拼团的例子,这是一开始描述的项目情况:

一文搞懂BRD、MRD和PRD,让你交付高质量原型
一文搞懂BRD、MRD和PRD,让你交付高质量原型

3、功能框架

还是站在整体的角度,来描述下功能的流程和结构框架,这2部分都在上面2节中进行了详细的描述,这边把他们放进来。

3.1 流程图

比如说拼团,涉及到多个平台,需要一个总流程图,梳理下各平台之间的流转规则:

一文搞懂BRD、MRD和PRD,让你交付高质量原型

然后针对核心功能,列出详细的流程图,比如说拼团活动创建流程:

一文搞懂BRD、MRD和PRD,让你交付高质量原型

如果异常流程对功能设计影响较大,可以单独拿出来说明一下,比如客户拼团时商品详情页发生的异常情况:

一文搞懂BRD、MRD和PRD,让你交付高质量原型

3.2 结构图

我们在最开始写结构图时会写的比较仔细,包括每个页面的字段,重点规则,这样画原型时就不会遗漏了。但在文档里面附上结构图时,不用细致到每个字段,到页面及功能点即可,主要是让团队人员知道本次的范围。

比如拼团结构:

一文搞懂BRD、MRD和PRD,让你交付高质量原型

4、全局说明

整体说明一下产品认为的重要事项,可能会被遗漏的问题点,还有一些通用规则,以减少沟通成本,减少重复描述,提高产品写文档的效率。

4.1 明确名词含义

每个人的用词习惯不一样,而且同样的名词在不同的场景下定义也可能不一样,所以一些重要名词先要明确下含义,否则多方沟通时会发生误解,产品在实现时就会出现偏差。明确含义可以从这2方面入手:

名词解释确定。明确定义名词指代的具体事物和规则。比如对新用户的定义,可能在电商是首次注册的用户;在O2O是线上或线下首次注册的用户。

同一事物名词一致。文档前后,不同的产品经理之间对同一事物的指代用同一个名词,否则其他人就会有疑问,到底是不是指那个呢?到底用哪个名词呢?比如说订单状态,待付款、待付钱,其实是一个意思,那就统一都叫待付款。全局替换下就可以。

4.2 重要规则

我们会把产品业务规则写在对应原型页面上,但这样就会导致规则比较零散,重要规则和普通规则混杂在一起,看起来比较累。可以把一些重要的规则提炼出来,首先和团队人员强调一下,这样大家都有了一个大的规则框架,后面沟通细节时也会比较容易。

比如这是拼团写的重要规则:

一文搞懂BRD、MRD和PRD,让你交付高质量原型

4.3 通用规则

一般是一些交互规则,在原型中,会遇到很多共用组件的情况,比如弹窗,角标。如果在每个涉及到的地方都写一遍交互规则,会让页面规则看上去很多,重点规则容易被忽视。可以在文档前面就描述通用的交互规则,后面用到的地方加个链接就可以了。

比如这是拼团的交互规则:

一文搞懂BRD、MRD和PRD,让你交付高质量原型

5、原型图

有的产品经理一上来就画原型图,然后画着画着就画不下去了,感觉逻辑走不通,前后对不上,页面上的字段也不知道放什么,画完后又发现很多细节都没有考虑到。

其实原型图是承接上面的项目介绍,功能框架和全局说明来的,这些事情都想清楚了,计划好了,原型画起来就简单了。这步主要是结合用户的特征和行为习惯,把功能用页面形象化、可视化地表现出来,告诉大家最终的成品大概是这样的。

有的产品可能会有疑问:要不要画高保真原型?如果是给内部人员看,不要!高保真原型会浪费很多的时间,实际上对于开发的帮助却很小,不如把时间花在其他值得地方。如果要给用户演示,可以视情况做的美观,详细一点。

有的公司交互配备比较好,产品只需要理出结构图,就可以交给交互出原型图了。但我还是建议产品画个大的框架,不用很美观、很详细,把页面结构,重点内容,页面间的联系画出来。因为很多时候交互没有直接深入过用户,没有产品了解用户的习惯,特别是B端产品。

5.1 原型规则

5.1.1 一个页面一个原型图

有的产品会把很多原型图都画在一个页面里面,用箭头标识页面之间的跳转关系。这样看上去原型图之间的联系是清楚了,但别人看的时候,要往旁边或者下面拉动,图一多都不知道哪里是终点,很容易遗漏一些页面。比如下面这样的:

一文搞懂BRD、MRD和PRD,让你交付高质量原型

建议一个原型图放一个页面,这样不会有遗漏的情况,开发一看侧边栏,就明白涉及了几个页面,也好评估工作量,合理安排时间。

5.1.2 站点地图

页面之间的跳转关系,可以加上跳转链接,AXURE里面直接拖动侧边栏到页面里面即可。如果觉得整体页面跳转情况不清晰,可以整体画个页面地图,只要说清楚页面之间的关系即可,不用画得很详细。

一文搞懂BRD、MRD和PRD,让你交付高质量原型

5.1.3 原型不要用截图

这是我踩过的一个很大的坑,因为在原来的功能上进行优化,图个方便,直接把线上的页面截图下来,放在页面上,然后写上改动点。当时是节省时间了,但下次再优化这个页面的时候,发现改动起来特别麻烦。所以长久来考虑,尽量用组件画原型。

5.1.4 页面旁边即标注规则

我们已经一个页面一个原型图了,旁边有很大的空间可以写上规则。原型上用数字标上注释点,旁边写上对应的规则。

一文搞懂BRD、MRD和PRD,让你交付高质量原型

要注意包含这2方面的规则:

功能规则

功能点名称及说明。功能点名称可以用醒目的大标题写明,就像上图的紫色主标题。这样在看原型图标注的时候,能立马明白功能点的目的,下面写上对应的总规则,这样看起来比较清晰,可读性强。

字段说明。建议把页面上的字段用表格的形式列出来,表格里面的字段可以根据业务需求来调整。这样子页面就不会乱乱的都是字了,看起来简洁明了,也不会遗漏一些字段规则的说明。

一文搞懂BRD、MRD和PRD,让你交付高质量原型

3 .异常校验。也可以用表格的形式来显示,表格里面的顺序也是校验的优先级,开发可以按着这个顺序来进行校验,看起来比较直观。

一文搞懂BRD、MRD和PRD,让你交付高质量原型

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质量。

产品交付完文档,是不是工作就完成了?当然不是,产品还需要关注整个项目流程,和不同角色的沟通合作,请看下章的讲解。

本文由 新媒体之家 作者:司马特小分队 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
0

发表评论