用户旅程地图最容易做成一张漂亮表格，却把推断写成事实。我用一个 Skill 跑完 6 个阶段，同时生成 JSON、交互 HTML 和 PNG，重点看它怎么守住证据边界。

上周直播时，分享过一个产品经理的 Skills，主要是做用户旅程地图的，简单分享下思路。

简单说就是：把“产品经理拿到研究材料，到评审前形成下一轮研究问题”画成一张用户旅程地图。

咱们输入只需要是研究材料，执行过程包括锁定任务、拆阶段和标证据，最终得到1 份 JSON、1 个可交互 HTML、1 张 PNG。

大家可以先看下完整结果。

比如，地图里有 6 个阶段，每个阶段都带目标、动作、触点、情绪、痛点、证据状态和产品机会。

6 阶段用户旅程地图完整结果

当然，这是个测试案例，所以图里的体验描述只标记为“合理推断”或“待验证假设”，可以理解在思路。

一张地图，只解决一个核心任务

大家做 skills，一定要围绕场定位和场景特点着手。比如，大家都知道，用户旅程地图更关注用户如何进行旅程体验。

公司部门和产品菜单，都不能直接拿来当阶段。这个 Skill 的第一道门槛，是先确认一个具体用户、一个场景、一条从开始到结束的任务链。

目标用户、场景与核心任务被明确写入地图

范围确定后，再拆成 5 到 7 个用户阶段。

比如，收拢材料、锁定任务、拆分阶段、标注证据、生成地图、评审验证。阶段沿着用户动作走，没有按“数据组、产品组、设计组”设定。

完整任务被拆成 6 个连续用户阶段

说实话，前两步看似简单，却决定了后面的图是不是用户视角。因为，先收拢材料，才能知道手里有什么；然后再紧接着把任务压窄，才不会一张图塞进三个用户、四条流程。

收拢材料阶段的目标、动作与证据说明

锁定任务阶段明确一张地图的范围

最难的不是画图，是明确功能定位

事实上，我上周还在内部分享会上提到，做 skills 的几个经验，其中之一就是要描述清楚场景和定位。

阶段拆分最常见的偏差，是把功能菜单当旅程。Skill 会要求每个阶段对应用户目标和动作，同时检查起点、终点是否闭合。

拆分阶段时保留“待验证假设”标签

更关键的一步，是给每条体验结论标注证据状态：已验证事实、合理推断、待验证假设。

没有材料就保留“待验证”，表格再完整，也不能替代研究。

标注证据阶段逐项区分事实、推断与假设

比如，这一步的情绪值落到 -2，是整条旅程的低点，并给到清晰的原因。

证据标注是本次示例的情绪最低点

说实话，一张旅程地图有没有用，先看假设有没有被诚实地留下。

情绪最低点，不等于最高优先级

地图用 -2 到 2 记录情绪，但机会排序另算。默认公式是：影响 × 频率 ×（6－当前解决程度）。

所以“用户最难受”只能提示断点，不能直接替团队决定先做什么。

6 个阶段的情绪变化从 0 降至 -2，再回升到 2

评审验证阶段同时检查优先级与证据边界

这次地图里，证据标注是情绪低点，机会优先级也高；但这只是本次评分的结果，不是规则。换一批材料，排序可能完全不同。

评审阶段显示情绪与机会优先级是两套指标

交付物要能改，也要能回到证据

user-journey.json是唯一结构化数据源，交互 HTML 从它生成，PNG 再从 HTML 截取。

这样改阶段、调情绪或补证据时，不会出现表格一版、汇报图又一版。

生成地图阶段保持 JSON、HTML 与 PNG 同源

最后，这个 Skill 并不是替产品经理做用户研究，用户旅程图其实是提升产品体验的关键载体之一，而是更好的来辅助产品同学来完善需求设计。