Intercom 早期加过一张地图，显示客户分布在世界哪些地方。它很快受到欢迎，团队却不容易说清：客户为什么需要它？
Des Traynor 在标注为 2014 年 10 月 16 日的文章里，列出了三种使用场景：有人带到展会上，有人放到社交媒体上，还有人拿给投资人看。顾客把这张图用来展示自己的业务。理解这个用途后，团队把改进放在了呈现效果、隐藏敏感资料和方便分享上，并提供可分享的链接。
这是 Des 对当时工作的记录，不是本文重新采访过的结果。如今原文还带有后来关闭地图功能的补注，但没有标出补注日期。不能把关闭说明当成 2014 年原稿的一部分，也不能把那张历史地图写成今天仍然可用的功能。
这段经历让我想到一种容易出现的误会：开发者听到了功能的名字，却还没看到用户拿它完成的那件事。
如果把问题定成“怎样做一张更好的地图”，讨论自然会沿着地图软件的方向走。但有些顾客需要的是一份可以向别人解释业务范围的材料。功能在产品里长什么样，和它到了用户手里承担什么工作，可能并不相同。
仅凭“经常有人打开”还不够分辨。相同的打开动作，可能是在做工作，也可能只是为了截一张图。打开次数会告诉团队哪里值得继续观察，却不能独自解释后续该改什么。
下面设想一个给社区社团使用的管理工具。它有一张成员分布图。一位负责人说，希望这张图更好用。这里没有真实访谈记录，只用两种假设任务来说明下一步该怎样问。
第一种情况，负责人要安排周末活动。他看成员集中在哪些区域，再找合适的场地。这时，位置粒度、筛选条件和数据是否及时，会影响他的决定。漂亮的展示页未必解决问题。
第二种情况，负责人要向新来的合作方介绍社团。他打开地图，截图，裁掉不相关的名单，再放进介绍材料。他需要别人迅速理解社团服务的范围。此时值得研究的，可能是怎样生成一份含义清楚、信息范围合适的材料。
这两个人都可能提出“地图再改改”。如果把回答直接记成同一条需求，再凭票数排优先级，团队就把差别抹掉了。
我会先请对方回看最近一次使用：当时准备做什么，图给谁看，离开产品后又处理了哪些东西。若对方愿意，可以用去掉真实成员资料的示例演示那段流程。重点是还原已经发生的动作，少让对方预测一个尚不存在的功能会有多好。
对于第二种用途，截图之后的删改尤其值得看。负责人反复裁掉一列名单，可能意味着当前输出包含了这次展示不需要的信息。但也可能只是那一次合作方的特殊要求。观察到一次后，应该继续找同类任务核对，而不是马上宣布所有人都需要一套全新的展示系统。
开发者可以做一个很小的候选版本：用示例数据生成一页说明，明确图中每个点代表什么，哪些范围被包含，资料属于什么时间。请负责人把它放进原来的介绍流程，再看还需要补写什么、删掉什么、解释什么。这比只问“这一版好看吗”更接近任务是否完成。
如果准备提供可分享链接，还要验证分享出去的内容与页面承诺一致。例如，产品若说只展示城市汇总，访问者就不应还能点到成员名单。哪些信息留在管理端，哪些进入展示材料，要由实际功能决定。这里提出的是候选方案的检查方法，不是在描述 Intercom 当年的具体实现。
反过来，如果更多人是在安排活动，团队可能应该继续改善分析与筛选。同一个功能名称，不需要只有一种答案；但每项改动最好能说明服务哪一类任务，避免把两类人都带进一套谁也用不顺的界面。
Intercom 后来关闭地图的补注，也提醒我给这个故事留一个边界：发现了真实用途，不等于这个用途值得公司永远投入。它能帮助团队判断眼下要怎样改，长期保留与否仍要结合产品方向、维护成本和用户依赖另作决定。
这张地图的故事，值得带走的是一种观察方式。下次看到客户频繁使用某个功能，可以继续追踪它的去向：谁拿走了什么，又把它带到了哪一步工作里。答案常常藏在产品界面之外。
资料：Des Traynor，Intercom，《This is not a map》，页面标注 2014 年 10 月 16 日，2026 年 11 月 6 日阅读全文。页面含未标具体日期的后续补注。
https://www.intercom.com/blog/shareable-map
地图使用和产品调整按作者自述归属；社团工具、演示过程与候选方案为本文独立假设及建议，未试用该历史功能。
