Watch users do the real task in their real environment. What people report in a neutral interview and what they actually do at their desk are often two different stories.
▸ Try the interactive toolContextual Inquiry is a qualitative method in which the researcher observes and interviews a user while they perform real tasks in their actual environment. Unlike a traditional interview — conducted in a neutral setting, relying on recalled behaviour — contextual inquiry places the researcher where the work actually happens.
The method's value is that it captures what users do, not what they remember doing — and the gap between the two is enormous. In context, you see the workarounds people have stopped noticing, the interruptions, the other tools open alongside yours, the environmental constraints no interview would surface. The classic stance is “master and apprentice”: the user is the expert demonstrating their real work, and the researcher is the apprentice watching and asking.
The user (master) does their real task in their real environment; the researcher (apprentice) observes and asks about what they see happening. Observe behaviour first; ask about it second. Context reveals what recall hides.
People are unreliable narrators of their own behaviour — not dishonest, just unaware. Contextual inquiry replaces the unreliable report with direct observation.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Relying on recall | Users misremember and rationalise their own behaviour. | Observation captures what actually happens, not the edited memory. |
| Missing the environment | Interruptions, other tools, and constraints are invisible in a neutral room. | Real context reveals the conditions that shape behaviour. |
| Unnoticed workarounds | Users stop noticing the hacks they rely on daily. | Watching surfaces the workarounds they'd never think to mention. |
| Idealised task flows | Users describe the clean version, not the messy reality. | In context you see the real, interrupted, non-linear flow. |
Arrange to observe where the work actually happens — their desk, their environment, their real tools. The setting is the data; a conference room loses it.
Position the user as the expert demonstrating their work and yourself as the apprentice. This frames them to show rather than summarise.
Have them do an actual, current task — not a hypothetical or a demo. Watch before you interrupt; the unprompted behaviour is the most valuable.
When something interesting happens — a workaround, a hesitation, a switch to another tool — ask about it then and there, while it's concrete, not in retrospect.
Note the interruptions, the adjacent tools, the physical and organisational constraints. These context factors often explain behaviour the screen alone never would.
In interviews, users described a workflow as smooth and said they had no real complaints. Behavioural data showed drop-off, but nobody could explain it. A few contextual inquiry sessions — watching people actually do the task at their own desks — told the real story within minutes.
Users were constantly interrupted mid-task, switched to a spreadsheet to track something the product didn't, and had built a fragile workaround they'd stopped consciously noticing — so it never came up in interviews. None of this was visible in a neutral room or recalled in a conversation. Seeing the real environment explained the drop-off the interviews had missed entirely.
The deliverable is observation notes capturing behaviour, environment, and in-the-moment explanations — the real workflow, not the idealised one.
| Interview alone catches | Contextual inquiry also catches |
|---|---|
| What users remember and report | What users actually do |
| The idealised task flow | The interrupted, messy real flow |
| Conscious complaints | Unnoticed workarounds |
| The product in isolation | The product among other tools & constraints |
Users are honest but unreliable narrators of their own behaviour. Contextual inquiry trades their edited memory for your direct observation — and the difference is the workarounds, interruptions, and constraints that no interview surfaces.
The master–apprentice framing is what makes it work. By casting the user as the expert demonstrating their craft and yourself as the humble apprentice, you shift them from summarising (where rationalisation creeps in) to showing (where real behaviour appears). The richest findings come from the moments you'd never have known to ask about — the spreadsheet open beside your product, the colleague who interrupts every few minutes, the workaround so habitual the user forgot it was a workaround. That's the data recall can't give you, and it's often the explanation for the metrics you couldn't account for.
Removing the real environment removes the point. Observe where the work happens.
Leading with questions gets you the recalled version. Observe behaviour first.
Over-questioning turns it into an interview. Watch, then ask about what you saw.
The interruptions and adjacent tools are often the real story. Capture them.
Observation (what they do) plus TEDW/5 Whys (why they do it) is a powerful combination (Tool 05).
Contextual observation is the strongest grounding for a well-framed problem (Tool 04).
When analytics shows a drop-off you can't explain, contextual inquiry reveals the why behind the numbers (Tool 09).
Rich contextual observations become patterns through affinity mapping (Tool 20).
Find someone willing to let you watch them do a real task with a product (even a colleague). Observe first, quietly. Note every workaround, interruption, or switch to another tool.
Afterward, ask them to describe the same task from memory. Compare what they reported to what you saw.
The gap between their description and your observation — the workarounds they didn't mention because they'd stopped noticing them — is exactly what contextual inquiry exists to capture.