ux-research

用户体验研究

规划并开展用户研究，产出决策，而不只是演示文稿。不依赖特定技术栈，也不依赖特定工具。

此技能适用于生成式研究和探索性研究。若要测试现有设计，请使用 usability-testing。若要绘制完整的客户体验，请使用 journey-mapping。

---

适用场景

• 启动新产品或重要功能，但对用户的了解不足
• 在缺少明确数据指标的情况下，诊断问题所在
• 提出新的机会假设
• 在投入大量资源前验证战略方向
• 帮助逐渐远离用户的团队建立共情
• 将“我们应该和用户聊聊”的想法转化为切实可行的计划

不适用场景

• 测试特定设计或原型（请使用 usability-testing）
• 绘制现有体验的完整旅程（请使用 journey-mapping）
• 量化评估（请使用 analytics-strategy）
• 转化率测试（请使用 cro-optimization）

---

所需输入

• 研究问题——你需要解答什么
• 利益相关方的支持（谁需要研究结果，哪些决策取决于这些结果）
• 用户访问渠道（现有客户、潜在客户、已流失用户、目标细分群体）
• 时间安排和预算
• 可借鉴的既有研究

---

框架：6 个阶段

1. 界定问题

糟糕的问题会导致糟糕的研究。应投入不成比例的时间来界定问题。

好的研究问题应当：

• 具体（而不是“用户对我们的产品有何感受？”）
• 开放式（而不是“用户喜欢功能 X 吗？”）
• 与决策相关（答案会改变要构建的内容）
• 可研究（可以通过接触用户来解答，而不只是分析）

示例：

不佳的问题	更好的问题
“用户喜欢我们的新手引导吗？”	“在新手引导的哪个环节，新用户会不确定是否要继续？”
“我们应该构建哪些功能？”	“当前用户在完成[具体任务]时有哪些未满足的需求？”
“为什么转化率低？”	“用户到达定价页面时的心智模型是什么？它在哪些方面与我们的意图不一致？”

2. 选择方法

研究方法应由问题决定。

生成式方法（实际情况是什么？）：

• 深度访谈。 时长 60 分钟，5 至 15 名参与者。最适合了解背景、动机和心智模型。
• 情境访查。 在用户的工作环境中观察他们开展工作。最适合了解工作流。
• 日记研究。 参与者连续数天或数周记录体验。最适合研究无法在单次访谈中体现的行为。
• 实地研究。 在用户生活或工作的场所进行调研。最适合了解文化和情境。
• 问卷调查（以定性为主）。 需要通过开放式回答获取广泛反馈时使用。

验证方法（假设是否成立？）：

• 概念测试。 展示描述、模型图或原型，并收集反馈。
• 卡片分类。 验证信息架构。
• 树形测试。 在不受视觉设计影响的情况下验证内容是否易于查找。

（若要测试可用设计的可用性，请参阅 usability-testing。）

3. 招募

招募工作成败攸关。

招募标准：

• 符合研究的目标受众（而不是“愿意参加的任何人”）
• 涵盖不同的行为类型（活跃用户、已流失用户、从未使用过的用户）
• 在相关情况下涵盖不同的人口统计特征
• 排除朋友、家人和员工（存在偏差）
• 尽可能排除职业研究参与者（他们属于不同群体）

招募渠道：

• 产品内招募（邀请当前用户参与）
• 向用户细分群体发送邮件
• 招募平台（UserInterviews、Respondent 等）
• 由客户支持团队推荐
• 线下现场拦访

参与补偿： 向参与者付费。标准费率：访谈 60 分钟支付 50 至 150 美元；高管或专业领域从业者的费用更高。

招募人数： 预留 20% 至 30% 的缺席率。招募 7 人，以安排 5 人参与。

4. 执行

访谈或研究环节本身。

访谈前：

• 提前 24 小时和 1 小时发送确认信息
• 测试录制设备（音频质量不容妥协）
• 准备访谈指南（参见模板）
• 尽可能安排一位记录员（让访谈者能专心投入）

访谈期间：

• 在征得同意后录制视频和音频
• 以建立融洽关系开场，而不是直接提研究问题
• 使用开放式问题（“说说你上一次……的经历”）
• 留出沉默时间（让参与者填补空白；不要急着问下一个问题）
• 可以问“为什么”，但不要连续追问太多次（会变成审问）
• 追问具体细节和示例（“能带我逐步回顾一下你当时做了什么吗？”）
• 温和地探究矛盾之处（“你之前说 X，现在又说 Y；能帮我理解一下吗？”）
• 留意情绪起伏的时刻（通常意味着有重要信息）
• 不要推销或说服——这是倾听，不是推介

反面做法：

• 带有诱导性的问题（“你不觉得这让人困惑吗？”）
• 假设性问题（“你会使用……这样的功能吗？”）——无法很好地预测行为
• 一次问多个问题
• 打断对方
• 填补沉默
• 只问能验证自己已有想法的问题

