journey-mapping

旅程地图

构建旅程地图和服务蓝图，呈现体验中的阻碍、帮助团队达成共识并发现机会。不依赖特定技术栈，也不依赖特定工具。

此技能用于绘制体验地图。若要测试具体触点，请使用 usability-testing。若要开展更广泛的探索性研究，请使用 ux-research。若要分析转化情况，请使用 cro-optimization。

---

适用场景

• 各部门对客户体验有不同的认知
• 客户体验在各个触点之间显得支离破碎
• 需要诊断具体的阻碍或流失点
• 战略规划需要对用户形成共同认识
• 服务设计（前台和后台）需要达成共识
• 需要结合更广泛的体验来设计新产品或功能

不适用场景

• 测试单个触点或页面（请使用 usability-testing）
• 绘制旅程地图前的探索性研究（请使用 ux-research）
• 不涉及用户的运营流程映射
• 漏斗优化（请使用 cro-optimization）

---

所需输入

• 已确定要绘制地图的用户画像或细分群体（每个细分群体绘制一张地图）
• 关于该细分群体的现有研究和数据
• 跨职能团队的参与（缺少运营、支持或工程团队的意见，就无法绘制后台流程）
• 时间和利益相关者的投入（真正的旅程地图是一项项目，不是一个下午就能完成的事）

---

框架：3 项交付成果

1. 客户旅程地图

面向用户的体验视图。

结构（行／泳道）：

• 阶段。 旅程中的主要阶段（例如，认知、考虑、入门、激活、留存、倡导）。阶段因产品类型而异。
• 步骤。 用户在每个阶段中执行的具体事项。
• 触点。 用户与产品、品牌或服务互动的地方（网站、应用、电子邮件、支持、社交媒体、线下）。
• 目标。 用户在此步骤中想要完成的事情。
• 想法。 用户此时的想法。
• 情绪。 用户的情绪状态（通常用曲线呈现）。
• 痛点。 出错、产生阻碍或引发挫败感的地方。
• 机会。 可以改善体验的地方。

格式：

通常采用水平时间线，每一行对应一个垂直泳道。阶段位于顶部，下方是触点、想法、情绪等内容。

2. 服务蓝图

支持面向客户体验的后台视图。

在旅程地图下方增加以下层级：

• 前台行动。 员工执行且用户可见的事项（销售电话、支持聊天、店内互动）。
• 后台行动。 在幕后发生的事项（订单履行、数据处理、内部交接）。
• 支持流程。 系统、供应商、基础设施（CRM、支付处理商、履约合作伙伴）。
• 可见性分界线。 前台（用户可见）与后台（用户不可见）之间的界线。

服务蓝图可以展示面向客户的问题源于哪些后台故障（例如，用户感受到的“发货太慢”可能是供应商交接问题所致）。

3. 综合机会地图

绘图工作的产出。

涵盖：

• 主要阻碍点。 体验反复令用户受挫的地方。
• 未开发的机会。 可以让用户感到惊喜和愉悦的时刻。
• 脱节之处。 前台与后台未能对齐的地方。
• 战略差距。 竞争对手具备而品牌欠缺的内容（或反之）。
• 快速见效的改进。 投入少、影响大的改进。
• 战略性投入。 投入较大、能带来转变的举措。

这项交付成果能够促成决策。旅程地图和服务蓝图是输入；机会地图是推动行动的输出。

---

不同产品类型的常见阶段

大多数产品

Awareness → Consideration → Decision → Onboarding → Active use → Renewal/Repurchase → Advocacy

SaaS

Trigger → Discovery → Evaluation → Trial → Onboarding → Activation → Habit → Expansion → Renewal → Advocacy

电商

Need recognition → Discovery → Research → Decision → Purchase → Wait/Anticipation → Receive → Use → Reorder/Recommend

服务

Awareness → Inquiry → Quote → Decision → Service delivery → Resolution → Follow-up → Repeat business

医疗保健／高风险购买

Trigger → Research → Provider selection → Appointment → Treatment → Recovery → Follow-up → Long-term outcome

阶段并非必选项。应从用户的真实体验出发，让阶段从具体步骤中自然浮现。

---

如何收集输入

一份优秀的旅程地图会结合多个事实来源。

来自用户

