全面解析用户故事地图
共
2431字,需浏览
5分钟
·
2021-06-21 00:43
昨天一篇文章我们给大家分享了用户故事,这篇文章我们来分享故事地图。
“用户故事”的概念来源于敏捷开发的理念。
用户故事是从用户的角度来描述自己渴望得到的特性以及带来的价值。
现在流行的模板是:英文:
As a <Role>, I want to <Activity>, so that <Business Value>.
中文:
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
传统的需求都是用列表展示,用户故事地图将你的需求列表变成一张二维地图。纵向:我们按自上而下划分不同的版本(可以理解为每个版本做的闭环功能)用户活动:组织邮件->管理邮件->管理日历->管理联系人搜索邮件又分为根据关键词搜索,整理邮件分为移动邮件和创建子文件夹。一份好的用户故事地图一般经历以下几个步骤:产品定义》梳理骨干故事》拆分故事》沟通确认,参与人员一般有技术开发、产品经理、项目经理、设计师、用户、产品老大。 将内容记录在黑板上,与大家讨论达成共识,确定产品定义。我们举个生活中的例子,比如早上到公司上班,我们一般需要经历如下几步:实际情况,大家写的故事粒度可能不同,需要po把控故事大小。上段故事可再往下细分一层,比如起床:如下图,骨干故事有了两层,分别为一级故事和二级故事。从左到右是一个叙事流。首先,我们在第一步确定产品整体范围之内尽量的把故事讲完整。其次,我们需要注意是要讲完整的故事,但是一定要广度优先,而非深度,不要过早的沉浸到细节中。我们可以按照以下几个维度对细节进行归类,分别是:故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得,也可以通过用户想法、用户的痛点结合主观判断。做完这步,我们已经获取到了足够多的细节信息,整个项目组都会做到对产品又见森林又见树木的状态。在这个过程中,先让大家在一定时间内按照自己的想法写出来,每一条写在一张卡片上,做到相互不干扰,然后每个人出声说出自己的卡片内容,让所有人了解并贴在墙上。项目组人在写想法的时候,相当于脑暴的过程,这时可以通过一些问题来刺激大家脑暴出更多的内容,比如:大家对卡片内容进行对标、充足讨论,把公认的留下来,无用的剔除掉。同时可以区分要做的故事细节的优先级。暂时无法梳理清楚的,先写个占位符,等待时机再做拆分。当所有故事梳理完成之后,就完成了这样一张完整的用户故事地图了。很多公司产品经理会产出PRD文档,这还算好的,有的公司直接就是产品经理简单说几句,然后手绘几个草图,就算交接需求了,这个时候难免会有偏差,而用户故事地图通过产品全景图和讨论的方式把大家的想法对标,从而达成一致。所有人都可以快速知道用户想要什么,每个故事都做到了站在用户的频道,说人话。传统的设计是经验性设计,都是产品经理通过观察用户的使用情景设计的,高度依赖前期的用户调研,包括用户访谈和用户观察,但是用户不会成为产品设计的真正参与者,后面的阶段基本是靠产品经理的经验,几乎没有用户身影。用户故事地图是一个吸引用户参与设计他们所需产品的便捷手段。因为故事地图是用户全程参与的,所以在我们整个设计过程中都有用户的身影。以往的记录的方式无非有几种:文档记录、笔记记录或者记录在聊天记录里面。这种方式大多是单点对单点或多点的,而且记录内容有限。回头再去看这些卡片的时候,和看照片一样,它会快速唤起我对那段时间的回忆用户故事不是另外一种写需求的方式,故事是用来讲的,不是用来写的,主要是为了建立共识。
为什么听了很多道理,依然做不好产品?道理不仅要懂,更要做,要做到知行合一,真正的“懂”,一定是在“实践”的过程中,用“道理”来指导“行为”。并且,在“亲自体验”过这个道理所带来的好处之后,更加认同和相信这个道理,继续用它指导自己的更多行为……PS: 转发此篇文章到朋友圈或者产品经理微信群,可凭截图找微信:yw5201a1领取一份项目管理模板。
此外我们的官方网站也上线了,每日分享高质量的文章、原型素材和行业报告,小伙伴可自行前往索取,支持搜索,需要的小伙伴可点击底部的阅读原文直接查看,或者复制网址:www.dadaghp.com 打开。想学习更多关于产品、职场、心理、认知等干货,可长按右边二维码,关注我们。··················END··················
浏览
45点赞
评论
收藏
分享
手机扫一扫分享
分享
举报
点赞
评论
收藏
分享
手机扫一扫分享
分享
举报