Contextual Inquiry: How to Run It and What It Tells You

Learn how to plan, run, and analyse a contextual inquiry study — and discover why observing users in their real environment reveals what interviews alone never

What Is Contextual Inquiry?
Contextual Inquiry vs User Interviews: When to Choose Which
Planning Your Contextual Inquiry Study
Running the Session: A Step-by-Step Walkthrough
Analysing What You Observed
Common Mistakes and How to Avoid Them
What Contextual Inquiry Tells You That Other Methods Don’t
Frequently Asked Questions

What Is Contextual Inquiry?

Contextual inquiry (CI) is a structured field research method in which a researcher observes and interviews a participant inside their natural work or use environment. Rather than asking people to recall how they do something, you watch them do it — then ask questions as the behaviour unfolds in front of you.

The method was formalised by Hugh Beyer and Karen Holtzblatt as part of their Contextual Design framework, built around four core principles:

Context — data is collected on-site, not in a lab or over the phone
Partnership — researcher and participant work together to understand the work
Interpretation — the researcher shares observations aloud and checks their meaning
Focus — sessions are steered by a research question, not allowed to drift freely

CI sits at the intersection of ethnography and interviewing. It is not pure observation (you may ask questions) and it is not a standard interview (you are not reading from a list of prompts). That hybrid position is precisely what makes it useful — and what makes it easy to run badly.

For a broader view of where CI fits alongside other approaches, the UX research methods overview maps the full toolkit.

Contextual Inquiry vs User Interviews: When to Choose Which

The fundamental difference is this: interviews capture recalled behaviour; CI captures behaviour as it happens. Memory is selective and often self-flattering. When a participant tells you what they do, they tend to describe the idealised version. When they show you, the workarounds and friction appear.

Choose CI when:

The workflow is complex, multi-step, or involves several tools or physical artefacts
Users rely on tacit knowledge — things they do automatically and cannot easily describe
You suspect workarounds exist that participants would not think to mention
The environment itself shapes behaviour (a noisy warehouse floor differs from a quiet office)

Choose a standard interview when:

Your timeline is short and you cannot schedule site visits
Participants are geographically distributed and screen-share access is impractical
The topic is sensitive enough that observation would feel intrusive
You already understand the environment well and need to probe attitudes or motivations

A hybrid approach is worth considering when resources are tight. A 15-minute screen-share segment at the start of a remote interview — where you ask the participant to open their actual desktop and walk through a recent task — captures some of the situated richness of CI without the logistics of a site visit. It does not replace CI. But it is considerably more revealing than questions alone.

For a direct comparison across evaluation approaches, see usability testing vs user interviews.

Planning Your Contextual Inquiry Study

CI generates dense, layered data. Without a clear research question at the outset, you will surface interesting observations that lead nowhere. Narrow the focus before you recruit a single participant.

A workable research question is specific enough to constrain what you pay attention to. “How do people use our product” is too broad. “How do site supervisors log and escalate safety incidents while on shift” is the right level.

Participant criteria

Define role, environment type, and experience level before you start recruiting. For most studies, 4–8 participants per distinct user segment is sufficient — CI sessions are long and data-rich, so saturation arrives faster than it does with shorter interview formats. See the guidance on recruiting the right participants for screening approaches.

Access and logistics

For in-person CI, confirm site access and any permissions required (some workplaces need sign-off from security, legal, or a line manager) well in advance. Build travel time into your schedule. For remote CI, agree on the screen-share platform and check that participants have permission to share their actual desktop — not a demo or sandboxed environment.

Session guide

Draft three to five focus themes rather than a script. A rigid question list undermines the spontaneity that makes CI valuable. Your themes act as navigation landmarks, not a checklist to tick off.

Practical preparation

Prepare recording consent forms in advance
Decide whether sessions will be run solo or with a researcher-plus-note-taker pair (two people in a room changes the dynamic, so brief your note-taker on staying quiet)
Document the full study structure using a user research plan template

Running the Session: A Step-by-Step Walkthrough

Step 1 — Introduction (5 minutes)

Set the frame before anything else. You are the learner; the participant is the expert. Tell them explicitly: “I’m going to watch you work and ask questions as we go. There are no right answers — I’m here to understand how you actually do this, not how it’s supposed to work.” This framing — sometimes called the master–apprentice model — reduces the instinct to perform a polished version of the task.

Step 2 — Warm-up observation (10–15 minutes)

Ask them to begin a typical task and watch without intervening. Resist the urge to guide or clarify. Note what tools they open, what order they follow, and where they pause or switch direction.

Step 3 — Concurrent probing

Interject minimally. Short, open questions work best: “Why did you do that?” “What were you expecting to happen?” “Where does this usually live?” The goal is to understand intent without breaking flow. If in doubt, observe and note — you can revisit anything in the debrief.

Step 4 — Interpretation checks

Periodically surface your reading of what you have seen: “It sounds like you always check the previous entry before you submit a new one — is that right?” This validates your interpretation in real time and catches corrections before they bake into your analysis.

Step 5 — Debrief (10 minutes)

Ask about edge cases, exceptions, and what a bad day looks like. The routine tasks you observed may not represent the full range. “What would make this harder?” and “What’s the messiest this gets?” often open more useful ground than the session itself.

Practical notes

Silence is data. A long pause before a participant acts tells you something. Photograph physical artefacts — sticky notes, annotated printouts, whiteboards — with permission; they are often proxies for unmet system needs. Note emotional cues too: frustration, hesitation, the quiet satisfaction when something works as expected.