5. 综合分析

笔记不会自动变成洞见。

综合分析流程：

1. 记录观察结果。 从录音、笔记和访谈记录中提取。每条观察都是一个独立的数据点：一句引述、一种行为、一种情绪或一个瞬间。
2. 进行亲和图归类。 将观察结果归纳为不同主题。可以使用实体便利贴或数字工具。
3. 发现模式。 在多位参与者身上反复出现的主题才是信号。偶然出现的观察结果也值得关注，但说服力较弱。
4. 识别洞见。 洞见不只是一个主题，而是一个非显而易见的发现，能解释原因或揭示其意义。
5. 用数据验证洞见。 如果洞见只适用于部分访谈，那它就是假设，而不是洞见。
6. 区分信号与噪声。 如果 8 位参与者中只有 1 位持有某种看法，这可能是噪声；如果有 6 位持有这种看法，那就是信号。

高质量洞见的判断标准：

• 让团队感到意外（团队早已知道的内容不算洞见）
• 能解释团队一直在猜测的“为什么”
• 能带来具体行动（这意味着什么？）
• 经得起多个数据点的验证
• 能用一两句话表达清楚

6. 传达

研究结果往往在幻灯片中被束之高阁。要提前规划如何传达。

有效的成果形式：

• 核心洞见文档。 列出 5 到 10 条清晰表述的洞见，并附上支持性引述。
• 精彩片段合集。 将参与者的关键片段剪辑成 5 到 10 分钟的视频。比任何文档都更有说服力。
• 现场工作坊。 带领利益相关者亲自完成综合分析。他们参与其中，才能真正理解并记住结论。
• 面向不同利益相关者的简报。 不同受众需要不同的表述方式。CEO 关心战略影响；设计师关心痛点；工程师关心使用场景。

无效的成果形式：

• 80 页的幻灯片，最后只被匆匆浏览
• 没人会读完执行摘要的报告
• 冗长的叙述性总结
• 放在文档里、没人会再次打开的洞见

---

工作流

1. 明确研究问题。 与利益相关者共同确定，并反复迭代。
2. 选择方法。 根据问题选择合适的方法。
3. 规划后勤安排。 时间线、预算、招募、工具和团队。
4. 招募参与者。 尽早开始。招募缓慢会拖延所有工作。
5. 试运行。 在正式开展前进行 1 到 2 场研究。完善指南。
6. 执行。 严格遵循指南，同时对意外发现保持开放。
7. 综合分析。 不要等到所有研究环节都结束后才开始；中途就可以着手。
8. 传达。 使用多种形式，面向多类受众。
9. 跟踪影响。 决策是否因研究而改变？如果没有，无论研究质量如何，都算失败。

---

失败模式

• 研究没有导向决策。 研究发现无处可用，付出的努力白白浪费。
• 研究问题含糊不清。 糟糕的问题会产生无法解读的答案。
• 招募“愿意参与的任何人”。 样本与目标受众不匹配。
• 过度招募专业参与者。 得到的是符合预期的回答，而不是真实用户的反馈。
• 访谈指南中的引导性问题。 研究发现反映的是研究人员的想法，而不是用户的想法。
• 跳过综合分析。 只有笔记算不上洞察。
• 洞察证实了团队已有的看法。 尤其要对这类洞察保持怀疑。
• 研究发现从未落地。 没有改变产品决策的研究发现只是装饰。
• 用一次研究项目支撑多年的决策。 研究结论有保质期，需要更新。
• 把研究当作一次性项目。 持续探索胜过阶段性研究。

---

输出格式

默认输出：

1. 研究计划（研究开始前）- research-plan-[topic].md
2. 访谈指南 - interview-guide-[topic].md
3. 研究发现文档（综合分析后）- research-findings-[topic].md
4. 精彩片段集锦（单独制作的视频）

研究发现文档结构：

# [Topic] research findings

## Question we set out to answer
[Specific question]

## Method
[Approach, sample size, dates]

## Top insights
1. [Insight, stated in one sentence]
   - Supporting evidence: [Quotes, behaviors, or state the gap per the data-availability rule]
   - Implication: [What this means for product/strategy]
2. [Insight 2]
   ...

## Themes (less prominent than top insights, still worth noting)
[List]

## Outliers worth investigating
[Single-participant observations that may be signal in disguise]

## Recommended next steps
[Specific actions]

---

如果所需数据不可用

此技能的输出依赖于其无法独立生成的数据、测量结果或工具结果。如果所需输入、工具或数据源不可用或无法验证，获准的输出应是交付物，并明确说明缺口：需要什么、实际获取或验证了什么，以及输出中哪些部分受到影响。绝不允许为了完成交付物而捏造、估算或插值补出所需数字。明确说明缺口本身就是完整的答复。

---

参考文件

• references/interview-guide-template.md - 结构化访谈指南模板，包含开场、追问和结束环节示例。