维护人员发现设备异常，先查手册，再问同事，最后打开官网发支持请求。提交成功后还要发照片、等回应。若只看官网页面，重复说明问题和等待中的不确定就容易被漏掉。
客户体验历程图沿时间组织一个人完成具体目标的行动、想法、感受和渠道，帮助看见前后关系。它需要丰富且可追溯的经历材料，不能凭接触点名称画出一条满意度曲线。
从一个人获得可执行建议的过程开始
以设备企业改善支持为假设示例。角色是首次寻求支持的维护人员，范围从发现异常到得到可继续执行的处理建议。它比“所有客户购买旅程”更适合研究。
采购、使用与维修的路径可能不同，应分别呈现或留分支，别平均成一个虚构人物。画像有助于定范围，但不能代替任务材料。
本篇过程是教学假设，正式现状图应由访谈、观察和记录支持。可以先画假设图帮助准备研究，待核实的位置要可见，不能把未来想法写成现状。
收一段完整经历，再划阶段
围绕近期相关任务询问何时开始、为什么转渠道、在哪里等待、最后怎样继续。资料可辅助回忆，观察可补动作。网站之外的手册、同事和电话同样属于过程。
按目标与状态划阶段，不必照搬认识、考虑、购买。进入、离开、返回和中断的条件比阶段名称更重要。
| 阶段 | 本例要了解的事情 | 候选机会 |
|---|---|---|
| 判断异常 | 如何确定需要支持 | 提供初步判断信息 |
| 寻求帮助 | 为什么选官网或电话 | 说明入口与处理范围 |
| 准备资料 | 哪些缺少、是否重复提供 | 提前说明并关联请求 |
| 等待回应 | 期待什么反馈、怎样继续 | 状态与责任说明 |
机会是待讨论方向，需要证据，不应借地图把团队原本想做的功能全部塞进来。
行动、想法与后台分别写
行动可来自观察或具体自述；想法和感受需要参与者说明。若他没有说等待焦虑，就保留未知，不因为流程看着麻烦画低落曲线。
后台知道工单正在流转，客户可能完全看不到进度。内部状态不能自动代表体验，客户困惑也不能自行说明系统原因。需要时增加后台层，明确与用户层的区别。
请参与者核对顺序与解释，再由业务检查支撑动作。客户说补交照片后没消息，就查照片是否关联原请求、谁接手、何时通知。问题能落在这里，比“提升沟通体验”更容易处理。
不同人经历不一致，检查任务、渠道和规则，保留有用分支。某阶段只来自一人的回忆，也要说明，不能为了曲线整齐抹平差异。
从一个断点作出可检查的改动
在本例中，可以尝试让补交资料显示已关联原请求，再说明接手状态。先核实系统与权限能否支持，不能靠一条顺滑连线假装实现。
正向节点也记录。某条准备说明帮助客户一次提供足够资料，就应保留；某次通知使他能继续操作，也值得理解。地图不只有痛点。
成功标志是团队找出一个跨阶段或渠道的具体断点，说清发生条件、用户影响和后台依赖，并选择能够核实和测试的改动。情绪曲线漂亮，并不是成果的判断标准。
现状与未来，保留两个版本
现状图记录材料支持的过程，未来图表达候选方案。新增能力、预期感受和假设注明，两张图可以比较，但不要混成一张“客户已经会这样”的图。
需要减少重复提交，就核实渠道能否关联数据、涉及什么权限、谁负责处理。原型再检查客户能否理解和沿新路径继续；组织与服务能力还要实际确认。
交付范围、角色、事件证据、现状、问题机会与验证安排。多方交接难理解时，可用商业折纸具体化关系，但关系模型无法代替客户经历。
客户的目标最终是得到可执行建议，提交表单只是其中一段。历程图使团队看见页面前后的条件，官网改版因此能针对真正的断点。
把跨渠道过程接到官网设计
58UI的官网设计开发与UI/UX服务，可梳理支持入口、资料补交和反馈状态，并结合响应式设计检查不同设备上的过程；品牌视觉设计让跨页面信息保持一致。实际服务责任仍需业务团队确认。
你可以了解设计与开发服务，查看官网与界面案例。通过沟通具体设计问题带来一项现状任务与渠道证据，能帮助判断页面应在哪些交接处提供支持。
相关服务
