下面这些 Empathy Map 示例展示了同一套 6 格布局如何适配不同的研究目标和团队场景。找到最匹配你当前 UX 挑战的那个，直接在 CodePic 打开编辑，无需注册。
使用场景: UX 团队做 design sprint 以提升结算转化率
这样组织的原因: 来自于 5 次电商结算可用性测试。关键洞察来自 Says/Thinks 矛盾：用户嘴上说「注册账号可以接受」，但心里想「我用 Apple Pay 就好」——说明他们容忍注册但能避则避。最终的 action item 是把游客结账按钮移到注册按钮上方。
使用场景: 产品经理和客服团队诊断高流失率原因
这样组织的原因: 来自客服工单分析 + 3 场用户访谈。便签密度最高的区域是 Pains——每个用户都提到重新说明背景是最沮丧的事情。团队 action item：实现「上下文继承」功能，回头客的工单自动预填历史记录。
使用场景: 技术负责人促进跨职能理解
这样组织的原因: Team empathy map 的独特价值在于暴露跨职能团队对彼此的假设。这份 map 揭示：工程师认为产品经理故意改需求，而产品经理同样对无法快速迭代感到沮丧。最终行动：在冲刺末尾留 2 天「spec freeze」窗口——最后 2 天需求锁定，不能变更。
使用场景: 考虑转行的职场人自我反思
这样组织的原因: Personal empathy map 暴露了经典的 Says/Thinks 冲突：公开层面用「好工资」、「在学习」来 justify 留下来，私下已经感到无聊和停滞。洞察：真正的需求不是「找新工作」——而是「6 个月内找到可见的成长，或想清楚到底缺什么」。行动：安排了一次 skip-level 职业对话。
使用场景: 做第一次可用性测试的 UX 学生
这样组织的原因: 学生研究员常见的错误是假设用户会「自己摸索」。这份 map 捕捉到：用户不会责怪设计——他们责怪自己。Says/Thinks 的差距（「导航混乱」vs「我觉得自己很笨」）是一个关键洞察：用户不会主动抱怨，仅靠埋点数据会漏掉糟糕 UX 的隐性成本。
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=empathy-map
使用这个模板