How to run a contextual inquiry

Most user interviews are run in a room the customer would never use the product in. The participant gets a calendar invite, opens Zoom from a tidy desk, recalls their work from memory, and answers in past tense. The transcript reads coherent and ships nothing, because the part the team needed to see (the cluttered second monitor, the spreadsheet open in the background, the shortcut nobody on the product team knew existed) was never on screen. Contextual inquiry exists to put the work back into the conversation, and the conversation back inside the work.

This is a working playbook on how to run a contextual inquiry that surfaces the workflow the participant cannot summarize from memory: scope the work, place the observation surface inside the work itself, open with apprenticeship instead of an interview script, probe in the moment with the right depth, build the affinity diagram from raw artifacts, and tie each observation to a decision the product team is about to make. The piece sits inside the wider voice user research guide and pairs with the playbooks on diary studies with voice notes, jobs to be done interviews, and affinity diagrams.

What a contextual inquiry actually is

A contextual inquiry is a qualitative field method in which a researcher observes a participant doing real work in their real environment, and asks questions about what the participant is doing while they are doing it. The output is a set of grounded observations about the participant's workflow, the artifacts they touch, the workarounds they have invented, and the breakdowns they have learned to live with. The method was codified by Karen Holtzblatt and Hugh Beyer at Digital Equipment Corporation in the mid-1990s and documented in Contextual Design (1998), a book that still anchors how the Nielsen Norman Group teaches the method today.

The unit of analysis is not the participant's opinion. It is the work itself: a discrete task or stretch of activity that the participant is performing right now or about to perform, with their tools, in their location, on a normal day. A contextual inquiry that drifts into "tell me about how you usually do X" has stopped being a contextual inquiry and has become an ordinary interview that happens to take place in someone's office. The difference is whether the data is observed or remembered.

Two properties separate a contextual inquiry from a usability test, an ethnographic study, and a regular interview. First, the participant is doing their own work, on their own terms, not a moderator's task. Second, the researcher is positioned as an apprentice asking the participant (the master of their own work) to explain what they are doing as they do it. The "master and apprentice" framing is not a metaphor; it is the operational model that prevents the researcher from leading the participant into the team's prior hypothesis.

The four contextual inquiry principles

Holtzblatt and Beyer name four principles. Each is a corrective for a failure mode that ordinary interviews routinely fall into. Naming them before the session is what keeps a contextual inquiry from collapsing into a friendly chat about software.

• Context. The conversation happens where the work happens. A participant at their desk, with their tools open, surrounded by the artifacts of the job. Not a conference room, not a video call from a hotel lobby, not a recalled story.
• Partnership. The relationship is master and apprentice. The participant teaches, the researcher learns. The researcher does not test, evaluate, or steer. A good apprentice asks "what are you doing now, and why" and gets out of the way.
• Interpretation. Observations are interpreted on the spot, with the participant. "It looked like you got frustrated when the export failed. Is that fair?" The participant either confirms or corrects. The shared interpretation is what later survives synthesis; an interpretation the researcher invented alone is the one that gets overturned in the readout.
• Focus. The session has a research focus, not just a topic. "How does the participant prepare a weekly report for their CEO" is a focus. "Get user feedback" is a topic. Focus is what lets the researcher decide which moments to slow down on and which to let pass.

The four principles work together. Lose context and the participant is recalling instead of working. Lose partnership and the participant performs instead of demonstrating. Lose interpretation and the field notes drift the next morning. Lose focus and the session ends with five hours of footage and no findings.

How to run a contextual inquiry, step by step

Seven steps. The shape is faithful to the original Holtzblatt and Beyer method, with two adaptations for distributed product teams who cannot fly to every participant's office, and who instead place the observation surface inside the work itself so the participant captures the moment as it happens.

01 · Scope the work being observed

The first decision is what work the inquiry is about. A contextual inquiry that tries to observe "how customers use our product" produces five hours of unsorted footage and no usable finding. A contextual inquiry scoped to "how a customer service manager assembles the Monday weekly metrics email for their VP" produces a thirty-minute session, a clear affinity diagram, and three roadmap candidates.

Two parameters to lock before recruitment:

• The job. A specific, repeatable stretch of work the participant performs as part of their role. Concrete enough that a colleague would recognize it. "Assemble the Monday metrics email" passes. "Use spreadsheets" does not.
• The trigger. What kicks the work off. The Monday morning calendar reminder, a Slack message from a stakeholder, a customer ticket that escalated. The trigger is what the inquiry uses to time the observation; without it, the researcher is asking the participant to start the work to order, which is no longer contextual.

The same scoping discipline that grounds jobs to be done interviews applies here, with one substitution: jobs to be done reconstructs a past switch, contextual inquiry observes a present task. Both need a tight unit. Neither survives a vague one.

02 · Recruit participants doing the work this week

