设计讨论里常会出现这样的时刻：几个人都说要画一张“流程图”，真正落笔时，想表达的却不是同一件事。有人要看用户从哪里来，有人想核对页面跳转，还有人关心后台由谁处理。今天兰亭妙微分享NN/g的UX图谱文章。它整理了不同图谱的用途，我们选出与日常项目关系较近的几类，通过一个预约服务的假设场景，看看这些图为什么长得不同，又怎样放在一起使用。
用户旅程图适合把一个目标前后的经历放到同一张图上。配图中的阶段、行为和感受有各自的位置，提醒我们观察的对象不只是某一张页面。一次线上预约，在打开App之前可能已经开始：用户先意识到需求，比较选择，再决定是否提交信息；完成预约以后，还可能等待通知、修改计划和评价服务。
当这些环节放到一起，有些问题会变得明显。用户迟迟不提交，未必是按钮不够突出，也可能是还不知道能不能改期。只盯着最后一个页面，很容易把前面没有讲清楚的信息，误判为视觉上的问题。拉长时间线，可以帮助团队看见问题是在哪一段积累的。
NN/g用户旅程图示意。 图片来自原文，版权归相关权利人。
不过，旅程图并不是把所有格子填满就完成了。对用户感受没有证据的地方，留一个待验证的问题，比写一句想当然的情绪更有用。可以区分观察记录、用户原话和团队猜测，让读图的人知道哪些内容已经得到支持，哪些还需要继续了解。
用户流程图关心的是完成任务所经过的步骤与分支。这里不需要把整个服务经历都塞进来，而是选择一个明确目标。比如“修改一次已经确认的预约”，从哪里进入、什么情况下可以修改、改完怎样确认，都是需要说清楚的关系。
配图中的节点与判断分支很简洁，重要的不是图形画得复杂，而是分支的含义能够被读懂。如果一个节点写着“失败”，但没有说明失败的原因和后续出口，图看起来闭合了，问题却没有被解决。把“没有可选时间”和“提交时连接中断”分开讨论，团队才有可能形成具体方案。
NN/g用户流程图示意。 图片来自原文，版权归相关权利人。
流程图也能帮助不同角色发现彼此的假设。设计师以为更改后立即生效，业务人员可能要求工作人员确认，开发人员则需要区分处理中与已完成。提前把这些关系摆出来，常常比等页面画好后再争论更有效。它提供的是共同讨论的对象，而不是代替讨论作出决定。
服务蓝图把用户看到的活动与后台支持联系起来。预约页面显示成功之后，可能还要分配人员、核对资源并发送提醒。用户只看到一个结果，团队内部却有多个环节。配图中的分层结构，正是为了让这些关系能够在同一张图里被对照。
继续用预约的假设场景：用户修改了时间，但工作人员的日历没有更新，界面本身可能没有任何报错，体验却仍然失败。这类问题很难只通过页面截图发现。将修改动作与后台响应对应起来，就能追问：谁接收变化、在哪里确认、未处理时怎样被发现。
NN/g服务蓝图示意。 图片来自原文，版权归相关权利人。
一张服务蓝图也不宜成为理想状态的宣传画。环节之间存在等待，就把等待标出来；责任还没有确定，就明确留下空缺。它的价值在于暴露需要协作的问题，而不是让复杂服务看起来已经完全理顺。后续规则变化时，这张图也需要有人维护。
Wireflow把界面线框与路径连接起来，适合讨论某个动作具体发生在哪个页面位置。只看流程图时，大家知道下一步要确认；加入简化界面之后，才能进一步讨论用户是否看得见确认内容，以及返回修改是否方便。它不需要达到最终视觉稿的精度，关键是保留讨论所需的信息。
我们比较喜欢把这几类图当作不同距离的观察工具：旅程图拉远看整体经历，流程图看任务关系，服务蓝图看协作，Wireflow靠近页面。这不是每个项目都要照做的固定顺序。小范围调整可能只需要一张图，跨团队服务改版才需要更多视角。
NN/g Wireflow示意，结合线框与流程。 图片来自原文，版权归相关权利人。
如果正在与用户体验设计公司讨论交付，可以先问清楚希望借这张图作出什么决定。图的名称不是目的，能否让团队发现遗漏、说明分歧并推进下一步才是。看完这篇文章，值得带走的也许不是更多术语，而是在画图之前先把要讨论的问题说准确。
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
