30分钟用脑图列出用户故事

随着互联网+各行各业的深入发展,互联网产品经理也在持续的向其他行业溢出。这也对产品经理的能力提出挑战:经常会遇到陌生的业务领域(2B产品更甚)。

对于这种新业务领域,产品经理在不了解商业模式、业务流程、不了解功能范围,怎么切入?这时可以试试花个30分钟,列举一个全局的用户故事脑图,它能帮助你快速建立对业务的商业模式、范围、流程、人员角色、各自需求的思考。

开始之前

我们知道,通常可以使用四个问题,来控制产品的思考范围:

谁是核心用户

他什么问题备受困扰

我的产品能如何解决

为什么是我们来解决,而不是别的产品

这几个问题问完,我们的产品就有一个大致的范围概念了,那么接下来怎么分析、分解呢?总有一种千头万绪无处下手的感觉。这时就可以考虑用户故事了。

为什么需要用户故事(或者至少用户任务)

用户故事的开发方法是跟随敏捷开发产生的一种需求分析、产品分解落地的方法。传统的敏捷开发会通过用户故事看板工具,来解决了团队一致性的沟通问题、产品的分版本、分阶段落地等问题。

而现在,为了能帮助自己梳理思考问题的逻辑链条,辅助后续工作的思考,可考虑将用户故事看板简化为用户故事脑图。作为用户故事看板的轻量形式,用户故事脑图在使用的过程中,可以让我们所有的功能都有场景、有依据,从而减少在产品设计阶段伪需求的产生。

再多轮业务的使用中,我认为它是一种独立建立角色设定、明晰场景、分析需求的一个很有效的方法。能够为后续的产品业务架构设计、产品迭代规划等提供高效的指导。

30分钟的时间,我们来看看怎么做一个有效的脑图用户故事

如何做脑图用户故事

常规单条用户故事的结构一般是:

我是XX【某个角色】,当我在XXX【某个场景】的时候,我希望能够XXX【做某件事情】,因为这样我就能XXX【实现某个目的】

当所有的用户故事罗列完成后,根据不同的角色、场景、任务之间的重要等级、关联和依赖程度去做功能开发的取舍、阶段版本的定义,从而推进到后续的产品设计、研发以及线上验证反馈阶段。

而脑图的用户故事中,因为是给自己做思路梳理的,所有它可以根据实际情况做简化。通常我会至少保留用户故事的基本结构,其他的信息在根据需要,做针对性深化。

另外,在做用户故事梳理还有一个原则,即:梳理阶段,只考虑用户与场景的需求,不考虑技术实现路径。

脑图用户故事的层级结构

我所使用的脑图用户故事的结构层级如下:

第一层 典型角色

第二层 典型场景(或者叫用户行为、骨干故事)

第三层 典型的用户任务

有些人会在用户任务下再细分一些更细致的用户故事,不过我感觉自己用到第三层次已经可以了,就没有再细分。

第一层 典型角色

举个例子,假设我们要做一个餐饮点单的产品,应该怎么来列这个脑图用户故事呢?

首先来看典型用户。所谓典型用户就是和这个产品有关联关系的角色,通常会有直接角色和间接角色。

在餐饮点单系统里,点单肯定会有的角色就是 顾客和点单员(也可能只要顾客就行了)。

点单前和点单后会涉及到的角色,比如 点单后的主厨角色、配菜角色、上菜角色;以及点单之前的迎宾角色等。

这样其实我们能看到,直接的角色就是顾客和点单人,其他人可以被视为间接角色,这样就可以在列角色的时候顺便把他们的重要等级也思考一下了。(当然脑图里可以不体现)。

命名可以使用“我是XX”做假设引入。注意,这个假设在思考过程中很重要。

这一步的原则是有多少和系统产品有可能有关系的角色都罗列,也许某个角色后续分享下来没有使用场景,那么后续即使空着也无妨。因为这样可以让你的思考更全面。毕竟:做不做先不管,产品得先想到是不是~

第二层 典型场景

这里叫用户行为&场景&骨干故事,都行,随便你怎么叫。它的核心就是描述某个角色在和产品交互时的所有场景的划分。

这里要注意划分的分类必须时单一维度上完全分类,需要确保在这个维度上的所有场景都要有。比如常规的划分方法可以按生命周期、过程时间线等。

回到顾客点单场景,典型用户是顾客,那么如何做全顾客的场景?这时我们就可以考虑吃饭决策的全生命周期了。具体就是:

不饿->饿了->进店->点单->等餐->就餐->结账->离店

做为示例,这里简化了很多决策环节。(比如进店前还有叫外卖等决策的可能)

那么它的典型生命周期全场景就是:

当我不饿的时候

当我开始饿的时候

当我进店的时候

当我点菜的时候

当我等菜的时候

当我就餐的时候

当我结账的时候

当我离店之后

注意这里的格式时:当我XXXX的时候

当然根据业务情况也可以简化,比如这里我们的产品重心并不是所有场景完全发力,所以就可以根据情况做一下非重点场景的合并调整,如下:

第三层 典型用户任务

这里就到了这个脑图最核心的部分了,用户故事(也可以叫用户任务,随便怎么称呼了)。它的格式就是我希望能够XXX【做某件事情】,因为这样我就能XXX【实现某个目的】。

这里希望能够【做某件事】一定是从角色的口吻描述。

比如 点餐的时候,描述成 “我希望能过通过点图片选菜,这样我能知道菜怎么样”。这其实就是从我方技术实现的角度来描述功能需求了,后续可能对我们的产品设计思路产生“固化”的效果。

如果换成角色的口吻,这个描述建议写成“我希望能够看到这个菜是什么样子,这样我好直观的知道菜怎么样”。在这样的描述语境下,点图片选菜就成为了这个任务的一个可能的解决方案。同时,看视频选菜,看实物选菜、看模型选菜也都是这个需求所涵盖的解决方案。

这样梳理会帮助你释放大脑的禁锢,更好的去输出想法。

这样从头到尾读下来就是:餐饮系统,我是顾客,当我进店点餐的时候,我希望能够看到这个菜是什么意思,这样我好直观的知道菜怎么样。

把所有的角色、场景、任务,都这样罗列之后,我们就获得一个餐饮产品的用户脑图了。以它为蓝本,再加上持续的角色调研、场景调研、头脑风暴,你的产品覆盖会十分完善。对后续的工作也能提供强有力的支撑。

最后的一些细节

这应该是谁的用户故事

有时候我们会遇到一些故事场景可能放哪个角色下都可以,这时候应该放到那个角色下面呢?个人建议无需太教条,不过可以遵循一个简单的原则:去想象一下如果不做这个需求,那个角色的反对声最大。这说明这个用户故事与他关联最大

那要做到什么深度呢?

这个深度其实可以继续细化到第四层(将用户故事按照功能实现的版本层次继续拆分),可还需要继续做吗?

我建议是跟着你的阶段走,大网大鱼 小网小鱼。找到适合自己的颗粒深度就行了。毕竟它是用来指定你做产品设计的。

接下来做什么呢?

后续可以针对用户故事,继续做功能分类,从场景关联性、角色任务重要等级等等,对应你的产品思路,产品功能的重要等级等,列产品业务框架,开始准备最小版本,进入持续一轮一轮的产品迭代落地了。

总之,找到你最适合的方法,让你的团队能够更好的转起来,就是好的方法。


文章转载于微信公众号爱运营


热门模板推荐

微信咨询

请扫码添加客服

微信公众号

请扫码关注公众号

帮助中心
返回顶部