Recruitment for contextual inquiry is not the same as recruitment for an interview. A participant who is happy to talk about their workflow is easy to find. A participant who is doing the specific work this week, on a normal day, with their normal tools, in their normal location, and is willing to be observed during it, is rarer.

Two screener questions usually do the work. First: "Are you scheduled to do this week or next?" Reject anyone whose answer drifts into the past tense. Second: "Where will you be when you do it?" Reject anyone whose answer is "in a meeting room" or "at the office, but I can step away." The room is part of the data. The general rules of thumb on recruiting user research participants hold, with the additional filter that the participant has to be observable during the work itself.

A workable cohort is six to eight participants per role per study. Below five and the patterns are not stable. Above ten and the field notes become unread.

03 · Set up the observation surface

The classic contextual inquiry is a researcher sitting next to a participant for two hours. That model is still the best one when it is operationally possible. It is rarely operationally possible at the scale a product team needs, and the substitute is not to drop the method but to move the observation surface to where the participant already is.

Two formats hold up in practice:

• Live remote, with the participant's screen and audio captured. The researcher joins on video, the participant shares their screen, and they work through the task together. Closest to the original method; calendaring is the limit. The participant has to set aside a two-hour block for an observation that has to happen during work that has its own clock.
• In-context capture, where the participant answers prompts inside the work itself. A study link placed on the screen where the work happens (a chat command in the team's workspace, a contextual prompt next to the feature, a persistent link in the tool's help menu) so the participant can record a voice note, type, pick a choice, or rate a moment as they hit it. The researcher reviews the artifacts the next morning instead of the next quarter.

The in-context format gives up the live researcher's ability to redirect mid-session. In exchange it preserves the actual work being done (the participant is not stepping away to be observed; they are working, and the observation is happening). For most distributed product teams it is the format that makes a contextual inquiry happen at all. The diary-study counterpart is documented in how to run a diary study with voice notes; the difference is that a diary study spans days or weeks, where a contextual inquiry zooms into one stretch of work.

Set the participant's input modes deliberately. Voice when the participant is alone at a screen and can talk; text when they are in a shared space or on the train; choice when the prompt has a small fixed set of plausible answers; rating when the team wants a comparable measure across participants. Each mode catches signal the others lose; constraining the participant to one mode discards three quarters of what they would have said. The qualitative case for letting the participant pick is in voice vs text surveys.

04 · Open with apprenticeship, not interview

The first five minutes of a contextual inquiry set the partnership. An interview script that opens with "tell me about your role" recasts the participant as a respondent and the researcher as an interviewer, and the rest of the session is colored by the framing.

The right opening is closer to "I'm here to learn how you do this. Start the work the way you normally would, and talk me through it as you go. I'll ask the dumb apprentice questions when I'm not sure what I'm looking at." Two effects: the participant relaxes, because they have been positioned as the expert; and the researcher gets permission to ask the questions whose answers contain the data ("what is that window you just opened", "why did you copy that cell into a different sheet", "what did you just hesitate about").

A useful apprentice question is concrete, anchored to a moment the participant just lived through, and free of any judgment about whether what the participant did was the right way to do it. The craft of writing questions that open people up rather than close them down is in how to write user research questions; the contextual inquiry case is the strictest version, because the question has to fit between two seconds of observed work without breaking the flow.

05 · Probe in the moment, at the right depth

The follow-up is where a contextual inquiry produces data that an interview cannot. The participant just did something unexpected; the apprentice question that lands in the next two seconds either recovers the reasoning ("I always copy it because the formula in the original sheet breaks when the date changes") or loses it forever. In a live session a senior researcher does this by reflex. In an asynchronous one, an AI moderator does the same work by reading the participant's last answer and deciding whether to probe.

Set the probing depth per question, not globally. Three settings cover most contextual inquiries:

• Shallow. At most one clarifying probe. Best on short tasks where the participant is mid-flow and a long detour kills the rest of the work. Use it on the warm-up prompts ("walk me through what triggered this work today") where you only need one layer.
• Medium. A small chain of probes when the participant's previous answer is still vague or contradicts what the artifact on screen shows. The default for most of a contextual inquiry, where each moment of observed work is one prompt and the second or third probe is where the reasoning surfaces. The AI re-reads the running thread after each probe and stops when the answer is rich enough.
• Expert. The AI keeps probing until the answer has the same context a senior researcher would dig out in a moderated session: contradiction, scope, who else is involved, when this last happened, what prior alternatives the participant tried, what would have made them choose differently. Capped only when the model is satisfied or the participant disengages. Reserve it for the highest-stakes moments in the session (the breakdown, the workaround, the moment of frustration) rather than the whole study, because expert depth is more demanding of the participant's attention.

