产品经理须知的三点用户需求分析

面对客户各种复杂多变的报表需求,我们如何能快速抓住要点,梳理出清晰的报表逻辑,从而设计出满足用户需求的报表,是产品人员在需求调研和分析中很重要的工作,本文把报表分析过程拆解成三个关键要素,帮助产品人员快速理解和掌握到报表分析的要点。

在我们的软件产品设计里面,报表很多时候是不可或缺的一部分,并且报表通常是管理者、高层领导要看的东西,是不是能很好满足他们的分析需求,往往对项目的成功起着重要的作用。

在今天的互联网产品里面,报表分析已经转化为日常的数据分析,成为产品运营的核心工作,所以,如何清晰的理解报表分析中的关键点,就显得尤为重要。

接下来,我们以某互联网产品统计工具的报表为例,来讲述报表分析的关键点:

1.  报表的三要素

要理解的报表的三要素,先上图:

如上图所示,每个报表都有三个关键要素:报表主题,报表指标,分析维度,我们逐一说明如下:

 报表主题

报表主题,很多时候你也会把它当标题看待,事实上我们也是以主题对标题来进行命名的。

但核心点是,每个报表主题一定清晰的对应着某个分析的目标,代表了客户期望从这个报表中获取到的信息,比如上图中留存分析,通常是基于客户想分析产品的使用情况,为版本功能优化、用户体验改版等提供数据支撑。

但很多时候,特别在一些 TO B项目里面,客户往往是直接告诉你我需要什么报表,背后分析目的和目标并不一定明确告知你, 这就需要我们在调研的时候,多问几句“您是用来做哪方便分析的,希望达到什么目标”之类的问题。

只有把报表期望得到的目标理解清楚了,你才能确定一个清晰的报表主题出来。

报表指标

有了报表主题后,很自然的,我们需要用哪些指标来支撑该主题的分析呢,还用上面的留存分析为例, 你看到,事实上是从4个关键指标来进行分析的:使用时长、使用频率、访问页面、使用间隔。

这4个指标从不同的方面来对用户使用产品的行为进行量化、从而帮我们对产品使用情况进行分析。

当然,具体在指标值上,可以有数值,也有基于数值衍生出来的各种百分比,如同比、环比、方差等等多种形式。

另外,指标还可以是复合指标的体现,比如对于绩效考核的得分来说,分值就是一个复合指标,而复合指标里面,还蕴含着子指标。

但无论是哪种形式的指标,关键点还是要想清楚,围绕着报表主题,我应该用哪些指标数据来进行衡量。

分析维度

有了报表主题,有了分析指标后,接下来就是分析维度。

上面的留存分析,初看过去, 好像没看到具体的分析维度,实际上因为这个报表相对简单,所以分析维度也比较明确,就是围绕着时间维度来开展的,而实际上对于留存分析,我们经常可以看到“日留存”、“周留存”、“月留存”,这里面的“日”,“周”、“月”就代表了三个不同粒度的时间分析维度。

从分析维度来讲,通常就是时间维度、空间维度,不同的维度支撑起我们对趋势、对发展分布、地域之间差异间进行对比分析,找出存在的问题点。

除开大面上的时间和空间维度,更细化的产品维度、服务类别维度等等对于更具体的定位到问题所在,有着重要作用;

更多的时候,我们还会对多个维度进行组合分析,然后找到其中的趋势、或者问题所在。

把握住了上面的三个关键要素,你也就能比较清晰的来设计一个报表的,但如何来展示报表了,这就是我们要说的第二点。

2.  报表展现形式

设计出报表了,该如何展示呢,报表的展示形式其实非常多,我们对常用的展示形式说明如下:

  • 折线图: 通常用于趋势的分析,所以其分析维度通常都是时间维度;
  • 柱状图:通常用于对比分析,如果趋势分析是纵向,那么柱状图就是横向的对比分析;
  • 点状图:多用于多个变量的回归分析;
  • 雷达图:多用于一个复合指标,存在多个子指标的分析展示;
  • 漏斗图: 销售分析的经典图,其主要用于来看转化率;
  • 饼图: 主要用于看各分支的占比分析,也是一种横向对比的展示;
  • 仪表盘:主要用于展示可以量化成分值类的指标,通常给企业高层管理者,喜欢这种仪表盘的展示,一是因为毕竟直观,二是因为仪表盘代表着一种企业驾驶、驾驭的感觉,所以很多人直接称这种图表分析的组合为企业驾驶仓;
  • 热点图:是参考气象云图的方式来进行展示, 通常用于展示有地域特征分布,并且实施动态变化比较快的数据;
  • 地图:使用地图来进行展示,通常都是和地域、地区统计分布相关的;

