如何写好PRD?站在用户角度是关键

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

常常有人问我怎么写prd,在深受市面上流行的功能需求模板“残害”之后,我现在一般不会向别人推荐任何所谓的“模板”。

PRDwendang

需求文档是产品需求的表达方式,而其中需要描述什么内容取决于产品经理想要描述什么,即产品经理的需求。如果产品经理的需求是明确的,而且产品经理脑中有物,那么需求文档自然而然就出来了。最可怕的是产品经理自己都不知道自己要描述的是什么内容,这个时候即使有模板,写出来的东西也是一团糟。

互联网产品以用户为中心,所以prd也应该站在用户的角度来描述,如果不知道自己要写什么,在写文档之前产品经理可以先问问自己以下4个问题:

  1. 用户需求是什么?
  2. 通过产品,用户能得到什么?
  3. 如何满足不同用户的使用场景?
  4. 产品应该做什么?

这四个问题凝聚了End2End思想的核心,站在用户的角度给需求,在Jesse James Garrett的《用户体验要素》一书中,被分别称为范围层(问题1,2),结构层(问题3),框架层(问题4)的用户体验。

一、用户的需求是什么?

按照需求出生的先后排序,需求分别是:

  1. 用户需求
  2. 功能需求

即先有用户需求,才有功能需求。此文开头已经提过,笔者曾受功能需求模板误导,所以下文中仅描述用户需求。举个例子,用户希望买到物美廉价的商品,那么对于用户而言,用户需求其实就是以下几点:

265765-fb9e97b8fbf7f990

如果是B2C平台,还得考虑到B端用户的需求,那么用户需求列表就是:

265765-c5ff5bb7f3995ce3

二、用户可以得到什么?

这个问题,其实也是思考产品的有用性,即产品这么做对用户能产生的价值。

在上面这个B2C电子商务平台的例子中,B端用户通过在系统中发布商品,供C端用户购买,可以给B端用户带来收益,加入了优惠券之后,B端用户在系统中发放优惠券,系统通过优惠券可以刺激C端用户消费,此时B端用户给C端用户提供了折扣,拉动消费后C端用户会给B端用户带来更多的收益,图形化后的表达为:

265765-7097e9b0b250cff2

更精确地,上图可称为用户价值链

三、如何满足不同用户的使用场景?

满足不同用户的使用场景,又称作用户场景分析

接着上面的例子,在用户的两个需求中又包含了不同的场景,其中商品需求的场景包括浏览、下单和付款,优惠券需求的场景包含了获取和使用,于是用户场景(use case)主要表现为:

265765-db9aee303aad2b6b

发布商品是对B端用户而言。

浏览商品这个场景中,不同的用户有不同的使用场景。一部分用户是有目的的,他们知道自己想要的东西叫什么名字,可能只是想知道在这个产品中该商品的价格,所以产品需要提供搜索功能来应对这种用户场景。然而大部分用户都是无目的浏览,为了满足这种用户的需求,只需将商品罗列出来就好。电商平台常见的分类展现、价格范围等等功能都是为了满足介于有目的和无目的之间的用户场景,分析方法类似,此处不再展开描述。

浏览商品之后是下单,有的用户习惯把看起来觉得还不错的商品全部放在一起,先比较比较,再决定是不是要购买,有的用户属于冲动消费或者消费目的明确,这些用户通常看到一个商品觉得还不错,就直接下单了。所以下单这个场景,又有两个用户场景,一个是添加到购物车再下单,一个是直接下单。

最后是付款,付款的方式有多种,有的用户喜欢用支付宝,有的喜欢用微信,有的喜欢用银联等等。这些场景都是现实存在的,但是产品经理需要过滤哪些场景是频繁的场景,哪些是不频繁的。比如,如果这个B2C平台是建立在微信上的,那么用户用支付宝和银联付款的场景就显得很弱,如果是淘宝或者天猫,毋庸置疑,支付宝一定是频繁场景,如果是独立的电商平台,那么可能以上几种场景都需考虑在内,甚至还需要再多加入几个支付场景。

优惠券为大家所知,获取的途径通常有两种,一种是系统发放,一种是主动领取。

通过以上描述,不难得出以下用户场景分析图:

265765-68180c0a00715f2c

四、产品应该做什么?

描述产品应该做什么的过程,是prd最核心的部分,也是研发人员最关心的部分。因为只有研发人员看了到产品应该做什么,他们才知道自己应该怎么做。

互联网产品重交互,所以用户与系统之间的互动是最好的描述方式。在测试中有一种方法被称为黑盒测试,用在这里,再合适不过。简单地说,就是用户输入什么,系统输出什么,即:

265765-3e56947c4de63d5a

左边一列描述用户的动作,一行仅与用户的一个动作关联,右边一列描述对于用户的这个动作,系统做出什么样的反应,包括达到什么页面,展示什么信息或者跳转到哪个页面。

结合我们的例子,由于这个例子中有“两个”用户,我们的C端用户和B端用户,所以表格需要做一点小改造:

265765-c7f5a12c93f9ebb0

以其中B端用户发布商品和C端用户搜索商品为例,展开描述,可得到如下用户事件流(user story):

265765-e658378ff7d77ab5

将其他场景拓展开之后,prd文档基本完成。在此基础上,不管系统应对的用户多么的复杂,都可以自如地化繁为简。

#专栏作家#

康小胖,人人都是产品经理专栏作家,产品经理。专注专注O2O电子商务,坚决拥护用讲故事的思维做产品,关注电子商务及移动互联网,爱好圆珠笔涂鸦。

本文系作者独家授权发布,未经本站许可,不得转载。

您的赞赏,是对我创作的最大鼓励。

评论( 9

登录后参与评论
  1. M-PRD

    回复
  2. 这个不应该是PRD的思维逻辑啊,定义为MRD的思维逻辑还差不多。

    回复
  3. prd是给苦逼的程序看的啊。站长用户的角度写的,我认为没有几个程序员会去看吧。。。

    回复
  4. 【此文章不会给PM有所帮助!反而会造成困扰!!!】prd给开发,给设计看的,围绕用户写,程序员怎么办?分析用户是写prd之前的事情,分析用户需求等等。万不可和prd混为一坛。

    回复
  5. 文章写的不错。但很不认可这个标题。
    我们思考的过程、策划的过程,肯定要更多的从用户出发。但现在是写prd,是给程序员看的,我们更应该去符合程序员的思路和代码结构去写。

    回复
    1. 回复

      我也是这么觉得的!

    2. 回复

      其实呢,如果最后一步写得够详细,把流程细节都描述清楚,开发基本已经能看懂了,这种做法的好处,是让研发不仅能知道要做什么,还能知道为什么要这么做。团队合作的风格因人而异啦~ :grin:

    3. 回复

      那是不是应该是MRD该做的事情?

    4. 回复

      产品是给用户用的,prd的用户是程序员,prd指导程序员开发出用户使用的产品,有点绕啊,那pm写prd是一件什么事儿

加载中