• 精选
  • 会员

用户故事地图的实战案例

2019年5月31日  来源:水伯 作者: 提供人:zhebei45......

用户故事地图如何在需求拆分过程中保持全景视野?


复盘:某蚁金服使用用户故事地图的实战案例

用户故事地图虽然是一个耳熟能详的体验工具,但事实上当你接触的时候才知道并不容易。其中需要注意的要点很多,能找到的模型也很多样,导致做一个正确的方向变得复杂,结果可能会产出一个适得其反的用户故事地图,或者什么都没有产出,那我们到底该怎么做呢。某蚁金服在实操项目的过程中,初期会选择采用「故事编写工作坊」的形式来梳理产品的用户故事地图。一般是项目组成员共创的形式,参与人员包括:技术开发、产品经理、项目经理、设计师、用户、产品老大。重要流程分成四个步骤:

-产品定义;-梳理骨干故事;-拆分故事;-沟通确认。

1、产品定义

一般是在「故事编写工作坊」准备阶段,首先由PD提主导产出,主要有几点内容:

1)产品的目标用户;2)解决了哪些问题;3)用户目标;4)产品目标;

将这些内容记录在黑板上,与大家讨论达成共识,最终确定产品定义。简单来说,需要明确:

「我们为什么要做这个?」以及「用户为什么要用这个?」

明确业务诉求和用户诉求,为之后的设计提供了指导,不仅可以在接下来讨论的过程中不易迷失方向,还可以避免陷入设计细节的纠结。基于业务诉求和用户诉求其实就是为了不忘初心,是为了明确设计的初衷。所以,在做交互设计之前,一定要问自己这两个问题:

「这能给我们带来什么价值?、这能为用户提供什么价值?」

这一步可以让项目组内所有人和用户共同明确产品覆盖的整个范围。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

2、梳理骨干故事

在这里以一个大家生活都会发生的事情为例。故事的整个范围:起点是起床——终点是到达公司。闭上眼睛,回想一下今天早上起床的过程。把这段故事分成这样几个阶段:起床——洗漱——穿衣——出门——上班途中——到达公司。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

在真实过程中,大家在这一步可能会写出不同颗粒度的故事,需要设计师把控故事的大小,这段故事可以再往下梳理一层颗粒度更小一点的故事。比如起床就可以再拆分为:闹铃响了——挣扎——关闹钟——下床。剩下的故事卡片都可以继续这样拆分归类。这样我们骨干故事就有两层:一级故事和二级故事,故事的发生从左至右是一个叙事流。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

这里需要注意的是,在真实业务中,故事的流程不可能是一帆风顺的,情况会变得复杂,我们可以借助流程图的图例线连接我们的故事卡片。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

总结一下,首先,我们在第一步确定产品整体范围之内尽量的把故事讲完整,比如我们这个例子,起床——洗漱——穿衣——出门——上班途中——到达公司。这样我们项目组的所有人就可以对整个产品有个全局的印象。其次,我们需要注意是要讲完整的故事,但是一定要广度优先,而非深度,要做到一公里宽一厘米深。比如刷牙这个故事里面,找牙刷、挤牙膏这类故事在这个阶段我们无须关注,不要过早的沉浸到细节中。在这步让大家做到对产品只见森林不见树木的状态。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

3、拆分故事

在这一步,需要在刚刚梳理的每一个二级故事下面做停留,去拆分二级故事获取更多细节内容。如果二级故事是一个海平面的话,那二级故事以上就是海平面故事,那现在需要关注的是海平面以下更多不可见的故事。项目组围绕这个故事写出很多细节来。可以按照以下几个维度对细节进行归类,分别是:故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得,也可以通过用户想法、用户的痛点结合主观判断。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

在这个过程中,先让大家在一定时间内按照自己的想法写出来,每一条写在一张卡片上,做到相互不干扰,然后每个人出声说出自己的卡片内容,让所有人了解并贴在墙上。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

项目组人在写想法的时候,相当于脑暴的过程,这时可以通过一些问题来刺激大家脑暴出更多的内容,比如:

-用户在这步具体做什么?

-用户还有其他选择么?

-用户怎么做才能更爽?

-出现问题如何处理?

-其他用户来到这里该如何处理?

回到实例,我们洗澡的时候有正常的流程,但当没有热水时这个流程就会发生变化。同样,在真实业务当中,这类情况将更普遍的发生,所以这一步我们将尽量多的关注到所有场景的故事。做完这步,我们已经获取到了足够多的细节信息,整个项目组都会做到对产品又见森林又见树木的状态。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

4、沟通确认

这里故事已经变得很丰满,甚至变得臃肿,所以沟通确认变得极为重要。我们在这步需要花费相对多的时间,大家对内容进行对标、充足讨论,把公认的留下来,无用的剔除掉。同时可以区分要做的故事细节的优先级。依次类推,当所有故事梳理完成之后,就完成了如下这样一张完整的用户故事地图了。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

总结一下。首先,我们需要对大家写的所有卡片进行对标,排除无效故事。其次,因为我们一般项目时间不够,开发资源紧张,不可能一口吃个胖子,所以把要做的事情达成共识排出优先级变得尤为重要。最后,并不是所有的故事卡片都需要在同一时间细化,在真实业务中有些模块的故事是无法一开始就梳理清楚的,所以可以先写个占位符,待合适的时机再做拆分。我们通过这种一目了然、格式一致的故事地图,让项目组所有人都获得足够的信息,让项目有一个明朗的开发流程。

说人话、少吵架!被姐夫(Jeff)称为共情雷达的用户故事地图火了

彩蛋:关系=信息;公众号:SFA-0002

一个女孩与一个男孩相亲,简单地收集数据的做法是问“你有多少存款啊?你有房吗?有车吗?月薪多少啊?“但这些数据只能代表这个人,作为当下这个“点”的截面特性,你能根据这些数据做决策吗?你知道这个人经历了什么,才成为今天的样子吗?

每个人对这些数据的解读,肯定是不一样的,而且各有各的道理,各有各的逻辑。大家拿着数据和逻辑PK,其实很难有说服力。量子物理中有个定义很有趣,关系=信息。如何判断你跟一个人关系好不好,无非就是你知道多少他的信息,以及他的最新动态信息会有多少跟你同步。所以一个好产品是从“第一只羊”被真正被满足开始的。我们充分认识这“第一只羊”,能够完全用他的语言说话,你需要了解他的故事。一个好产品,是从一个好故事开始的。

-End-

故事地图 / 共情雷达 / 同理心 / 需求拆分 / 商业画布 / 价值主张 / 用户画像 / 优先级 / 实例化需求

如涉及版权,请著作权人与本网站联系,删除或支付费用事宜。

0000