【专题】一个产品经理在原型设计上的一些想法(3)产品经理交付给实现部门的是不是只有原型就可以了?(含结束语)

我们这些产品经理知道,原型是用来更好的配合PRD来表述产品介质层面的需求的,也就是说,PRD才是我们应该交付给技术实现部门的最关键文档。

因此,要回答第三篇中的问题,那么,其实只要我们确定了PRD中都应该包含哪些内容就可以了。

说来也巧,在我开始准备写第三篇文章之前,正好有个朋友给我转发了一篇文章,内容就是关于某APP的PRD的,朋友问我,这个PRD是否合格?

我大概看了一下这个PRD的结构,怎么说呢,你说不合格吧,但是现在很多产品经理就是这么去写的,你说合格吧,但是至少对于我来说,还是认为并没有全面的说明一个产品介质应该包含的需求内容。

当然了,也不能说我的评价就一定是对的,咱们得讲理,是吧,因此,咱们还是先分析一下一个产品介质都可能产生哪些需求。

对于任何产品来说,无论是软件、网站,或是汽车、飞机,其实都离不开三个因素的影响:

1、产品介质本身

2、产品运转的环境

3、使用产品的人

其实理解了这一点,我们就可以确定PRD中的需求关注原则,就是:基于产品运转环境而出现的人和产品介质之间所形成的需求。

那么,基于这个原则,可能出现的需求都有哪些呢?

我来举一个例子:

比方说,我是一个糖尿病患者,经常要使用血糖仪,那好,我们可以这样来分析:

1、血糖仪是产品介质;

2、我是使用血糖仪的人;

3、我使用血糖仪是在一定的环境下。

那么,假设你现在是某血糖仪企业的产品经理,那么,你会考虑存在哪些需求呢?

首先,你一定会想到的是血糖仪这个产品介质本身的功能、性能、流程、外观这些需求,比方说,在功能上,你会考虑需要记录多少条测试值,是否需要进行阶段性血糖值的均值计算等,在性能上,你会考虑多长时间显示血糖值,5秒、10秒还是20秒,在流程上,你会考虑是插入试纸自动开机,还是开机后再插入试纸,在外观上,你要考虑用户一般是手持测试,还是放在桌子上测试,如果是手持测试,那外观设计上就要符合人体工程学,并且还要考虑材质,因为用户可能会存在不小心掉落的情况,如果是放在桌子上测试,如何保证血糖仪的平稳,当然,如果你要考虑两种情况都存在,那么就更得考虑一个兼顾的外观方案出来。

我想,很多产品经理可能认为把这些考虑到就可以了,但是真的够吗?

别忘了,任何产品最终都是用户要去用的,那么,用户在使用产品的时候,会不会有非产品介质层面的需求存在呢?

肯定会有了,最直接的就是你必须得有一个帮助文件告诉用户如何使用你的血糖仪,这个大家应该能理解,但是,这还不够,如果用户在使用过程中出现了一些问题,那么,用户该如何和你的企业进行沟通呢?

这就需要你考虑通过什么样的形式来解决这个问题,是客服电话,还是网站论坛,或是公众号,还是小程序,还是邮件,等等,如果你是个新的产品,而现有的体系或形式并没有纳入你的新产品,那么,你是不是需要想好后告诉实现部门去做呢?

你可能会说了,这个有专门的人在做,这样是没问题的,但是,我要强调的是,如果你不把明确的非产品介质的需求告诉具体操作的人,你怎么确保对方是按照规范和标准在做呢?

我记得我最早做产品经理的时候,仅仅在做帮助文件的时候,就有一个多达50多页的帮助文件撰写规范,里面明确了印刷版和电子版(CHM)帮助文件所有的规范,已经具体到标题用什么字体,多大的字号,颜色,间距等。

我以前在写PRD的时候,一定会明确这个的,我把这些需求称之为“产品发布需求”和“产品文档说明需求“。

而这些和产品介质发布有关的介质,就构成了用户和产品介质之间的一种间接需求,但基于这些需求所形成的产出会让产品介质本身更加丰满和完善。

好,产品介质,用户可能出现的需求都有了,那接下来就是用户会在什么样的环境下使用产品,而对于某些产品来说,使用环境会影响到产品的使用效率和效果。

