从用户旅程到服务蓝图

【背景】Lynn Shostack 1982 年在《哈佛商业评论》提出服务蓝图，开创'把服务画出来'的方法。 【步骤】1. 阅读 Shostack 设计师页，关注她提出蓝图的历史背景（当时服务营销缺少可视化工具）；2. 理解她的核心主张：服务与产品不同，需要'蓝图'来管理；3. 记录蓝图最初的形态。 【输出】Shostack 蓝图方法论笔记（背景 + 核心主张）。

【背景】蓝图有标准分层：证据线、前台行为、后台行为、支持流程——理解分层才能读懂任何蓝图。 【步骤】1. 浏览'服务蓝图查看器'至少 2 条蓝图；2. 重点看'前台行为'与'后台行为'之间如何通过'互动线'衔接；3. 找出一处'前台简单、后台复杂'的设计并解释其意义。 【输出】蓝图分层解剖笔记。

【背景】蓝图层数之争（三层/四层/五层）反映的是'该把哪些系统画进服务'的边界判断。 【步骤】1. 对比不同方法论的层数划分（Shostack 三层 vs 现代五层）；2. 思考：证据线、互动线、可见性线各起什么作用；3. 给出你倾向的划分及理由。 【输出】层数选择论证（含边界判断）。

【背景】旅程是用户的视角，蓝图是组织的视角：从旅程推导蓝图就是'把用户故事翻译成系统故事'。 【步骤】1. 从'旅程查看器'选一条旅程（建议 Oodi 或 Kaiser 护士交班）；2. 逐段拆解旅程中的触点、动作与情绪；3. 准备把它翻译成后台动作。 【输出】旅程拆解笔记。

【背景】推导蓝图的关键动作：为每个前台触点追问'背后需要什么'。 【步骤】1. 为选定的旅程绘制简化蓝图（前台行为/后台行为/支持流程三行）；2. 对每个前台触点列出所需的后台动作与系统；3. 标注'确定性'：哪些是你确知的，哪些是猜测。 【输出】推导出的蓝图（含确定性标注）。

【背景】蓝图的诚实度决定其价值：猜测的后台会误导决策。 【步骤】1. 统计你蓝图中的'不确定'部分；2. 思考：哪些可以通过访谈后台人员/查看日志来验证；3. 为每条不确定项写一个验证方法。 【输出】蓝图验证清单（不确定项 → 验证方法）。

【背景】信息断裂（前台承诺与后台交付脱节）是服务失败的主要来源。 【步骤】1. 在蓝图中寻找'前台承诺了 X，后台却无法及时交付 Y'的断裂点；2. 也找'触点输出与下一触点输入不匹配'之处；3. 为每个断裂点标出后果。 【输出】断裂点清单（位置 + 后果）。

【背景】弹性（Resilience）设计是服务蓝图的高级层：失败不可避免，关键是恢复。 【步骤】1. 阅读 GOV.UK 蓝图的 'Failure & Recovery' 层；2. 学习政府服务如何处理失败（错误页、降级方案、人工兜底）；3. 总结其弹性机制的类型。 【输出】弹性机制类型清单。

【背景】为断裂点设计恢复方案要具体到'谁、在多久内、做什么'。 【步骤】1. 为每个断裂点设计一个恢复方案；2. 避免'改进系统'的空话，明确责任人与时限；3. 标注哪些恢复需要后台协同、哪些前台即可兜底。 【输出】断裂点恢复方案表（责任人/时限/动作）。

【背景】蓝图能揭示组织责任：每个后台动作都属于某个团队，责任线越乱服务越容易断。 【步骤】1. 为蓝图每个后台行为标注责任方（团队/部门）；2. 找出跨团队依赖密集的触点；3. 判断：如果协作延迟，哪个触点会最先受伤。 【输出】责任线标注图 + 高风险触点。

【背景】服务版本与组织设计的关系：服务如何演化，往往取决于组织如何被组织。 【步骤】1. 浏览'服务版本'页（/relations/service-versions）看服务版本如何变化；2. 思考版本迭代背后是用户需求还是组织变化；3. 记录'组织设计即服务设计'的案例。 【输出】组织-服务关系笔记。

【背景】蓝图的价值在于沟通：若外行 3 分钟看不懂，蓝图就没有完成它的工作。 【步骤】1. 把你的蓝图给一个不懂服务设计的人看；2. 请他们在 3 分钟内复述'服务如何运作'；3. 根据反馈修改蓝图（简化/补层/重画）。 【输出】修改后的蓝图 + 反馈记录。