情景描述泳道图实操：对齐体验与系统流程

页面显示“预约成功”，联系人便把时间发给同事。运营人员随后才发现讲师未确认，只能再通知改期。界面上的一句反馈，把尚未完成的业务承诺提前交给了用户。

情景描述泳道图适合检查这类错位。它将同一个用户故事分成故事画面、用户体验、业务流程、工具和系统四层，沿事件逐一对照。用户此刻得到了什么回应，后台有没有条件兑现，在图上可以一起讨论。

从一次预约画起

假设一家企业培训平台要设计团体课程预约。企业联系人选课程、报人数、提出时段，再把安排转告同事；运营需要检查名额和讲师，系统保存申请并发出通知。

本次只画“提出预约到获得明确安排”。更改预约另起一张图，因为联系人已经有一份原安排，平台也要处理原名额和通知。把所有故事叠在一起，很容易让箭头代替解释。

四层各有用途，不能只把部门名称写成泳道。部门职责属于业务流程，用户的处境与感受、页面反馈、系统依赖也要看得到。

同一列表示同一个事件附近的过程。运营可能稍后处理，邮件也可能异步发送；不必强行同时发生，更不能为了图整齐省掉等待。

准备一张纸或共享白板，把触发、提交、收件反馈、等待、收到安排依次写出来。配几幅简单草图，展示联系人何时需要把结果交给同事。故事画面只补任务条件，无需画成精美海报。

这些事件应由访谈、授权任务记录和业务资料支持。缺少材料时，可以起草假设版本，但把待确认位置直接写在图上。让用户代表核对目标，让业务人员说明谁接手，让技术人员确认已有状态，避免一个人凭印象填完整张图。

完成用户这条线以后，再往下补后台。运营怎样看到新申请？由谁查名额？讲师未回复时，状态如何显示？每一项页面反馈都应对应某个业务动作或系统事件。

假如系统当前只能保存申请，设计就应写“已收到，时间待确认”。“预约成功”应留到平台确实能提供明确安排时。图上的缺口帮助团队做取舍，不需要靠一个笼统的“自动处理”填满。

四条平行纸带以同一节点对齐，表现体验与后台的对应关系

请团队从联系人提交开始逐列讲一遍。到等待处暂停，检查用户需要知道什么、谁负责更新、通知从哪个渠道发出。官网消息、邮件、电话确认要分别写，不能统一画成“联系用户”。

“自动通知”也应有条件。是申请保存后发送，还是时段确认后发送？如果邮件失败，运营能否看到、谁来补发？把触发条件、接收者和失败后的接手写清，开发才知道要实现哪种行为。

等待时间需要结合用户处境与实际服务能力确定。联系人可能要在当天下班前通知同事；平台若无法承诺即时确认，页面至少要解释当前进度和怎样获得帮助。泳道里不画等待，用户仍然会等。

再走一个有依据的例外，如课程已满。联系人应何时知道，可选择什么替代时段，原申请会不会保留？把问题留在发生的那一列，并注明谁核实业务规则。新的箭头不能解决尚未决定的规则。

成功标志是团队能用图讲完一次预约，并说清每次重要反馈由什么动作支持；遇到讲师未确认或课程已满，也找得到接手人员和用户可见的状态。

最终保留图、缺口清单与状态说明。把“现有实现有问题”“拟增加能力”“用户需求尚未确认”分开写。否则一个待研究问题很容易被当成确定的开发需求。

图完成后，请目标联系人使用原型，看看他能否理解“已收件”和“已确认”的差别。技术团队检查状态和通知能否实现，业务团队检查实际交接。泳道能帮助发现问题，不能自行证明满意度、系统稳定性或服务能力。

服务人员与工程师在设备区核对纸图中的交接节点

关系难以理清时，可以先用商业折纸摆出角色和渠道，再把同一预约的事件整理成泳道。业务规则发生变化，图也要更新版本和适用情景，避免旧图继续决定新页面。

预约与审批界面常常需要同时设计等待、确认和异常状态。58UI的UI/UX与官网设计开发服务可以把流程问题落实到页面、文案和原型；品牌视觉设计帮助各类状态保持一致表达，响应式设计则检查手机上的处理过程。

设计与开发服务介绍了相关范围，官网与界面案例可供了解呈现方式。通过沟通具体设计问题讨论项目时，一次完整的用户故事和现有状态清单，会比孤立的页面截图更有帮助。