Contextual inquiry is watching users do real work in their actual environment. Here's what it reveals that interviews can't, and when it's worth the extra effort.
.png)
Contextual inquiry is a research method where you observe users doing real work in their actual environment, rather than asking them to describe it or replicate it in a lab setting. It's more time-intensive than a standard user interview, but it reveals things people can't articulate: the workarounds they've forgotten about, the interruptions that shape their workflow, the context that makes abstract feedback concrete. Worth using when you're building something that fits into an existing workflow and you don't fully understand that workflow yet.
Contextual inquiry sits between a user interview and pure observation. You're present while users do real work. You watch, you ask questions, but you're not running a usability test. The user isn't completing a task you've set. They're doing their actual job, and you're a quiet participant trying to understand it.
The method was formalized by Hugh Beyer and Karen Holtzblatt in their book Contextual Design (1998), but the core practice is simple: go to where your users work, watch them work, and ask questions about what you see.
What makes it different from a regular user interview is the environment. When you ask someone to describe how they handle a workflow, they give you the cleaned-up version. They describe it as they understand it, which often isn't quite how they actually do it. In context, you see the real version: the sticky notes on the monitor, the spreadsheet open in a second window, the moment they pick up the phone because the system doesn't do what they need.
Three categories of insight that contextual inquiry surfaces reliably and interviews often miss:
Workarounds people have forgotten about. Users adapt to their tools constantly. Over time, the workarounds become invisible, they're just "how things work." In an interview, they don't mention them because they're not thinking about them. Watching someone work surfaces them immediately.
Environmental context. The physical and digital environment shapes behavior in ways that users rarely articulate. Are they constantly interrupted? Do they have three monitors? Are they switching between the product and a competitor's tool? You can't know this from an interview, but it changes what you need to build.
The gap between stated behavior and actual behavior. People reliably describe their behavior in cleaner, more rational terms than how they actually work. Not because they're lying, because their mental model of what they do and what they actually do diverge. Contextual inquiry shows you the actual version.
Contextual inquiry is worth the investment in specific situations:
You're building something that fits into an existing professional workflow you don't fully understand. If your users are specialists (healthcare workers, financial analysts, industrial engineers, legal professionals) the context of their work matters enormously for what you build. An interview gives you a description. Contextual inquiry gives you the experience.
Your product has unexpected adoption or usage patterns. If users are doing things with your product that you didn't expect, contextual inquiry can show you why. What need is that unexpected behavior serving?
You're redesigning something that's deeply embedded in a workflow. Before rethinking a significant part of a product, understanding how it currently fits into users' actual work prevents you from breaking things they depend on that never made it into a requirements document.
Early-stage discovery in an unfamiliar domain. If you're new to a problem space, contextual inquiry accelerates the learning that would otherwise take months of interviews.
Contextual inquiry is time-intensive. Each session takes several hours including travel and debrief. For many research questions, a standard user interview or prototype test is more appropriate.
Skip contextual inquiry when:
Set expectations clearly. Tell the participant what you're doing: "I'd like to observe you doing your normal work for about 90 minutes. I'll ask questions about what I see. Don't change what you do for me, the normal, messy version is exactly what I'm here to see."
Observe first, ask second. Spend the first part of the session watching without asking many questions. Let them settle into their normal rhythm. Take notes on what you see: tools open, tasks they perform, moments of friction.
Ask about what you see, not what they think. "I noticed you copied that into a spreadsheet. Can you tell me more about that?" is better than "how do you handle data from this system?" You're grounding questions in observed behavior, not abstract self-report.
Master/apprentice framing. Beyer and Holtzblatt describe the relationship as master (the user) and apprentice (the researcher). You're there to learn from them, not to evaluate them. That framing shapes how you ask questions and how you respond to what you see.
Debrief immediately after. Your notes from the session will make much more sense to you right after than two days later. Write up your observations, what surprised you, and what you'd want to explore in a follow-up session within an hour of finishing.
Strict contextual inquiry requires being physically present. But a remote version is useful when in-person observation isn't practical.
Ask users to share their screen and walk you through their actual workflow, using real tasks from their current work. It's not identical to in-person observation (you lose the environmental context) but you get the real workflow rather than the described version. Watching someone use your product alongside five other open tabs teaches you something that "tell me how you use our product" never will.
Great Question's moderated interview features support this: research calendar scheduling, session recording, and observer rooms for teammates. The synthesis layer connects findings to your repository so this session informs future research.
Contextual inquiry is a qualitative research method where a researcher observes users in their actual work environment while they perform real tasks. It combines observation and interview techniques, with questions focused on what the researcher observes rather than abstract self-report. It's useful for understanding existing workflows, uncovering workarounds, and surfacing environmental context that shapes product usage.
A user interview asks participants to describe their experience or behavior. Contextual inquiry observes it directly, in context. The difference surfaces in what you learn: interviews produce the cleaned-up, conscious version of behavior; contextual inquiry shows the actual version, including the workarounds, interruptions, and environmental factors that users rarely mention unprompted.
Contextual inquiry is best for understanding an existing workflow or problem space before or during product design. Prototype testing is best for evaluating a specific design solution. Use contextual inquiry to inform what to build; use prototype testing to evaluate whether you built it well.
Typically 90 minutes to three hours per session, depending on the complexity of the workflow. Add travel time for in-person sessions and a 30-60 minute debrief after. Plan for a full day per participant for in-person sessions.
A remote version is possible: ask participants to share their screen and walk through their actual work using real tasks. You lose environmental context (physical setup, ambient interruptions) but gain access to the real workflow rather than a description of it. Great Question's moderated research features support remote contextual sessions.
See moderated interview features
Related: How to write a discussion guide for user interviews · User interviews for product managers · Customer discovery: how product builders do it fast · Remote user testing: how to run it
Tania Clarke is a B2B SaaS product marketer focused on using customer research and market insight to shape positioning, messaging, and go-to-market strategy.
.png)
.png)
.png)