轻松搞定用户故事地图
产品经理用户旅程地图与用户共同讲好一个故事,商业变现自然水到渠成
一、用户旅程地图是什么？用户旅程地图是以视觉化呈现用户为达成某一目标所历经过程的工具，通过创建历程图，能够更好地理解目标用户在特定时间里的感受、想法和行为，认识到这个过程的演变过程，寻找用户的痛点，通过讲故事（Storytelling）的方式描述用户的体验过程，采用视觉化（Visualization）的方式将信息高效简单明了的呈现出来，便于记忆与团队分享。
每一张旅程地图都会因场景不同而各不相同，但一般而言，它们都包括了“Lens”（用户视角），体验的流程，机会点洞察三大区块。
Zone A：Lens区域包括（1）用户的人物画像（“who”）以及产品的使用场景（“what”）（2）为旅程地图提供基本的人物情境设定Zone B：是旅程地图的核心部分，包括用户体验历程的各个阶段划分（3）用户的行为（4）想法（5）感受（6）根据用户调研反馈填写Zone C：此区域会因各项目商业目标的不同而不同：（7）未来的机会点（8）企业内部主导权分配以教育培训类产品为例，见下图，用户从一个陌生人，到进入产品浏览课程，发起在线咨询，预约听课，购买课程就是该产品的用户旅程。
二、为什么需要创建用户旅程地图？用户旅程地图是一个强大的工具，如果你是产品经理，它会帮你理解用户的使用场景，清晰地了解用户来源以及他们试图达到怎样的目的；如果你是内容运营，它将帮你理解用户遇到的问题以及他们的感受，并且可以提供给管理者用户体验的全景图：看到用户是如何在销售漏斗中流动的，进而提升用户体验。
此外，用户旅程地图还可以呈现出用户服务的提升是如何改变消费体验的，洞察到用户体验中的断层和痛点，比如：设备间的断层，这发生在用户在不同的设备间切换时；来自部门之间的断层，用户可能会感觉受挫；市场推广中的断层（例如：从社会化媒体跳转到网站体验可能会更好些）。
值得强调的是，因为手机、社会化媒体和网络正在改变用户行为，因此企业需要更加聚焦用户需求，深入研究以用户为中心的旅程地图，那么，我们该从何处着手呢？三、如何研究用户旅程？创建用户旅程地图的过程必须始于了解用户旅程，以在线英语教育类产品为例，随着知识商业化的到来，其中最核心的企业能力是获取付费用户，以及服务付费用户的能力。
如何制作用户体验地图
身为设计师，大家应该对“用户体验地图”都不陌生，就算自己没搞过，也应该听说过。
说实话，我之前对这件事儿有些抵触。
总担心它比较形式化，花大量时间没有解决真正问题，得不出执行层面的结论，最终以贴贴便签纸拍拍照看起来很专业的样子，其实默默的画上句号为终止。
不过，最近在做产品整体体验优化时，我发现用户体验地图是一个非常有效的方法，它可以让我们更全局的发现用户痛点、挖掘需求、脑爆产品机会点、高效做出决策。
那么bb了这么多，该如何有效的制作属于自己产品的用户体验地图呢?就像打仗需要地形图，体验提升的战斗也需要一个蓝图来规划和指引。
用户体验地图(Experience Maps)也被称为使用者旅程图(User Journey Map)。
用直白的话来解释下：用户体验地图就是通过一张图，用一种讲故事的方式，从一个特定用户的视角出发，记录从用户来到你的产品到完成目标离开的全部过程，它包括：用户在这个场景中的触点、行为、痛点、爽点、以及内心OS。
通过直观地了解用户如何使用自己的产品，以及在此过程中的整体感受，帮助我们寻找新的机遇去建立更好的用户体验。
它的价值是什么?除了上面所说优点，用户体验地图对团队还有以下价值：1.用户视角很多产品工作人员都有一个通病，习惯性的沉浸在自己的逻辑世界中，以工作者的视角去做产品功能，从“我”的目的是什么，“我”有什么东西出发，然后把功能罗列上去。
一顿操作猛如虎自嗨的去设计，以为用户就会在这个规则完成任务，其实用户一脸懵逼，甚至想卸载了你。
如果运用体验地图，参与者需要切换成用户视角、小白模式去看产品体验问题，去观察用户在整个路径中是如何满足自己目标的，以及在满足自己目标时，是困难还是容易的，而不只停留在主观的自嗨。
2.全局思维身为设计师或产品经理，对“体验优化”应该再熟悉不过了，大家往往单纯从产品功能出发，通过数据或用户反馈层面的依据，割裂地去看每一个模块。
这样做的问题就在于，很难做到整体系统的提升体验，一直处于头痛医头，脚痛医脚的优化中，被问题牵着鼻子走，不能从全局视角出发，发现更多的潜在机会点。
产品经理用户故事的故事
用户故事的故事编辑导语：用户故事在软件开发过程中被作为描述需求的一种表达形式；为了规范用户故事的表达，便于沟通，包含角色、活动、价值三个要素；本文作者分享了关于用户故事的故事，解答一些用户故事最常见的问题，我们一起来看一下。
一、开篇我将给你讲述用户故事的故事，并回答一些用户故事最常见的问题；我们将谈论用户故事，从来源到实践，并学习一些技巧来帮助我们。
敏捷开发指南对用户故事只字未提，有一段时间我还在想去哪里找关于用户故事的可靠信息。
待办事项列表是否应该只由用户故事组成？如果不用“作为用户，我想，以便”的模板，是不是就不是用户故事了？那么那些写着“作为开发者”或者“作为产品经理”等等的故事呢？我的目的是对用户故事进行全新演绎，澄清一些围绕用户故事的误解，并为你指出那些对用户故事进行最好阐释的人。
二、基础篇1. 用户故事的故事我将解释用户故事的来源，因为这对我来说是理解用户故事和澄清误解的最好方法。
用户故事来自于90年代，Kent Beck在他的《Extreme Programming Applied》一书中开始讨论用户故事。
这个想法来自一个用户告诉他的一个关于新产品的故事：“我输入邮编，它就会自动填入城市和州，不需要我触碰按钮！”如果你能讲述软件可以做什么的故事，并在听众心中产生动力、兴趣和愿景，那么为什么不在制作软件之前讲故事呢？Kent问自己，为什么不能在构建产品之前就产生这种对产品的愿景呢？关于谁会使用这个产品，它将做什么，以及为什么？我们应该通过对话来帮助我们思考问题。
《User Story Mapping》一书的作者Jeff Patton坚持认为：“故事的名字来自我们如何使用它们，而不是如何写它们。
”2. 模板后来Connextra公司的Rac Davis发明了我们今天使用的模板，它是这样的：“作为一个用户，我想以便”她试图帮助同事有条不紊地在小卡片上写故事，模板提醒我们最重要的三件事：谁要、要什么、为什么。
怎样绘制用户体验的地图产品经理工作学习产品设计产品运营知识
怎样绘制用户体验的地图用户体验地图就是通过画一张图，用一种讲故事的方式，从一个特定用户的角度出发，记录下他与产品或者服务接触、进入、互动的完整过程。
开始做产品经理的人容易犯的错误，就是用管理员的视角来规划产品。
我经常看到这种全局型的产品设计，复杂，全面，没用重点，这肯定是错的。
我一般会告诉这种产品经理，请按照一个用户使用的路径，从一开始用户怎么进入，到每一步怎么体验，最后怎么离开。
这就是我们在《两套经典的用户画像》那节课里讲的，“第一只羊”怎么能够在你的“草地”上活下来，而且玩得很开心的过程。
画出“第一只羊”从开始到结束的完整体验，这就是用户体验地图。
01 怎么画用户体验地图1、一个画像完整的人物角色：需要对“第一只羊”有完整地了解2、清晰描述用户的目标和预期：他什么来到你的草地上？他要什么？3、服务触点：用户从接触你的服务，到实现他的目标之间，会跟你在产品上有哪些接触，你需要在这些地方服务用户。
4、使用路径：使用路径与服务触点的关系是什么？用户在宜家逛的过程是使用路径；在宜家里向工作人员咨询，到盒子前拿免费的资料是服务触点。
5、用户情绪曲线：场景是要触发情绪的。
在整个过程中，用户的情绪是如何变化的？把这个用户从接触你的服务开始，到达成自己的目标为止（或者放弃为止），整个流程画一个坐标图，横轴是用户的使用路径与触点；纵轴是用户情绪。
这样你就可以得到一条用户在与你的服务互动过程中的情绪波动曲线了。
02 为什么要画用户体验地图为了避免管理员视角。
很多初级产品经理都是用管理员视角在设计产品，有什么产品罗列什么，而不是考虑用户要什么。
你要通过用户体验地图，让自己以用户视角来思考，用户能不能一步一步实现目标，这个过程是困难还是容易。
比如，我朋友做了一个中医养生类的keep，叫一体。
我感觉产品方向不错，但下载后却发现是，产品只有一堆教学视频的罗列。
我作为用户，不知道应该看什么，我对朋友说，我是你的目标用户，但我没法坚持用你的产品呢？其实可以通过用户体验地图来分析一下：1、用户画像：亚健康、需要自我调理的人，智能手机用户2、我的目标是什么？目标是调整亚健康状态，问题是脖子疼，肩膀疼，后背疼。
敏捷项目管理中的用户故事分解和任务划分
敏捷项目管理中的用户故事分解和任务划分敏捷项目管理是一种灵活和迭代的项目管理方法，已经在各行各业得到广泛应用。
在敏捷开发团队中，用户故事是一种常见的需求表达方式。
用户故事能够帮助团队更好地理解用户需求，并将其转化为具体的任务和功能。
本文将重点讨论敏捷项目管理中的用户故事分解和任务划分，以及相关的最佳实践和技巧。
一、用户故事分解用户故事是一种简短的需求描述，以用户的角度来描述系统的功能。
在敏捷项目中，用户故事具有以下格式：“As a (user role), I want (goal), so that (reason).”用户故事应该简洁、具体、可测试和可估算。
当用户故事的规模过大时，我们需要将其进行分解。
用户故事分解的目的是将大型的用户故事切分为更小的、可操作的任务，以便于团队能够更好地理解和估算工作量。
用户故事分解的常用方法包括：1. 功能分解法通过将用户故事的主要功能拆分为一系列子功能来进行分解。
这样可以将复杂的功能拆分为更小的、较为独立的子功能，方便团队进行开发和测试。
例如，我们有一个用户故事：“作为一个用户，我想能够通过手机号码登录系统，以便于访问我的个人信息。
”这个用户故事可以被分解为以下子功能：- 在登录页面输入手机号码- 验证手机号码的有效性- 生成验证码并发送到用户手机号码- 验证用户输入的验证码是否正确- 登录成功后跳转到个人信息页面通过这种方式，我们可以将复杂的用户故事分解为一系列可以独立实现和测试的子功能。
2. 故事拆分法故事拆分法是指通过将用户故事中的不同场景或者条件进行拆分来进行分解。
这样可以确保所提供的功能能够满足不同情境下的需求。
例如，我们有一个用户故事：“作为一个用户，我想能够通过不同方式接收系统的通知，以便于及时获得相关信息。
”将其拆分为以下子功能：- 通过邮件接收通知- 通过短信接收通知- 通过推送通知接收通知通过这种方式，我们可以确保系统在不同条件下提供不同方式的通知功能。
地产营销实战之客储策划客户地图3步制作法
地产营销实战之客储策划客户地图3步制作法地产营销实战——客储策划客户地图3步制作法营销决策要从感性、经验转化为理性、量化的逻辑分析推理过程，这样才能提升决策的成功率，这就需要充分调研及⼤数据的精准分析！体现在客储策划中，⾸先就需要有精准的客户地图。
本篇我将讲述如何做好客户地图。
⼀你的客户地图真的能找到客户吗？说起客户地图，⼤家想到的多半是这样的：亦或是这样的：试想⼀个客储⼈员拿着这样的客户地图能找到⽬标客户吗？即便找到了，在⼈⼒、时间和费⽤上是否花费了不必要的试错成本？找来的客户转化率是否偏低？总量是否匹配销售⽬标？事实上，这样的客户地图更多是⽤来汇报的，⽽我们今天要探讨的是能够指导客储⼈员花费最低成本，找到⾜够多⾼质量客户的作战地图。
⼆客户地图=⾯状地图+点状地图，皆须分产品分户型客户地图的输出成果包括点状地图和⾯状地图，前者主要服务于⼩蜜蜂等客储终端⼈员，⽤以指导其找到⽬标客户的具体地址，后者主要服务于客储管理⼈员，⽤以发现机会战场。
由于不同产品和不同⾯积段户型存在客户分布的差异性，故需分开制作，以免造成客储结构的不均衡。
进⼊信息爆炸的时代，要想让客户记住你，除了内容够好，还要出现的次数够多，试想⼀个客户上班时、下班吃饭时、回到⼩区都接触到了我们的信息，记忆度⼀定⼤于单点接触。
这就要求我们的点状地图需要包含客户的居住、⼯作和娱乐三⼤点位，同时为了提⾼⼯作效率并指导资源分配，此清单需在地址之外，列出各点位规模及帮助进⼊点位的关键⼈，如某单位关键⼈是业主王先⽣，规模是2000⼈。
图1 客户地图之点状地图⽰意⾯状地图系根据各点位在地图上的分布绘制⽽成，绘制时居住、⼯作和娱乐可⽤不同颜⾊区分，主要⽤以寻找机会战场，如距离项⽬较近但暂为空⽩的区域（详见图3），或项⽬⽅圆2km已⼗分饱和，则需扩⼤地图范围。
图2 客户地图之⾯状地图⽰意图3 某项⽬⾯状地图机会战场（黄⾊区域）⽰意三客户地图3步制作法图4 客户地图3步制作法⽰意1、通过竞品调研和项⽬交通分析，形成初步客户地图1）竞品=新房+⼆⼿房⾯对供基本或严重⼤于求、有效客户量不⾜的市场局⾯，对于指标压⼒较⼤的项⽬，竞品已不仅是新房，必须同步和⼆⼿房抢客户。
userstory-用户故事（故事、需求拆分、验收标准）
userstory-⽤户故事（故事、需求拆分、验收标准）
⽤户故事标题：
作为乘客，我想要系统推送最新的优惠活动给我，为了能够获取更⼤优惠活动；
拆分需求如下：
1.1，系统推送消息⽅式，采⽤极光推送，在APP打开的时候，系统可以采⽤极光推送消息⾄页头且3 秒消失并在app“消息”⾥⾯查看，在我APP关闭的时候，推送到⼿机的通知栏；
1.2，推送推送⽅式，采⽤短信推送，在⽤户>=15天未活动时，每隔15天或者节假⽇系统采⽤短息推送活动消息，来唤醒⾮活跃⽤户；短信包含短链接； 15天参数CMS运营可配置
1.3, 极光推送活动，跳转⽬的地是在APP的“消息”；
1.4，点击短信推送短链接导向打开APP，没有app安装的话，提醒安装APP；
1.5，极光推送和短信推送不叠加推送
验收标准：
2.1，APP打开时候，可以在页⾯看到推送的活动，点击可以查看活动内容，不点击3秒消失，并且可以在"消息”查看。
2.2，APP不打开，可以在⼿机通知栏看到推送消息，不点击⼀直存在；点击后跳转APP到“消息”
2.3，⾮活跃⽤户，短信推送活动消息，可以收到⼿机短信，同时短链接可以点击，并且点击后的动作满⾜需求
3，前置条件
3.1 ，三⽅极光推送对接，短信通道开发
3.2，CMS服务端完成消息活动配置设计
4, 相关UI效果图和交互设计图此处放置这个⽤户故事相关的UI效果图和交互设计图的链接；。
优秀用户故事范例
优秀用户故事范例用户故事是敏捷开发中常用的一种需求表达技术，它能够帮助团队更好地理解用户需求，从而更好地开发产品。
优秀的用户故事能够清晰、简洁地表达用户需求，并且有助于激发团队的创造力和协作精神。
下面将为您制作一份关于优秀用户故事范例，希望能够帮助您更好地理解并应用用户故事。
# 一、用户故事简介假设我们正在开发一个名为“TripPlanner”的旅行规划应用程序，用户可以使用该应用程序规划自己的旅行路线、搜索景点、预订酒店等功能。
以下是一个关于TripPlanner的用户故事：## 用户故事名称：查找周边景点- **角色**：旅行者- **愿景**：作为一名旅行者，我希望能够在到达目的地后，通过TripPlanner应用程序方便地查找周边的景点，以便更好地规划我的行程。
# 二、用户故事详情通过上述简介，我们可以进一步分解用户故事，以便更好地理解用户的需求和期望。
以下是对用户故事的详细描述：## 用户场景小明是一名热爱旅行的大学生，他计划在寒假期间去某个南方城市旅行。
到达目的地后，他希望能够方便地查找周边的景点，以便更好地规划自己的行程。
此时，他打开TripPlanner应用程序，进入“周边景点”功能页面。
## 用户操作1. 小明在TripPlanner应用程序中选择“周边景点”功能，系统显示出周边的景点列表，并且提供了筛选和排序功能，使他可以更快地找到自己感兴趣的景点。
2. 小明可以在景点列表中查看每个景点的具体信息，包括名称、介绍、地址、营业时间等，以便更好地了解每个景点。
3. 小明可以通过地图功能查看每个景点的位置，以便更好地规划自己的行程路线。
## 用户期望小明期望TripPlanner应用程序能够提供全面、准确的周边景点信息，以便他更好地规划自己的旅行行程。
他希望能够方便快捷地查找到自己感兴趣的景点，并且能够在应用程序中获取到详细的景点信息和地图定位。
小明也希望TripPlanner应用程序能够提供个性化的推荐功能，根据他的偏好和兴趣推荐适合他的景点，以便更好地享受他的旅行。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 2）这些条目作为一个整体要 完全穷举（ Collectively Exhaustive），也就是要“分 净”，做到无遗漏。
• 这两点合起来就是ME-CE。
02
故事地图步骤
用户故事地图步骤
Userstory211
Userstory221
Userstory231
Theme31
Time Release1
业务角 度拆分
Userstory122
Userstory212
Userstory232
Userstory21…
Release2
Release和时间线平行，确保在放入Release的过程中考虑故事的完整性。
用户故事地图结构
User Activities （主干）
Epic1
Epic2
Theme11
Theme12
Theme21
Theme22
Theme23
User Tasks （梗概）
Userstory111
Userstory121
Userstory211
Userstory221
Userstory231
Userstory122
步骤三：拆分故事
一级 需求
会控入口
会控界面
二级 需求
会议控制 权限
控制按钮
顶部
中部
底部
个性定制 ቤተ መጻሕፍቲ ባይዱime
高
故事 细节
权限管理 控制鉴权 产品Logo 导航栏 版权信息
想法
会控人昵 称
操控区域
痛点
机会
多语言
参会人管 理
优先级
退出会控
关闭会议 室
低
步骤三：拆分故事
• 大家在写想法的时候，可以通过一些问题来刺激大家 脑暴出更多的内容，比如：
需求金字塔
需求金字塔
需求金字塔
• 金字塔的顶端是需求的目标，也就是解决什么用户或 业务问题？
• 金字塔的中间层次是操作和操作流程，为了实现上面 目标，系统需要支持哪些用户操作？这些操作的流程 是什么样的？
• 金字塔的底层是业务规则，各个操作步骤对应的业务 规则是什么样的？
需求金字塔
• MECE原则是麦肯锡方法的核 心，在各个层次上都要做到：
步骤一
明确方向
步骤二
骨干故事
步骤三
拆分故事
步骤四
精简故事
步骤一：产品定义
• PO召集3-5人参与故事地图讨论会，讨论以下议题：
– 目标用户，用户目标----用户诉求
用户为什么要用这个?能为用户带来什么价值？
– 产品目标，解决什么问题----业务诉求
我们为什么要做这个?能为我们带来什么价值？
度优先，而非深度，不要过早沉浸到细节中。
步骤二：骨干故事
• 然后，将桌面上所有的便签按类似的任务分为一组。 • 选择另外一个颜色的便签，对每个组命名，作为User
Activities（一级需求） • 最后，对这些摆放好组的便签进行排序，一般按照用
户完成操作的顺序，从左到右摆放
– 如果大家无法决定顺序，那么顺序可能没有那么重要。
故事地图作用
• 了解整个产品的全貌。 • 找到整个产品的主干，也就是路径。 • 促使产生更多用户故事。
可解决的问题
• 防止只见树木不见林，更容易看清backlog全貌
• 确保backlog覆盖了最重要的用户体验路径，及当前 所规划的场景是否可以为用户提供价值
• 确定发布计划以及发布目标，同时确保早期的发布可 以验证整体架构和解决方案
案 例
用户故事地图
黄河敏捷
01
结构与作用
故事地图产生背景
Backlog中的 需求该如何
产生？
故事地图产生背景
• 用户故事地图就是将story用可视化的方式展现在团 队面前，让团队可以仔细梳理、讨论，确认这个 story包含的内容，最终产出需求进行开发。
• 用户故事地图是Userstory的前传！
• 最终，根据排列好的故事优先级，排出迭代计划，并确保 我们的第一个发布越小越好，大约在1-2个迭代后可以发 布第一个MVP版本。
案例讨论
• 某服装公司需要快速开发一套在线服装销售网站，请 讨论完成以下工作：
– 10min：请帮忙输出开发该网站的用户故事地图！ – 5min：请挑出你认为无效的故事，同时补充你认为缺
• 明确方向，防止迷失方向，陷入设计细节的纠结。
步骤二：骨干故事
• 每个人写下自己认为重要的“所要做的事情”User tasks （二级需求）。
• 完成后，每个人轮流读出自己的内容，并把便签纸放在桌 面上。
– 尽量把故事讲完整，便于对整个产品有全局的印象。 – 做到对产品只见森林不见树木的状态。讲完整的故事，一定要广
Userstory212
Userstory232
Userstory21 …
Epic3 Theme31
Epic…
用户故事地图结构
很大的故 事
Epic1
Epic2
Epic3
Epic…
存放类 似故事 的篮子
Theme11
Theme12
Theme21
Theme22
Theme23
Userstory111
Userstory121
– 用户在这步具体做什么? – 用户还有其他选择么? – 出现问题如何处理? – 其他用户来到这里该如何处理? – 使用之后有什么变化？ – 别的产品怎么做？
步骤四：精简故事
• 这时我们的故事已经变得很臃肿。接下来要对卡片内容讨 论，把公认的留下，无用的剔除，同时区分优先级。
– 首先，要对大家写的所有卡片进行对标，排除无效故事。 – 其次，不可能一口吃成胖子，对选定的故事排出优先级。 – 最后，无法梳理清楚的故事卡片，可以先写个占位符。
故事地图特点
• 不是另外一种写需求的方式 • 故事是用来讲的，不是用来写的 • 侧重事件发展过程的描述 • 故事不是忽悠，不是夸大
故事的听众
老板
听众
团队
用户
用户故事地图结构
• 地图的核心是一条从左到右的时间线 • 通过时间线和卡片进行约束
– 时间线上第一行放置最大粒度的需求，即Epic – 时间线上第二行放置二级粒度需求，即Theme – 时间线下自上而下放置三级粒度需求，即Userstory
步骤三：拆分故事
一级需求 二级需求 三级需求
步骤三：拆分故事
• 从业务角度，拆分故事，建议分析维度：故事细节、 想法、痛点、机会……
• 使用静默头脑风暴方式，把自己的想法写在一张卡片 上，相互不干扰，然后每个人大声说出自己的卡片内 容，让所有人了解并贴在墙上。
• 这时不必使用用户故事的标准句法（As a …），因为 每张便签都处于地图的特定位置，大家很容易识别其 所处的场景和角色。