一. 从“好像不错”到“咋这么难用”

设想你在做一款英语学习 App：有单词卡片、跟读练习、打卡日历，还有精心设计的激励体系。上线前团队做了多轮可用性测试，指标也不难看，任务完成率挺高，用户也会说一句“整体还不错，就是有点忙的时候就用不起来”。

上线后 DAU 却迟迟上不去，复访率更是惨淡，很多人下载后连续用两三天就再也没打开过。产品会上大家开始猜：是不是激励不够强？是不是内容太难？是不是提醒推送不到位？你能感觉到问题和“忙的时候用不起来”有关，却总抓不住关键。

直到有一天，你跟用户研究一起，提议去几位用户家里和通勤路上看一看他们是怎么“真正使用”这款 App 的。你在地铁上看见一个年轻人单手扶着吊环，另一只手拿着手机，耳机里听着英文材料，中途手机被消息打断，他快速切出去回了两句，又被站内广播打断，下车前匆忙关掉 App；你还在咖啡馆里看到有用户本来打算学习 15 分钟，结果被同事叫去开会，App 在后台躺了一个小时，回来时他已经忘记自己学到哪儿了，索性关掉，心想“晚上再说吧”。

这时你会突然意识到，所谓“忙的时候用不起来”，不是一句泛泛的抱怨，而是由一个个具体情境、干扰、设备状态、网络质量、注意力切换共同堆叠出来的结果。很多你在会议室里讨论的“优化点”，其实跟这些真实的使用场景根本对不上号。

情境调查（Contextual Inquiry）就是帮你把自己从会议室里“拉出去”，丢到用户的真实世界里，用一种有方法、有结构的方式，去看他们怎样在现实生活中使用你的产品，并且边用边讲。

二. 情境调查的核心定义与精神

如果用教科书式的一句话来讲情境调查，大概率会让人犯困。对设计师来说，更实用的理解是：情境调查，就是在用户真实的使用环境里，一边观察他完成真实任务，一边通过对话理解他为什么要这么做，从而看到“说出来的需求”和“真实行为”之间的差距。这里有几个关键词，决定了它跟普通访谈、可用性测试完全不是一回事。

1. 真实环境

刚才那个英语学习 App 的例子，如果你把用户叫到公司会议室，给他一杯咖啡、一张干净的桌子、一台满电的手机，然后让他说“你平时怎么用这个 App？你现在演示一下”，他确实会演示，但那是一种“被摆拍”的使用：没有地铁拥挤、没有信号不好、没有同事叫他去开会、没有家人突然说话。他演示的，是他心目中“理想状态下”的自己，而不是现实生活中那个被各种干扰撕扯着的自己。

2. 真实任务

情境调查不太适合让用户做“任务剧本”那种事，比如：“假设你今天想学 10 个新单词，请你完成以下步骤……”，而更像是：“你刚刚是不是要坐地铁通勤？那你就像平常一样使用手机，什么时候想打开我们的 App 学一下，就自然打开，我在旁边看着就好。”研究者会围绕用户本来就要做的这件事去提问和观察。