第3章 用户旅程拆解
区分典型用户角色、绘制端到端交互路径、标记触达点
适用场景
- 新产品业务流程设计:需要明确不同用户在系统中的完整行动路径,避免角色混用导致流程遗漏。
- 现有流程诊断与优化:通过用户旅程可视化发现冗余触达点或断裂环节。
- AI产品功能规划:确定各用户角色在业务节点上的智能决策需求(如推荐、异常检测)。
- 多角色协同流程标准化:当业务涉及前台、后台、审核者、数据管理员等多种角色时,统一端到端理解。
前置条件
| 编号 |
前置条件 |
说明 |
| 3.1 |
业务范围已划定 |
明确本次拆解覆盖的模块(如用户注册、商品检索、订单流转) |
| 3.2 |
用户角色清单初稿 |
至少列出 3~5 个典型角色名称及职责简述 |
| 3.3 |
关键业务事件列表 |
如“用户提交订单”“客服发起退款”“管理员查看数据看板” |
| 3.4 |
触达点定义模板 |
统一标记方式(触点类型、媒介、触发条件) |
操作步骤
本步骤采用“四层拆解法”逐层深入,建议组建 3~5 人跨角色工作坊完成。
| 步骤 |
动作 |
输出物 |
工具/方法 |
| 3.1 |
用户角色区隔:基于业务目标列出所有可能角色,合并同类项,最终确定 3~6 个核心角色,并撰写 角色画像卡片 |
角色画像表(含角色名、典型动机、频率、权限等级) |
用户画像模板、角色矩阵 |
| 3.2 |
场景启动事件梳理:对每个角色列出其“第一次进入系统”到“完成核心任务”的关键事件 |
事件-角色对照表 |
头脑风暴 + 卡片排序 |
| 3.3 |
端到端路径绘制:按时间顺序连接事件,形成交互路径图(泳道图或流程图) |
用户旅程图(SVG 或绘图工具草稿) |
泳道图、思维导图 |
| 3.4 |
触达点标记:在每个交互步骤上标注触达点类型(按钮、通知、短信、API、人工会话等) |
触点清单(含触点编号、类型、媒介、预期响应时间) |
触达点标记规范表 |
| 3.5 |
交叉验证:邀请各角色代表(或PM、开发、测试人员)走读并修正路径 |
旅程评审记录 |
走读会 / 评审会议 |
输入输出物
| 类型 |
名称 |
来源/去向 |
| 输入 |
业务范围文档、用户角色初稿、关键业务事件列表 |
第2章输出物/产品经理提供 |
| 输出 |
角色画像表、事件-角色对照表、用户旅程图、触点清单、评审记录 |
交付给第4章“流程节点定义” |
责任边界
| 角色 |
负责内容 |
参与/协助 |
| 产品经理(PM) |
主持工作坊、起草角色画像、确认触点必要性 |
协调开发、QA 代表参与走读 |
| 业务负责人 |
提供对真实用户行为的一手洞察,验证触达点合理性 |
参与评审 |
| 交互设计师 |
将旅程转化为 UI 流程稿,补充触达点交互细节 |
与 PM 协作完成触点清单 |
| 开发代表 |
评估技术实现可行性,标记不可实现的触点 |
在评审阶段提供技术约束 |
| QA |
基于旅程图编写测试场景 |
参与走读,确保路径可测 |
记录材料
异常处理
| 异常情形 |
影响 |
处理措施 |
| 角色过多无法聚焦 |
旅程图复杂、关键路径被稀释 |
强制按业务贡献度筛选前 5 位角色,其余放入“次要角色辅助路径”另行存档 |
| 触达点缺乏实际数据验证 |
触点类型错误导致后续研发返工 |
启动一周快速原型测试,收集 5~10 条真实用户日志确定触点触发率 |
| 跨角色路径冲突 |
同一事件在不同角色视角下顺序不同 |
以时间轴为主,建立“共享事件池”,冲突部分在评审会上投票或由业务负责人裁决 |
| 外部依赖触达点(如第三方 API)不可控 |
路径断裂、用户体验下降 |
在触达点标记中增加“外部依赖”标签,并设立 fallback 替代触点(如手动处理) |
验收标准
- ✅ 所有核心角色均已覆盖,且每角色至少完成一条端到端路径(从触发到结束)。
- ✅ 用户旅程图通过至少一次跨角色走读评审,无逻辑矛盾或遗漏关键步骤。
- ✅ 触点清单包含编号、类型、媒介、触发条件、响应预期,且与技术方案初步对齐。
- ✅ 异常处理记录中列出的灰色地带已确认处理策略并分配责任人。
- ✅ 所有输出物(角色画像表、事件-角色对照表、旅程图、触点清单、评审记录)已归档至共享文件夹。
本章核心用户旅程框架图
💡 最佳实践:建议用“泳道图”或“时间轴+角色分行”的方式在正式文档中呈现完整用户旅程。本文框架可作为早期快速收敛草稿。
⚠️ 常见坑点:① 将“用户角色”与“系统权限”混为一谈——同一角色在不同模式下路径可能不同;② 忘记加入异常路径(如登录失败、订单超时),导致触达点遗漏关键反馈。