展现形式还有很多,在很多时候也会以多种形式来从不同维度、不同组合方面来展示数据,以求得更直观、简单的呈现数据的信息,实际中需要我们灵活应用;

3. 报表的穿透

有了报表的要素、报表的展示形式后, 为了实现某个分析目的,我们还需要考虑报表数据之间的穿透,穿透实质上有两个方向,一是纵向的穿透,一种是横向的穿透,用一句话总结是:横到边,纵到底。

对于纵向穿透,比如一个部门的绩效考核得分,90分, 你需要了解90分里面的各项组成指标的得分情况,然后你向下穿透,分布看到子项的:工作业绩完成得分、团队建设得分、成本支出得分等几个子项指标;然后可能这些子项指标还有进一步的子指标组成,你需要进行逐级的穿透,最后到每个人得分,每个人的指标情况,从而有效帮你从宏观到微观,掌握到整个数据的全貌和细节。

横向穿透,那即从对比分析方向, 看不同部门之间的、不同区域、不同产品等等方面上的差异,从而为你找到差距提供分析支撑。

综合以上,当我们在需求调研及分析过程中, 始终从报表的主题出发,抓住报表设计的三个要素,再选择好报表的展示形式,并做好报表的穿透分析,那么,报表需求和设计工作将变得不那么复杂。

我们结合一个“用户自助寄件”的需求,分析了从业务需求、用户需求,向产品功能需求转化的过程,本节,我们继续沿用该案例,向大家展示如何高效快捷的绘制出业务流程图。

在业务流程图的形式中,对于产品人员来说,最经典的莫过于“泳道图”,从百度图片里面搜集的泳道图说明如下:

(图片自百度图片中搜集过来)

泳道图之所以应用比较广泛,是因为其:

  1. 清晰的展示了该流程里面涉及多少个“角色”;
  2. 该业务流程分成了多少个“阶段”;
  3. 角色活动的边界、流向清晰;

但一开始要直接来绘制泳道图,我们总觉得比较复杂,好像有些无从下手,又或是担心漏掉很多细节,那么到底如何有效的绘制出一个清晰明了,简单实用的泳道图呢?