The participant retains the right to skip on every probe. A probe that gets skipped seventy percent of the time is a signal that the probe was the wrong one, not that the participant is uncooperative. The longer treatment of how depth choices interact with response rate sits in AI follow-up questions in user research.

"Yeah, I always paste the numbers into this second sheet first, because if I link them directly the dashboard breaks every time the team adds a new column. Nobody on your side knows about this. I've been doing it for two years."

That sixty-second answer carries a workflow detail, a breakdown ("the dashboard breaks"), a workaround ("paste into a second sheet"), and a piece of organizational evidence ("nobody on your side knows"). None of those would have shown up in an interview that asked the same participant "how do you use the dashboard?" the following week.

06 · Build the affinity diagram from raw artifacts

Contextual inquiry produces a particular kind of raw material: short observed moments, each one tied to an artifact (a screenshot, a voice clip, a typed sentence) and a moment in the participant's workflow. The synthesis step is to cluster those moments into themes without losing the participant's voice on the way through. The original Holtzblatt and Beyer method uses an affinity diagram for exactly this; the working guide on how to run an affinity diagram covers the mechanics in detail.

The two rules that matter most for the contextual inquiry case:

• Cluster moments, not paraphrases. Each card on the wall is one observed moment, in the participant's words, with a citation back to the original recording or screenshot. Two participants describing the same breakdown become one theme with two pieces of evidence. The label on the theme is the team's gloss; the evidence is the participant's. The wider note on synthesizing user research holds here.
• Keep the workarounds visible. The most valuable output of a contextual inquiry is usually the workaround the team did not know about. A participant who pastes numbers into a second sheet, exports to CSV before sharing, screenshots a dashboard instead of using a share link, or maintains a parallel spreadsheet outside the product, is naming a breakdown the product caused and patched around. Cluster workarounds together. They are the candidates for the strongest roadmap moves.

The synthesis should stream as the artifacts land, not wait for the end of fieldwork. A contextual inquiry across six participants over two weeks should produce a synthesized view of the themes by the end of week one, not a deck at the end of week three. The streaming-synthesis pattern is the same one that powers continuous pain-point and customer journey map work: structured themes, quotes, and citations available to the team as the responses land, and to the agents the team builds with for downstream use (a release-note generator, a roadmap helper, a retention alert).

07 · Tie observations to a decision the team will ship

The last step is the one that decides whether the inquiry mattered. Each cluster of observations either becomes a decision the team is about to make, or it does not.

Two rules:

• Observation to decision, not observation to backlog. A row in a backlog is a deferral. A decision is "we will ship a fix for the dashboard column problem this sprint, scoped to the workaround the participants showed us." Name the call, name the slot, name who owns it.
• Reply to the participants. A participant who recorded a sixty-second voice note about their workaround should hear back, by name, when the team ships the fix the recording prompted. One sentence is enough. Closing the loop is what keeps the same participants willing to record the next prompt. The mechanics are in the customer feedback loop playbook.

The downstream artifacts to update from a contextual inquiry are usually three: the relevant rows on the customer journey map, the empathy texture in the empathy map for the persona, and the opportunity branches on the opportunity solution tree. A contextual inquiry that does not refresh any of those three has produced field notes; one that refreshes all three has produced a research artifact a roadmap can be built from.

Why async voice and text changes contextual inquiry

The original contextual inquiry assumed a researcher on a plane. Holtzblatt and Beyer's customer base in the mid-1990s was enterprise software vendors who could put a researcher in the customer's office for two days. That assumption is what kept the method out of reach for most product teams for thirty years. The shape of the method (observe the work in its real context, ask in the moment, interpret with the participant) was sound. The shape of the operations (a researcher on a plane) was not.

The async version preserves the shape of the method and replaces the operations. The participant is at their own desk, doing their own work, on their own normal day. The observation surface is a study link inside the work itself: a Slack command, a contextual prompt next to the feature, a persistent link in the help menu, a one-question card after a key task completes. The participant answers in voice, text, choice, or rating, at the moment of the work, not the calendar slot two weeks later. The AI probes in the moment with the depth the researcher set per question. The themes synthesize as the artifacts land. The team reviews the cluster the next morning, not the next quarter.

The trade-off is real and worth naming. The async version loses the researcher's ability to redirect a session live ("can you show me what happens when you click that other tab"). The compensation is volume: the same study link can run across dozens of participants in a week, the synthesis is continuous, and the affinity diagram refreshes against new evidence without anyone calling a new project. The continuous version of the method is the one most product teams can sustain past month two; the on-a-plane version is the one they intend to and never quite do.

The async pattern also opens contextual inquiry to a use case the original method did not address. The same study link can be shared in internal channels for a synthesized view of how engineers, designers, support agents, and finance leads do the work they are about to ask the product team to support. The internal contextual inquiry is the fastest way to surface workflow assumptions a feature is going to break before the build commits. Share the link in the team's Slack, get the synthesized cross-functional view of the work the next day, ship the design that does not break it.

