A research method that finds what users don't mention in interviews — because they've stopped noticing it themselves.

Contextual inquiry is a field research method where a researcher observes and interviews a user in their natural environment — at their desk, in their workflow, using their actual tools and setup — while they work. Rather than asking users to describe their behavior, you watch it happen in context.

The method was developed by Karen Holtzblatt and Hugh Beyer in the late 1980s. It remains one of the highest-fidelity methods for understanding how people actually use tools — as opposed to how they think they use them, or how they describe using them when removed from the context.

Both involve observing a user interact with a product, but they answer different questions.

Usability Testing puts a user in front of a specific interface and asks them to complete defined tasks. The focus is the UI: can they navigate it, find what they need, understand what's happening?

Contextual inquiry observes the user doing their real work in their real environment. The focus is broader context: what are they actually trying to accomplish? What else is happening around the product? What workarounds have they built? What does their workflow actually look like versus what the product assumes it looks like? These are questions a lab session can't answer.

A session typically runs 60-120 minutes. The researcher observes the user doing real work — not a simplified or staged task — and asks questions as natural moments arise. The stance is closer to an apprentice learning from a master than a researcher administering a test.

A few principles that separate good sessions from mediocre ones:

• Observe real work, not demonstrations. Ask users to continue what they'd normally be doing.
• Ask about what you see, not what you assumed. "I noticed you copied that into a spreadsheet — what's that for?" often surfaces more than any pre-planned question.
• Note observations and ask about them at a natural break rather than interrupting mid-task.

Contextual inquiry consistently surfaces workarounds — the spreadsheets, Slack messages, and manual steps users have built around a product's gaps. These rarely come up in interviews because users have normalized them. They don't think of a workaround as a workaround; it's just how the job gets done.

It also reveals the physical and social context of product use: the constant interruptions, the multiple monitors, the colleague who answers certain questions, the environment the product was never designed for. User Journey Map artifacts are often built on assumptions about context; contextual inquiry replaces those assumptions with observations.

Contextual inquiry is highest-value early in a product lifecycle or at the start of a major redesign — when the team needs to understand the real work context before making structural decisions. It's also valuable when support tickets and usage data suggest users are struggling in ways that don't map to anything obvious in the UI.

It's resource-intensive: six to eight sessions is typically the minimum for meaningful patterns to emerge. Reserve it for strategic questions where the depth is worth the investment. For faster feedback on specific UI problems, Usability Testing or guerrilla testing are more efficient.