下面我们以“用户自助寄件”的案例来进行说明。 (该案例来自上一节的连载文章,建议可先查阅上节的该案例:需求分析篇|从实例分析中理解业务需求、用户需求、功能需求的转化

第一步:将业务分拆成多个阶段

用户自助寄件是一个业务,你也可以理解成一个任务,那么在自助寄件里面,大致可以拆解成几个阶段呢,在上一节里面,我们已经知道,可以拆解成三个阶段:

  • 阶段1:在线填单阶段
  • 阶段2:找柜子放件阶段
  • 阶段3:支付阶段

具体阶段应该怎么拆,如何拆得比较合理,其实还是在于我们对业务流程的理解程度,我们在调研和需求分析中,是不是真正将业务场景、用户场景理解透了。

通常对一个任务的阶段拆解,你可以从任务执行时间上进行拆解,比如这个例子,填单和找柜子放件,是有时间分隔的,因为往往并不是填完单马上就会去放件。

然后,你可以从任务执行的位置、操作对象上来进行分割,还以填单和放件来说,地理位置上变了,特别是操作对象上变了,那么也是适合拆成两个阶段。

事实上,对任务阶段的拆解,你更多的是从时间、地理位置和操作对象几个维度上的不同来最后确定要区分几个阶段。

当然,一开始分得不合理也没关系,因为对阶段进一步细节分解、梳理过程中,会帮你发现不合理的地方,然后你还可以继续修正。

那么,当你第一步进行了业务的阶段拆分后,其实你可以简单的绘制阶段流程图,示意如下:

这个很简单,我们接着往下说。

第二步:阶段内各角色流程活动的梳理

有了第一步的分阶段,我们需要对每个阶段的细节内容进行梳理,阶段细节的梳理,其实要弄清楚的这里面会涉及那几个角色,这里的角色,不仅仅指用户,系统或者某个实体作为和任务有交互的地方,都是一个角色。

以“在线填单”为例,这里面有那几个角色呢,首先,肯定有:

  • 用户角色:就是自助寄件的人;
  • 系统:在线填单后,系统要接收处理快递单,肯定也是一个角色;
  • 快递柜:是用于用户后续放件的地方,它也是一个角色;

这个案例里面,主要是这三个角色;有了角色后,那么我们就需要对每个角色,在这个阶段里面的具体的活动来进行整理。

在“在线填单”的阶段,任务的发起角色是“用户”,主要的活动也是他来触发的,所以,我们肯定要从用户这个角色开始梳理他的阶段内的活动。

那么用户在这个“在线填单”里面都需要执行哪些活动呢,其实联系现实中寄件填单过程,你很快就能理解到用户主要有“填写收件人信息”、“填写物品信息”、“寄件人信息”、“需要的柜子大小等”,整理成流程图,就是这样:

这个流程图里面的活动,其实都是蛮容易就能想到,唯一刚开始可能缺漏的是活动“4”,但其实一开始有缺漏没关系,后面进一步的分析会帮你发现这个缺漏。

理完用户这个角色,那么接下来要继续梳理“系统”这个角色流程活动。

很显然,用户在线填完单后,系统要接收该快递单,要考虑分配怎样的柜子,以何种方式来让用户找到柜子、开启柜子等内容,那么你会逐步梳理出系统的流程活动是这样的:

其实系统的活动也还蛮简单,也是只有5步,梳理完系统后,还有快递柜,显然,快递柜的位置和空闲状态是由快递柜本身的系统来返回的,它的流程图我们在这里暂略,在后面的总图中会看到。(需说明的是,实际上快递柜和快递公司,由于不是一家公司,所以,这里面快递柜是一个独立的角色)。

按照角色梳理完阶段内各自的活动后,接下来就是整合的操作。

第三步:使用泳道图来整合各角色的流程活动

有了上面的各个角色的阶段内活动图后,我们这个时候来把它们整合成泳道流程图,显然就很容易。

还以自主寄件中“用户在线填单”为例,最后整合出的泳道流程图如下:

看起来这个流程图一眼望去还是比较复杂的,但其实如果你按照上面的三步:

  • 第一步,将业务分拆成多个阶段;
  • 第二步,阶段内各角色流程活动的梳理;
  • 第三步,使用泳道图来整合各角色的流程活动;

你一定可以比较轻松的完成整个业务流程图的绘制。

当然,在具体的整合过程,以及整合后,我们还需要对很多细节进行推敲,完善,很多时候也不是一次性就完成的,这里面还有很多正常、异常的情况需要去考虑,但有了上面的基本方法,你的框架定下来了,细节逐步去完善就不会很难了。

 

在产品的需求里面,经常有这三个概念:业务需求、用户需求、功能需求,但往往,我们很容易搞混,不清楚他们之间的关系和差异,我们先引用一下比较官方的解释:

业务需求( Business requirement )表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。

用户需求( user requirement )描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求( functional requirement )规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求

这个解释其实还是蛮明确的,其实理解这三者的关键点,是要先认清楚每个需求针对的对象不一样:

  • 业务需求———对应的是组织或者客户,实质就是业务的建设方;你也可以类比房地产市场的开发商;
  • 用户需求———对应的是使用产品的用户;你也可以类比买房的人;
  • 功能需求———对应的是产品,即产品要具备怎样的功能,才能满足相应的业务需求和用户需求;类比房地产市场,那就是房子本身。

类比成房地产三个角色后,你发现,开发商通常的诉求是想多赚钱,买房的人诉求是买到物有所值,甚至物超所值的房子;但不管二者怎么想,最终都是需要通过房子来实现,必须建设的房子的属性达到某个标准才能满足二者的诉求;

所以,这么一看,你就明白了,其实这三者之间的关系是:

即,业务需求和用户需求,只有经过需求分析的转化,变成产品的功能需求后,才能得到实现。

需求实例

接下来,我们用一个简单的实例来进行说明:

案例:用户自助寄件的需求

业务建设方:某快递公司

需求描述:目前很多城市的小区都已经有了快递柜,但快递柜主要是用于送件使用,而对于快递公司收件,用得比较少,某快递公司,就希望利用快递柜,来实现用户自助寄件的需求。

首先,我们来分析其业务需求

这个案例的业务建设方是:快递公司,其业务需求也很明确,就是:用户自助寄件。

业务方之所以要建设这个需求,其目的是:希望利用快递柜,实现更高效的收件服务,减少人工上门收件的等待、低效、人力投入成本高等问题。

其次,我们来看用户需求

这个案例的用户,就是每一个要寄快递的人,那么他们的需求是什么了?

他们的需求,其实就是在进行“自助寄件”的过程中,你尽量让我简单、易用,高效、快捷。

接下来,我们进行需求分析的转化

需求分析的转化,核心是两个点,一是对这个业务的场景进行充分的理解和认知,二是想明白业务场景中需求点,要通过何种方式来满足它。

业务需求是“用户自助寄件”,这个业务要实现,我们结合寄快递的实际场景,其实还是蛮容易就能想到,有3个关键环节:

  1. 用户要填写单据:即填写收发件人的相关信息;
  2. 用户要能找到周边的快递柜,并且能打开它;
  3. 还需要进行计量、支付快递费的问题

这三个环节,基本把这个业务的三个关键阶段说明出来了,它就是:填单——>找柜子放件——>支付。

然后,逐一对三个阶段进行具体的分析:

填单阶段:

  • 业务方需求:必须收件人、联系电话、寄件人信息清楚、明确等等。
  • 用户需求:能选的就选,能简单填写的就简单填。

转化为功能需求,你发现,无非是通过表单形式让用户把相关信息填上来,而为了满足用户需求,你肯定需要设计对收件人的记忆功能,让用户填写一次,后续每次只需要选择而已(相关的细节还很多,这里只做举例)。

找柜子放件阶段:

  • 业务需求:把最方便最合适的柜子告诉用户,并确保用户能安全、准确的找到快递柜、放入快递件;
  • 用户需求:我就想知道我要把快递件放到哪里,别让我多走;

这个业务需求和用户需求说起来简单,转化成功能需求时,其实里面还蛮多细节的:

  1. 位置服务肯定需要,一是为满足发现柜子的需求,二是也有导航的需求;
  2. 如何打开柜子呢?从我们的产品经验或者竞品参考来看,可以有扫描开启、验证码等方式;
  3. 如何保证用户去到快递柜,一定就有其空的柜子可以给他放了,这里面就涉及一个快递柜忙闲资源的管理;

所以,这里转化为功能需求时,你发现:有位置服务功能、扫描开启/验证码开启功能,柜子资源分配管理功能等;

支付阶段:

  • 业务需求:根据收费标准,准确无误、及时收到用户快递费。
  • 用户需求:支付方便。
  • 功能需求:
  1. 如何来计量,由于是自助寄件,称重显然不合适,那么按体积是一种较简便的方式,而如何按体积了,其实根据可快递柜的柜子;
  2. 如何支付,这个还简单,可以使用比较常用的几种支付方式就好;

以上,都只是简单的需求分析和转化的过程,实际的需求过程中,我们经常讲需要结合业务场景、用户场景把一些关键细节挖掘出来,并能在产品设计时考虑进去,以给用户一个良好的体验。

业务场景细节的挖掘

比如:在上面的开启柜子的方式中,到底用扫描开启还是验证码的方式呢?

其实用“验证码开启”会更合适,因为会存在很多这样的场景,某个寄快递的人,刚好家里有人下楼,或者认识的邻居下楼,而快递柜就在小区门口,那么找人代劳一下放件是一种很正常的事情,那么这时候,使用验证码就是一种最合适、简便的方式。

又比如:某用户希望自己的快递能更快的被寄出去。

那么,如果在给用户呈现周边分布的快递柜的同时,还告诉用户,该快递柜的收件时间,目前快递员的分布位置,是不是能让用户更好的去选择呢。

这样的细节还很多,需要在实际分析中,更好的去理解用户场景、挖掘细节,并逐步的完善。

通过上面的分析,我们发现,只要你充分认清楚业务需求方的诉求、用户在执行具体任务时的诉求,并对产品的常规实现方式有了解的话,需求分析并不是一个多复杂的过程,就是这么一步步去推理、去转化的过程。

而要把每个细节做透,就必须在实际中多去磨练,在生活中多体验,学会场景化的思维方式。

 

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/497.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息