We ran one study with field-based workers where a participant opened a personal spreadsheet mid-session. It turned out to be a shadow system she had built because the official tool could not handle a common scenario. She had never mentioned it in a prior interview — it simply had not occurred to her. Observation surfaced it within the first twenty minutes.

Remote adaptation

For remote CI, screen share becomes the environment. Ask participants to work from their actual desktop rather than a demonstration account. You lose the physical environment — desk layout, printed artefacts, background interruptions — but the principle holds: you are watching real work, not a reconstruction of it. Note the environmental limitation in your study documentation.

Analysing What You Observed

Start within 24 hours. Memory of contextual sessions is unusually fragile — what felt vivid in the room fades quickly, and notes without context become ambiguous.

Affinity diagramming and sequence models

Group observations by task flow rather than by participant. The unit of analysis is what happens in the work, not who said what. An affinity diagram maps recurring themes; a sequence model traces the step-by-step structure of a workflow across participants, showing where paths converge or diverge.

Look for breakdowns

Moments of friction, unexpected tool switches, workarounds, and error-recovery sequences are the most analytically valuable observations you will collect. They signal where the gap between how a system was designed and how people actually use it is largest.

Surface behaviour vs intent

Contextual data is unusually good at revealing why people do what they do, not just what they do. Distinguish the surface behaviour (opened a second browser tab) from the underlying intent (needed a reference the main application could not display simultaneously). Design implications follow from the intent, not the behaviour.

Translate, don’t transcribe

Findings should be design-actionable insights: “Users need to cross-reference two data states simultaneously during the review step.” Not feature requests: “Users want a split-screen view.” For a repeatable approach to this translation step, see how to analyse user interview data — the synthesis workflow applies equally to CI data.

Common Mistakes and How to Avoid Them

Over-scripting the session

A rigid question list turns CI into an interview with a change of location. The value of CI is that unexpected things happen when you watch real work. A session guide with themes is right; a numbered question script is not.

Talking too much

Aim for roughly 70% observation to 30% questioning. If you find yourself speaking more than the participant, pull back. Narrate observations quietly in your notes and save the questions for the debrief.

Setting too broad a focus

“How people use our product” generates observations you cannot act on. Scope the focus to a specific workflow, role, or moment in the user journey before you start recruiting.

Skipping interpretation checks

If you do not surface your assumptions during the session, they compound during analysis. An unchecked inference in session three shapes how you interpret session four. Build in at least two or three interpretation checks per session.

Treating CI as a one-off

Products and workflows evolve. A CI study conducted at launch provides a baseline; it does not serve indefinitely. Teams that run CI once and never revisit it accumulate research debt in product teams — a growing gap between what they know and what is actually true about their users’ environment.

What Contextual Inquiry Tells You That Other Methods Don’t

CI surfaces tacit knowledge: the things users do automatically, without deliberate thought, that they genuinely cannot recall in an interview. These habitual behaviours are often the most consequential for design.

It exposes the real environment — competing tools open in adjacent windows, physical interruptions that break focus, spatial constraints that shape how a device is held or a screen is positioned. None of this appears in a lab session or a video call.

Workarounds are the most valuable single output. When a user builds a shadow spreadsheet, annotates a printed screen, or routes around a feature to use an older tool, each workaround is a clear signal of an unmet need. CI finds them reliably; interviews find them by accident.

There is a stakeholder benefit worth naming too. When product managers, engineers, or designers shadow CI sessions — even once — the effect on team empathy is substantial and durable. Abstract personas turn into observed human behaviour.

CI is the highest-effort method in the standard UX toolkit. It is also the highest-fidelity method for understanding complex, embedded workflows. Use it when the work you are designing for is genuinely hard to reconstruct outside its natural setting.

Frequently Asked Questions

How many participants do I need for a contextual inquiry?

4–8 participants per distinct user segment is typically sufficient. CI sessions are long and data-rich; saturation is usually reached faster than with shorter interview formats. Prioritise diversity of context — different sites, shift times, and experience levels — over raw headcount.

Can contextual inquiry be done remotely?

Yes, with adaptations. Screen share replaces physical observation; ask participants to work from their actual desktop rather than a demo environment. You lose environmental cues — desk setup, paper artefacts, background interruptions — but gain access to geographically distributed users. Note the limitation explicitly in your study documentation.

How long does a contextual inquiry session take?

Typically 60–120 minutes per session. Shorter than 60 minutes rarely allows enough time to move past surface behaviour; longer than two hours risks fatigue for both parties. Budget additional time for travel or technical setup depending on whether sessions are in-person or remote.

What is the master–apprentice model in contextual inquiry?

It is the relational frame used during the session: the participant is treated as the domain expert (master) and the researcher as a learner (apprentice). This framing encourages participants to show and explain their actual practice rather than performing a polished version of it — which is the core behaviour you are trying to observe.

How is contextual inquiry different from ethnographic research?

Ethnography typically involves extended immersion — days, weeks, or longer — with minimal intervention from the researcher. CI is bounded and purposive: sessions last one to two hours, there is a defined research focus, and the researcher actively probes and checks interpretations throughout. CI borrows ethnography’s commitment to natural context but operates at a pace and scope that is practical within a product development cycle.

About Glasgow Research — Glasgow Research helps B2B SaaS teams turn customer and market research into product decisions. Work with us.