比方说,血糖仪配套的试纸,厂家要求的试纸使用环境的温度是在10-35度,如果不在这个范围呢,不是说试纸就不能用了,而是测试结果可能会出现偏差,因此,作为产品经理,为了保证用户能测出一个准确的值,那是不是要说明这个需求呢?

尤其是一些必须依赖于某些环境才能运转的产品介质更是如此,软件,互联网产品,都必须基于硬件和操作系统才可以,那么,你在考虑产品介质需求的时候,难道不需要考虑这些运转环境对你的产品介质可能产生的影响吗?

比方说兼容性,就以axure为例,同样是rp文件,7.0就打不开8.0的文件,而在7.0中,3190这个版本就对之前的一些版本中的格式和字体支持的不太好,这样你让那些升级了版本,但是已经用老版本所做的RP文件的产品经理怎么搞。

我现在就是7.0和8.0两个都装了,没办法啊。

除了产品版本升级可能出现的兼容性外,还有一些硬件和第三方软件可能会对你的产品介质产生影响,这个我就不具体说了,大家应该都有一些体会的。

好,咱们先总结一下,基于产品介质、人、环境,已经产生了哪些需求呢?

1、功能需求

2、性能需求

3、外观(界面)需求

4、流程需求

5、产品文档需求

6、产品发布需求

7、兼容性需求

还有没有了呢?

当然可能有了,如果你的血糖仪是同时面向国际市场的,产品介质本身不会变,但是比方说在菜单上需要变成英文,那你就得准备一个”词典“来说明标准,我把它称为是”扩展需求“。

如果你做的是一个2B的产品,并且产品很复杂,需要培训客户企业的使用者,那就又涉及到了产品的使用培训,我把它称为是”支持和培训需求“。

除此之外,如果你的产品涉及到的是多个平台,那你就要对开发人员说明要基于哪些平台来做开发,在开发的时候,要优先保证哪些,我把它称为是”开发需求“。

我以前接触过的,需要产品经理来明确的需求就是这么多,汇总一下,见下表:

咱们再回到开篇时提到的那个APP的PRD,从内容中我可以看出,这个PRD就是基于原型的扩展,仅仅是包含了功能、外观和流程,如果对照上表,也就是完成了不到三分之一的需求内容而已。

而我们似乎应该记住,你负责的产品永远是一个用户在一定的环境中使用的,抛开用户和环境只考虑产品介质,至少在我看来,是远远不够的,尽管上表中有些需求内容是比较简单的,但是简单并不意味着不应该去规范。

当然,如果只写功能、外观和流程,可不可以?可以,不过那样形成的文档,通常就不叫PRD了,而是叫FRD(Function Requirement Document,功能需求文档),而PRD,产品需求文档,要涉及的内容要远远多于FRD。

不过我还是要多说一些,PRD我们所体现的产品介质、人、环境的需求,在一个真正意义上的产品经理看来,还是不够的,或者可以这样理解,PRD通常交付给的是技术实现部门,而我们别忘了,你的产品在做出来后,还需要拿到市场上去实现价值交换,那么,用户对于这个价值交换的过程一定也会出现各种各样的需求,比方说价格上的,渠道上的,推广上的,服务上的等等,而这些难道不也是我们这些产品经理需要去考虑的吗?

有些朋友会说了,你瞎说,我从来没考虑过这些,抱歉,不是我瞎说,而是你一直就不是一个真正意义上的产品经理,事实如此,就是这样。

结束语

为什么突然想起要做这个系列呢,一是因为在前言中提到的原因,二是因为我也很长时间没亲自做原型了,怕生疏,就练练手,在网上查资料的时候,看到很多产品经理都在询问原型制作的各种技巧,而很少有人问产品经理和原型之间到底应该是什么样的关系,因此,我就想到是不是需要写一些东西来说明一下我的观点。

在这个系列中,我要表达的其实就是三个观点:

1、产品经理一定会涉及到原型,但是,如果公司有原型师,那么,产品经理就需要明确原型的设计需求,如果没有,那就需要产品经理亲自去做了。

2、如果是产品经理去做,那么,不要把原型当成是万能的,对于技术实现部门来说,他们对你提供给他们的产品的阅读需求是:越容易理解越好,越容易阅读越好,越容易沟通越好。

3、作为一个产品经理,必须要明白的是,即使只是在PRD中,产品要涉及的需求类型也是很多的(产品介质、人、环境),原型能表现的需求就是那么几类,而其他的需求依然需要PRD去承载。

分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址