When contextual inquiry is the wrong tool

Three cases where running a contextual inquiry makes the team feel rigorous while producing the wrong artifact.

Pre-build, no workflow yet to observe. Contextual inquiry assumes there is real work being done. A team pre-launch with no customers using the product cannot observe the workflow because the workflow does not exist. The right artifact for a pre-build question is concept testing on the value proposition, or customer discovery interviews on the segment the team thinks it is building for.

Quantitative volume questions. "How long does the average user spend on the dashboard" is a product-analytics question, not a research question. Trying to answer it with six contextual inquiries produces a guess that costs ten times as much as a query in PostHog or Amplitude. Contextual inquiry is the wrong shape for any question whose answer is a number across the whole customer base.

Evaluation of a finished design. A contextual inquiry observes the work as the participant naturally does it. A usability test asks the participant to perform tasks the moderator designed, against a specific interface, with a defined success criterion. Mixing the two produces an artifact that is neither: not a usability score, not a workflow observation. Pick one. The usability testing playbook covers the other shape; the contextual inquiry shape is the one for observed work, not designed tasks.

FAQ

What is a contextual inquiry?

A contextual inquiry is a qualitative field method in which a researcher observes a participant doing real work in their real environment, and asks questions about what the participant is doing while they are doing it. The method was codified by Karen Holtzblatt and Hugh Beyer in Contextual Design (1998) and remains the canonical approach to observing real work in real context. The output is a set of grounded observations about the participant's workflow, the artifacts they touch, the workarounds they have invented, and the breakdowns they have learned to live with, each anchored to a recording or screenshot the team can return to during synthesis.

How is contextual inquiry different from a regular user interview?

A user interview asks the participant to recall and summarize their work in the past tense. A contextual inquiry observes the work in the present tense and asks about it as it happens. The two methods produce different artifacts and answer different questions. An interview surfaces what the participant believes about their work; a contextual inquiry surfaces what they actually do. Both are useful at different moments in product research. They are not interchangeable, and substituting one for the other is the most common failure mode in junior research practice.

How long does a contextual inquiry take?

A traditional live contextual inquiry runs two to three hours per participant: enough time to observe a meaningful stretch of work, interpret moments together, and wind down. Async in-context formats split the same observation across shorter prompts that fire during the work itself, totaling roughly 10 to 30 minutes of recorded answer per participant across a few days. Both formats produce the same kind of artifact: observed work in context, anchored to specific moments the team can return to. The async version trades the live researcher's redirect for the volume that lets the method run continuously instead of as a one-off project.

How many participants does a contextual inquiry need?

Six to eight participants per role per study is the working default. Below five and the patterns are unstable; a single loud participant's workaround can dominate the affinity diagram and mislead the team. Above ten and the field notes become unread, and the marginal participant adds little against the cost. Saturation in contextual inquiry behaves similarly to qualitative interviewing more broadly; the practical defaults are documented in how many user interviews do you need.

Can a contextual inquiry be done async?

Yes, with one trade-off. The async version preserves the core of the method (observing real work in its real context, asking in the moment, interpreting with the participant) and replaces the operations (a researcher on a plane) with an observation surface inside the work itself: a study link in the tool the participant uses, an AI moderator that probes at the depth the researcher set per question, and a synthesis engine that streams themes and citations as the artifacts land. The trade-off is the loss of the live researcher's ability to redirect mid-session. The compensation is volume and continuity: the method can run as a standing instrument across dozens of participants instead of a quarterly project.

What is the difference between contextual inquiry and ethnographic research?

Ethnographic research is a broader method that immerses the researcher in a participant's environment over an extended period to understand culture, behavior, and meaning. Contextual inquiry is narrower and more applied: it borrows the in-context observation and the master-apprentice framing from ethnography, but focuses on a specific job and trigger rather than a whole culture, and produces decision-grade observations on a product team's clock. Ethnography is months; contextual inquiry is days or weeks. Both are legitimate. They answer different questions.

---

Contextual inquiry is not a deliverable from a quarterly research project. It is a way of seeing the work the product is supposed to support, in the place where the work actually happens, before the team ships the next thing that has to fit into it. The original method needed a researcher on a plane. The continuous version needs a study link placed inside the work, an AI moderator that probes at the depth the researcher set, and a synthesis engine that streams themes back to the team as the artifacts arrive. Talkful runs the pipeline behind the continuous version: a standing link on every surface where the work happens, voice or text or choice or rating from the participant's pick, configurable adaptive probes that turn the polite first answer into the honest second one, and a synthesis engine that streams themes and citations to the team as the responses land, ready for the trio to act on or for the agents you build with to ship from. The wider voice user research guide covers where the practice sits inside a continuous product-research rhythm.