更新时间： 2026年10月17日
用户旅程图回答“用户经历了什么、哪里感到困难”，服务蓝图进一步回答“前台触点背后由哪些人员、系统和流程支撑”。两者不是二选一：先用墨刀白板整理真实体验，再按需要补齐后台协作层，才能从抱怨定位到可执行改进。
一、先用四个问题判断该画哪一张图
| 问题 | 优先使用 | 原因 |
|---|---|---|
| 想了解用户在每个阶段的感受？ | 用户旅程图 | 聚焦行为、目标、情绪和痛点 |
| 想找出跨部门断点？ | 服务蓝图 | 把前台触点与后台动作对齐 |
| 资料只有访谈和观察记录？ | 用户旅程图 | 先整理事实，避免凭空补流程 |
| 已知道触点但问题反复发生？ | 服务蓝图 | 追踪人员、系统、规则和等待时间 |
二、以“售后换货”为例搭建用户旅程图
- 确定角色和范围：购买后发现尺寸不合适，目标是完成换货。
- 按时间顺序写出查询规则、提交申请、等待审核、寄回商品、收到新货五个阶段。
- 每阶段记录用户目标、实际行为、触点、情绪和阻碍，引用访谈原话或数据。
- 把痛点改写成机会点，例如“审核等待久”改为“明确材料清单并展示处理进度”。
每个痛点都要有证据来源。没有数据时标记为待验证假设，避免把团队猜测当成用户事实。
三、把旅程图扩展成服务蓝图
- 前台动作：用户看到的页面、客服回复和物流通知。
- 可见员工行为：客服审核、仓库确认、物流更新等用户能感知的动作。
- 不可见后台行为：库存校验、退款规则、权限审批和异常处理。
- 支持系统与证据：工单、接口、数据表、SLA和负责人。
扩展时只补与问题直接相关的后台动作。若换货等待来自库存同步，就把同步频率、失败提示和人工兜底写在同一行；如果只是情绪描述，不要强行画出不存在的系统。
四、从图上产生行动而不是停在展示
- 给每个痛点标注影响、证据和负责人，先处理高影响且可验证的项。
- 在图旁添加改进假设、指标和验证周期，例如“展示进度后，咨询工单是否减少”。
- 把需要设计验证的项链接到原型，把需要研发确认的项链接到任务或接口。
- 评审后冻结一个版本，记录删除、合并和新增的原因。
最终交付可以是一张用户旅程图、一张针对关键断点的服务蓝图和一份行动清单。它们共同说明问题发生在哪里、谁能改变它，以及下一次验证应该看什么结果。
五、如何组织一次共创工作坊
工作坊先让参与者分别写下事实，再合并成时间线。第一轮只讨论用户做了什么，不讨论解决方案；第二轮补充情绪、触点和证据；第三轮才把高影响痛点转成机会点。需要后台协作时，再把前台触点向下延展到人员、系统和规则。这样能减少“先画系统再找用户问题”的倒置。
| 产出 | 负责人 | 完成条件 |
|---|---|---|
| 事实时间线 | 研究或产品 | 每个阶段有来源或标记为假设 |
| 痛点优先级 | 全体参与者 | 按影响与频次说明排序依据 |
| 服务蓝图 | 产品与运营 | 每个关键触点能找到后台动作 |
| 行动清单 | 项目负责人 | 有负责人、指标和复查日期 |
六、避免把图画成组织架构
服务蓝图的泳道按用户触点和服务动作划分，不等同于公司部门表。一个部门可能在多个触点出现，同一触点也可能跨部门完成。判断是否需要新增泳道的标准是：新增后是否能解释一个体验问题或责任交接；不能解释就留在备注中。
把主流程和异常路径跑通后，再把本页的复现记录与交付结果放在同一份版本记录中，后续评审可以直接追踪。
案例：分析电商换货体验
先用用户旅程图记录“发现尺寸不合—提交申请—寄回—审核—收到新件”的行为、触点、疑问和情绪，再选出“申请后不知道进度”这一高频痛点。只有当痛点需要客服、仓库和通知系统共同解决时，才继续展开服务蓝图。
- 用访谈或工单回放补齐真实等待时间和用户原话。
- 将痛点写成可验证问题，例如“申请后 24 小时内没有进度通知”。
- 在前台层写客服可见的状态，在后台层写仓库审核、库存和通知动作。
- 为每个改进行动指定负责人、输入输出和验收指标。
- 评审时从用户触点向下追到系统责任，找出承诺与能力的断点。
| 产物 | 回答的问题 | 何时停止扩展 |
|---|---|---|
| 用户旅程图 | 用户哪里受阻 | 痛点已有优先级 |
| 服务蓝图 | 谁与什么系统支撑体验 | 行动有负责人和证据 |
