一张旅程图如果只有“了解—比较—购买—使用”和一条从皱眉到微笑的曲线，通常很难指导设计。它看起来完整，却没有说明痛点来自哪里、谁负责、影响什么指标，也没有证据证明用户真的这样经历。
一张旅程图如果只有“了解—比较—购买—使用”和一条从皱眉到微笑的曲线，通常很难指导设计。它看起来完整，却没有说明痛点来自哪里、谁负责、影响什么指标，也没有证据证明用户真的这样经历。
01 旅程图首先是一种对齐工具，不是一张展示海报
它把用户在一段时间内经历的事件、渠道、判断和情绪放到同一条时间线上，让产品、市场、销售、客服和运营看到同一个服务。真正的价值不是“画出来”，而是发现部门交接、信息断点和责任空白。
旅程图适合多步骤、跨渠道、跨团队的体验。例如企业客户从第一次搜索设计公司，到浏览案例、提交需求、比较报价、签约、反馈、验收和后续维护。若只是一个页面里的按钮流程，用户流程图可能更直接。
02 先锁定范围：谁、从哪里开始、到哪里结束
“所有用户的完整旅程”通常太大。开始前写清：
- 主体角色：谁的旅程，例如企业市场负责人，而不是“客户”。
- 目标：他要完成什么，例如筛选并签约官网供应商。
- 起点：什么时候需求真正出现，而不是网站首页。
- 终点：签约、上线、复购，还是长期使用？
- 场景边界：线上、线下、内部审批是否都包含？
- 当前态还是未来态：现在真实发生，还是团队希望发生？
当前态与未来态不要画在同一层里，否则“问题”和“方案”会混在一起。
03 证据先于情绪颜色
旅程图可以来自访谈、观察、客服记录、搜索词、表单、销售CRM、产品日志和工单。每个关键痛点最好能追溯到一种证据。
如果某一阶段只来自内部猜测，可以标记为“假设”，并列出需要验证的问题。诚实地留白，比用一条漂亮的红色曲线填满更有用。
04 一张可行动的旅程图至少有十层
| 层级 | 要回答的问题 |
|---|---|
| 阶段 | 旅程按什么事件自然分段？ |
| 触发 | 什么让用户进入下一阶段？ |
| 目标 | 此刻他真正想完成什么？ |
| 行为 | 实际做了哪些动作？ |
| 触点 | 官网、搜索、邮件、电话、产品或线下？ |
| 问题与信息需求 | 他在判断什么，还缺什么？ |
| 情绪与风险 | 为什么焦虑、犹豫或放心？ |
| 证据 | 哪场访谈、哪条数据或工单支持？ |
| 后台与责任人 | 哪个团队、系统和流程影响这一刻？ |
| 指标与机会 | 怎么知道改善有效，先做什么？ |
并非每张图都要展示全部层级，但分析底稿里最好保留。
05 示例：企业选择官网设计服务商
| 阶段 | 用户任务 | 主要触点 | 常见痛点 | 后台原因 | 可验证指标 |
|---|---|---|---|---|---|
| 需求出现 | 统一改版目标与预算 | 内部会议、旧官网数据 | 各部门目标不一致 | 缺少项目负责人和范围说明 | 需求确认用时、返工次数 |
| 搜索与初筛 | 找到可信候选 | Google、案例页、推荐 | 案例好看但看不懂服务范围 | 案例缺少背景、过程和结果 | 案例页到咨询页路径 |
| 咨询与沟通 | 判断团队是否懂业务 | 表单、微信、会议 | 重复讲需求，反馈口径不一致 | 没有统一Brief与记录 | 首次响应、有效需求完整度 |
| 比较方案 | 比较范围、方法与风险 | 提案、报价、合同 | 总价可比，交付范围不可比 | 报价格式和验收标准不同 | 决策周期、澄清问题数量 |
| 执行与反馈 | 按阶段确认方向 | Figma、会议、文档 | 多人分散反馈导致推翻 | 没有反馈负责人和版本规则 | 每轮修改时间、超范围需求 |
| 验收与上线 | 确认功能、内容与资产 | 测试站、清单、源文件 | 页面上线了但资料未交齐 | 验收只看视觉，没有资产清单 | 缺陷数、交付完整率 |
这类表格会自然暴露：很多“网站体验问题”其实源于内部流程与服务交付，而不是网页组件。
06 阶段要按用户事件分，不要按公司部门分
“市场部、销售部、交付部”是组织视角；“发现需求、比较、决策、实施、验证”才更接近用户经历。部门可以放在后台责任层，而不是拿来切分用户旅程。
阶段数量通常5到8个比较易读。太少会掩盖关键过渡，太多则变成流程清单。
07 找机会点时，先看断点和交接
旅程里最值得讨论的往往不是情绪最低点，而是：
- 用户重复提供同一信息。
- 状态从一个系统转到另一个系统时丢失。
- 用户完成动作后没有确认。
- 前台承诺与后台执行标准不同。
- 多个部门都参与，但没有最终责任人。
- 风险很高，却没有清楚的求助和恢复路径。
这些问题通常不能靠改一段文案解决，需要跨团队调整。
08 用机会优先级替代“灵感墙”
每个机会可以按四项评分：用户影响、业务影响、证据强度、实施成本。高影响、高证据、成本适中的问题优先进入方案；高风险但证据弱的问题先研究；低影响的视觉优化不要因为容易做就排到最前面。
| 机会 | 用户影响 | 业务影响 | 证据 | 成本 | 建议 |
|---|---|---|---|---|---|
| 咨询前提供标准需求清单 | 高 | 高 | 高 | 低 | 优先实施 |
| 新增复杂AI推荐 | 未知 | 中 | 低 | 高 | 先验证需求 |
| 调整案例卡片动画 | 低 | 低 | 中 | 低 | 暂缓 |
| 统一项目状态与通知 | 高 | 高 | 高 | 中 | 跨团队规划 |
09 旅程图、流程图和服务蓝图不要混用
- 用户流程图：聚焦用户在产品或任务中的步骤与分支。
- 用户旅程图：聚焦一段时间内跨触点的经历、问题和感受。
- 服务蓝图：在旅程基础上加入前台人员、后台流程、系统、政策和支持资源。
- 体验地图：范围可能更广，不一定围绕单一品牌或服务。
当问题明显来自后台责任和系统交接时，可以在旅程图之后继续做服务蓝图。
10 一场两小时旅程工作坊怎么开
- 15分钟：确认角色、目标、起点和终点。
- 25分钟：根据研究材料排列真实事件。
- 20分钟：补触点、信息需求和行为。
- 20分钟：标记痛点、情绪及证据。
- 20分钟：加入后台责任与系统。
- 15分钟：提出机会并评分。
- 5分钟：明确负责人、下一步和待验证问题。
不要让所有人凭空发便签。提前准备访谈摘录、数据、工单和现有流程，讨论才不会变成意见投票。
常见问题
没做用户研究，可以先画旅程图吗？
可以画“假设旅程”，用于暴露团队认知差异，但要明确标注假设，并安排验证。不能把内部工作坊产物当成用户事实。
是否要为每个用户画像画一张？
只有当角色目标、权限或路径明显不同时才拆分。过度按照年龄、性别等表面属性复制旅程图，会增加维护成本。
情绪曲线必须有吗？
不必须。若没有可靠情绪证据，可以改用“信心、阻力、风险”或直接描述问题。不要为了视觉完整强行打分。
旅程图做完后谁维护？
由最接近业务与用户研究的负责人维护，并在流程、政策或产品变化后更新。它不是一次性PPT，而是跨团队决策材料。
11 让旅程图进入下一次决策
旅程图最好的使用场景不是挂在墙上，而是在确定路线图、改版范围、服务流程和指标时反复被打开。每个机会点都应该有证据、责任人和下一步，否则再漂亮的地图也只是一张项目纪念品。
链接复制成功