• 深度访谈。 让用户回顾自己的真实体验。询问他们近期经历的具体情况。
• 日记研究。 用户在整个旅程期间记录自己的体验。
• 调查问卷。 大规模收集定量信号，但深度较浅。

来自业务

• 内部访谈。 销售、支持、客户成功、运营团队。他们对体验的观察角度与产品或设计团队不同。
• 运营数据。 转化漏斗数据、支持工单类别、NPS 回复、客户流失原因。
• 系统清单。 有哪些触点、哪些工具为其提供支持、数据流向何处。

交叉验证

• 用户描述的体验
• 业务掌握的用户行为数据
• 内部团队对体验的看法

这三种观点经常相互矛盾。这些分歧本身就是发现。

---

工作流

1. 明确范围。 一个用户画像、一段旅程、一个时间范围。试图在一张地图中涵盖所有用户，只会导致混乱。
2. 收集输入。 用户访谈、内部访谈、运营数据。为收集输入预留 2 到 4 周。
3. 起草旅程地图。 阶段、步骤、触点。尽快完成可用的初稿，再逐步迭代。
4. 添加各个层面。 目标、想法、情绪、痛点。
5. 构建服务蓝图。 前台、后台、支持流程。
6. 找出机会。 利用摩擦点和脱节之处。
7. 与用户验证。 这是否符合他们的真实体验？进行完善。
8. 与利益相关者开展研讨会。 带领团队了解地图，确保达成共识。
9. 转化为行动。 明确具体项目、负责人和时间表。
10. 持续维护。 旅程地图是一份动态文档。每年或发生重大变化后重新审视。

---

常见失败模式

• 不做研究就绘制地图。 根据内部假设绘制的旅程地图反映的是假设，而不是用户。
• 所有用户共用一张地图。 中端市场买家和企业买家的旅程各不相同。不要将其合并。
• 缺少后台层。 地图展示了症状，却没有呈现原因。
• 地图精美，却没有行动。 为了追求制作效果而牺牲决策。
• 把地图当作成果，而不是工具。 存在 Figma 中，却再也没有打开过。
• 忽视情绪层面。 只写“做什么”，不写“感受如何”，就错过了绘制旅程地图的重点。
• 痛点含糊。 “令人沮丧的入门体验”——具体是什么？发生在什么时候？为什么？
• 找到了快速见效的改进项，却从未执行。 这与研究发现最终没有落地如出一辙。
• 每年走过场，却不跟进。 一年前的旅程地图描述的是一年前的用户。

---

输出格式

默认输出：

1. 旅程地图（可视化，通常使用 Figma / FigJam / Miro，另附 Markdown 叙述版）
2. 服务蓝图（可视化，通常使用相同工具）
3. 机会地图（Markdown，按优先级排序的清单）

旅程地图的 Markdown 叙述版：

# [Persona] journey map

## Phase 1: [Phase name]

### Step: [Step name]
- **Touchpoint:** [Where this happens]
- **Goal:** [What the user wants here]
- **Thoughts:** [What they're thinking]
- **Emotion:** [State on the emotional curve]
- **Pain points:** [Friction]
- **Opportunities:** [Improvement potential]

### Step: [Step name]
[Same structure]

## Phase 2: [Phase name]
[Repeat]

## Service blueprint additions

### Phase 1
- **Front-stage actions:** [What employees do user-visibly]
- **Back-stage actions:** [What happens behind the scenes]
- **Supporting processes:** [Systems involved]

[Repeat per phase]

## Opportunity map

### Critical friction
1. [Specific issue, with evidence]
2. [Specific issue, with evidence]

### Quick wins
1. [Specific opportunity, with effort/impact]

### Strategic bets
1. [Specific opportunity, with effort/impact]

### Cross-team disconnects
1. [Specific disconnect, with implication]

---

如果所需数据不可用

此技能的输出依赖其无法自行生成的数据、测量结果或工具结果。如果所需输入、工具或数据源不可用或无法验证，合规的输出方式是提交交付物并说明缺口：需要什么、实际获取或验证了什么，以及输出的哪些部分受到影响。为完成交付物而编造、估算或插算所需数值，绝不符合规范。说明存在缺口本身就是完整的答复。

---

参考文件

• references/journey-map-template.md - 可填写的旅程地图和服务蓝图模板。