未经验证的地图是团队假设

概念解释

研讨会里用便利贴拼出「用户怎么走」，散会后这张图改名为客户旅程，出现在需求文档里。没有对照过任何一次真实完成过程的地图，身份是团队假设（team hypothesis），不是研究发现。假设可以画，而且常常必须先画，才能知道去观察什么；错的是换标题：把内部构想写成已经发生的事。

机制

在场的人最熟的是自己负责的步骤，最不熟的是别人手里的例外。拼图时会用「应该会」填空：客服「应该」会回、用户「应该」会查邮件。这些填充让图变完整，完整又被误认为真实。验证要付出对照成本——跟一次完整案例、对一次工单时间线——组织更愿意把已经完整的图拿去汇报。标题一改，后续观察若与图冲突，会被当成个案噪音，而不是对假设的证伪。

怎么研究

把地图步骤写成可观察命题（在该步应能看到何种行为或痕迹），拿独立案例去匹配：命中、缺失、顺序颠倒、存在图上没有的步骤。比较「仅工作坊图」与「至少对照过 n 个案例的图」在后续被修正的次数。未对照过的图，在报告中应编码为假设产物。因变量包括命题可观察比例、案例匹配率和因冲突而被改写的步骤数。

边界

战争室里为了对齐内部对现状的分歧，先画出「我们认为的流程」是合法的，只要页眉写明假设、并列出未知。全新服务尚无用户可跟，地图只能是愿景或模拟，不能假装已验证。验证也有程度：跟了两个人不等于抽样完成，只是从纯假设迈出了可被打脸的一步。用内部员工走一遍自己的产品，只能验证内部熟悉度，不能验证外部旅程。

怎么落地

• 页眉强制二选一：「假设：团队构想」或「已对照：案例编号」；禁止无标记上会。
• 工作坊结束后把每一步改写成一条能被观察打脸的句子，作为后续跟访清单，而不是直接进需求。
• 至少用一次端到端真实案例走图；走不通的步骤改回虚线，不要用想象补全。
• 发现图已经出现在对外材料里且从未对照，先降级标题，再补观察，而不是补画细节让它看起来更真。

延伸

• 同组：Q4.04.1 地图跨越触点呈现全过程 · Q4.04.2 需标注情绪与痛点的证据来源 · Q4.04.4 现状地图描述实际发生的过程，愿景地图描述期望的过程，两者不可混用 · Q4.04.5 颗粒度过细会淹没关键转折点，过粗会掩盖具体断点 · Q4.04.6 地图涉及多个部门时需要共同维护，否则会与现状脱节 · Q4.04.7 地图完成后若不更新，会逐渐偏离已变化的实际流程
• 相邻：Q4.03 用户画像 · Q1.02 探索性与验证性
• 站内检索：unverified journey as team hypothesis · assumption map · journey validation