从提问到交付，检查客户的完整旅程

划定一个完整需求

选择具体情境及可辨认的起点、终点。对虚构面包店，旅程从有人需要聚会订单开始，到取货并知道之后如何提问结束。“浏览 Instagram”只是其中一个接触点。

GOV.UK 把体验地图说明为基于研究、呈现服务过程中行动、想法与感受的工具。我们的初步练习用于准备研究：先画出认为会发生的过程，并明确标注仍需向用户核对的部分。

还原案例，保留信息缺口

寻找一个获准审阅的真实请求，收集必要消息、使用过的表单、确认与交付记录。只保留相关信息，避免把个人资料复制到共享演示中。若不知道两个步骤之间发生了什么，就把缺口画出来。

在虚构面包店中，客户看见照片，通过聊天询问数量，并收到总额。取货如何确认还不清楚。这只是说明性假设。要描述多个真实客户的经历，需要听取他们的叙述，并检查案例之间的差异。

用四行连接体验与运营

• 行动：每个阶段客户想完成什么。
• 信息：继续之前需要知道什么。
• 回应：收到什么页面、消息或帮助。
• 负责人：谁能回答问题或修正这一步。

下方再写证据与开放问题。只有客户表达了情绪，或研究支持时，才把它记为观察；否则保留为待探索的问题。地图应区分已有知识与团队认为可能发生的情况。

仔细检查确认时刻

提交订单后，客户是否知道只是发送成功，还是订单已被接受？日期、地点与变更渠道是否清楚？GOV.UK 的确认模式包括接下来何时发生什么，以及相关编号和联系方式。它可以作为参考，再按自己的服务情境调整。

示例消息可以归纳请求、状态与下一步：“已收到申请，我们会检查可用情况，并通过此渠道回复。”文字必须符合真实流程。订单尚未确认时，表达也要保留这个状态。

选择能够观察的小改进

假设多位客户询问去哪里取货。全面改版前，先检查当前消息是否给出可识别的到达地点。准备更清楚的说明，请人用自己的话解释会去哪里，并记录原先缺少什么、修改了什么。

客户问题可以帮助确定说明优先级。本站定位指南检查最初承诺；旅程地图则把承诺连接到后续执行，让具体疑问对应明确指令或负责人。

分别保留范围与结果

记录审阅案例、时间段、所作变化与后续观察。正面意见能说明该案例中的理解情况。若要声称总体放弃率或购买量改变，则需要定义、可比较的测量，以及其他变化的背景。

最后作一个小决定：保留新说明、向更多人核对，或解决文字无法修复的运营问题。本站可见性与成果指南区分不同阶段的信号。旅程帮助定位这些信号，而不预设前一步造成了后一步。