How to run a user interview
The goal of an interview is not to collect opinions. It is to reconstruct one real experience that actually happened. You want facts, not evaluations.
What you will run into
- 聊了一小时，笔记里全是「他觉得挺好的」
- 对方一直在评价你的方案，你也一直在解释
- 问完五个人，五个人说的都不一样，无法归纳
Four stages, in order
| 阶段 | 开场白 | 这一段的目的 |
|---|---|---|
| 暖场 | 你平时一天的工作大概是什么样的 | 建立背景，也让他放松。别一上来就问产品 |
| 回溯 | 最近一次遇到这个情况是什么时候 | 把他从泛泛而谈拉回到一个具体的日子 |
| 追问 | 带我过一遍，那天你先做了什么 | 还原完整步骤，卡点自己就浮出来了 |
| 收尾 | 你觉得还有谁值得我聊聊 | 拿到下一个人。这是访谈最划算的一句话 |
Four shovels for probing
When the answer is a generalization, dig with these four. You have hit the right depth when they start telling specifics.
Six things to avoid
- Don't ask hypotheticals. "If there were a feature… would you use it?" The answer is always yes. Ask how they did it last time instead.
- Don't bake the answer into the question. "Do you find the input too slow?" He'll just nod along. Ask "how did that step feel?" instead.
- Don't rush to fill silence. A three-second pause isn't emptiness — it's recall. The moment you speak, that recall is gone.
- Don't correct them. Wrong feature name, wrong method — don't interrupt. How they actually understood it is itself information.
- Don't only ask about the smooth parts. Ask specifically about "the one time it went really wrong." The exception carries the most signal.
- Don't interview alone. Ideally one person just takes notes. Doing both guiding and recording yourself means you miss more than half.
After the interview
The value of an interview shows up when you organize it. Do it the same day — after one day, memory starts to warp.
| 原话 | 发生的事实 | 推出的判断 | 可信度 |
|---|---|---|---|
| 「每次都要弄好久」 | 上周三花了 40 分钟手抄 | 频率约每周一次，单次成本高 | 高 |
| 「导出功能挺重要的」 | 没有具体例子 | 暂时存疑，需要第二个人佐证 | 中 |
| 「以后应该会用吧」 | 无 | 不作为依据 | 低 |