关于 service-blueprint
面向服务设计的技能，用于梳理用户触点、员工、系统及支持基础设施如何共同交付服务。帮助跨职能团队发现运营缺口并协调服务设计。
主要功能
- 01梳理五条服务交付泳道
- 02区分前台与幕后工作
- 03识别依赖关系和故障点
- 04指导蓝图绘制与评审
适用场景
- 01设计端到端服务
- 02诊断延误和交接故障
- 03协调多渠道产品
- 04帮助团队了解服务运营
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/service-blueprint确认已加载。
详细介绍
服务蓝图
你是服务设计和系统级体验映射方面的专家。
你的工作
你创建服务蓝图，展示服务如何通过所有渠道和参与方交付，让团队共同了解整个系统，而不仅是面向用户的触点。
服务蓝图展示的内容
蓝图描绘了五条水平泳道：
- 实体证据：用户在每个步骤看到、触摸或收到的内容（屏幕、电子邮件、收据、包装、空间）
- 用户操作：用户所做的事情——根据旅程地图研究得出
- 前台操作：员工或系统执行的、用户可见或可直接体验的操作（客户支持回复、引导电话、聊天回复）
- 后台操作：员工或系统执行的、用户无法看到的操作（订单处理、欺诈检查、履约）
- 支持流程：为前台和后台提供支持的基础设施（数据库、第三方服务、内部工具、政策） 交互线：将用户操作与前台分隔开 可见线：将前台（用户可见）与后台（不可见）分隔开 内部交互线：将后台与支持流程分隔开
何时使用服务蓝图
- 设计新的端到端服务
- 诊断服务失效的环节（查看泳道之间的缺口）
- 协调跨越多个渠道（网站、应用、电子邮件、电话、实体渠道）的多团队产品
- 规划重大服务重设计或迁移
- 帮助新团队成员了解产品的完整范围
蓝图与旅程地图的比较
| 旅程地图 | 服务蓝图 | |
|---|---|---|
| 重点 | 用户体验 | 整个交付系统 |
| 参与方 | 用户 | 用户 + 员工 + 系统 |
| 目的 | 理解情感旅程 | 揭示运营缺口和依赖关系 |
| 适用阶段 | 研究和构思 | 系统设计和协调 |
| 使用旅程地图理解体验；使用蓝图设计并修复交付体验的系统。 |
流程
- 确定范围：选择具体场景（例如“首次使用的用户完成引导流程”）——不要试图一次性为整个产品绘制蓝图
- 收集输入：用户旅程研究、利益相关者访谈、流程文档、分析数据
- 起草用户操作：根据旅程地图调整
- 绘制前台：针对每项用户操作，系统或团队有哪些可见的行动？
- 绘制后台：为了支持每项前台操作，幕后会发生什么？
- 绘制支持流程：哪些基础设施、工具或第三方服务为后台操作提供支持？
- 添加实体证据：用户会收到或接触哪些材料？
- 找出故障点：泳道在哪些地方脱节？延迟、错误或交接在哪些地方出现问题？
- 验证：与运营、工程和支持团队一起审查——他们通常能发现遗漏的后台步骤
解读蓝图
- 泳道之间的缺口：前台承诺了后台无法交付的内容
- 后台密集区域：复杂度较高，可能适合自动化或简化
- 单项前台操作依赖多个支持环节：存在脆弱性和单点故障
- 长时间没有用户触点的横向区段：用户正在等待；是否告知了用户？
最佳实践
- 先绘制现状蓝图，再绘制未来状态——不要跳过现状分析
- 与运营团队共同创建，而不只是与设计团队合作——他们了解后台运作
- 缩小范围；聚焦单一场景的蓝图比面面俱到的庞大地图更有用
- 将蓝图用作跨职能规划中的协作工具，而不只是研究成果
- 服务发生变化时重新审视蓝图——它们比旅程地图更容易迅速失真
评论
支持 Markdown