3.3 Contextual Inquiry

At a Glance
Other names A Day in the Life · Field Study · Ethnographic Interview
In Brief
Contextual inquiry combines semi-structured interviews with direct observation of a participant in the actual environment where the problem occurs. You visit the participant’s workspace, watch them work, and ask questions in the moment to better understand the work. The output is a rich, qualitative picture of real workflows, tacit knowledge the participant cannot easily articulate, and workarounds that point to unmet needs.
Common Use Case
You have identified a pain point for your prospective user, but you aren’t sure about their real behavior and workflows. You visit them in person, watch them act in real situations, and discover behaviors and workarounds they never mentioned in interviews. You want to see the real behaviors so you can design a better solution.
Helps Answer
- What problems does the participant actually experience in their environment?
- What workarounds or substitute products is the participant already using?
- How often does this problem happen in practice?
- What does the participant know about the problem that they cannot easily put into words?
- What steps make up the participant’s real workflow?
Description
In contextual inquiry you visit the participant’s actual environment, watch the work happen, and ask questions in the moment rather than after the fact. You model an expert/apprentice relationship: the participant is the expert in their own work, and you are the apprentice learning it.
Observation produces different data than interviews because participants can only describe what they consciously do; they cannot describe the workarounds, sticky-note hacks, and tacit shortcuts they don’t notice themselves doing. A retrospective interview gets you the participant’s mental model of their work. A contextual inquiry gets you the work itself — including the parts the participant would never think to mention. Workarounds, environmental constraints, and interruptions tend to appear only when you watch the work happen.
Contextual inquiry rests on four principles that describe how you behave on-site. Context means going to the real place where the work happens, not a conference room. Partnership means treating the session as a shared inquiry — the participant drives the work, you follow and ask. Interpretation means voicing your reading of what you just saw and inviting the participant to confirm or correct it. Focus means having a defined research question so you notice what matters and don’t drown in everything.
The output is qualitative and small-sample. It produces hypotheses, not statistics — pair it with a downstream evaluative method (Paper Prototyping, Comprehension Test, closed-ended survey) once the field data has shaped a hypothesis worth testing.
How to
Prep
-
Define your research question. Create one clear research question. For example, “How do mid-market accountants actually close the books at month-end?” “Learn about accountants” is not sufficiently focused. The question shapes what you’ll watch for and which workflow steps you’ll ask the participant to walk you through.
-
Recruit five or more participants in their real environment. A contextual inquiry done at the participant’s desk during their actual workday produces different data than one done over coffee. If the problem only happens at certain times (month-end close, surge periods, mornings), schedule the visit for then. Recruit at least five participants — small samples mean any single observation is anecdote until a pattern repeats.
-
Train the observer pair. Pair the lead researcher with a second observer when possible — one focuses on the work, the other captures notes and timestamps. Both should agree in advance on what counts as a workaround worth probing. If you’re solo, plan to record the session so you can re-watch instead of trying to take notes mid-observation.
-
Prepare a framing statement. Two or three sentences you read at the start of the session: who you are, what you’re trying to learn, that you’ll mostly watch, and that you may interrupt occasionally to ask what they just did. Make clear they’re the expert and you’re the apprentice — something like “I’d like to watch you do [task] the way you normally would. I’ll mostly watch and ask a few questions along the way.”
-
Prepare an observation checklist, not a script. Unlike an interview, you’re not running a list of questions. You’re going to watch real work. The checklist is a reminder of which workflow steps and decision points you want to make sure get covered if they don’t surface naturally. Include space for: workarounds noticed, tools or substitute products in use, interruptions, body language during difficult moments.
-
Get permission to record. Audio at minimum, video or screen-share if it doesn’t change behavior. Promise the participant you’ll send them a summary and ask before quoting them anywhere.
Execution
-
Set the expert/apprentice frame. Read the framing statement you prepared. Establish that the participant drives the work and you follow. Get explicit consent to record.
-
Observe first, ask later. Resist the urge to interrupt. The participant will work through steps that look obvious to them but contain the real signal. Note questions for later — most will be answered in the next two minutes of work without you asking.
-
Probe in the moment, but only when it’s natural. When the participant hits a workaround, a hesitation, or an interruption, that’s the moment to ask. “What just happened there?” or “Why that step?”
-
Voice your interpretation and let them correct it. Every fifteen or twenty minutes, summarize what you think you just saw: “It sounded like the reason you copied that into a spreadsheet is because the report doesn’t sort the way you need.” The participant will either confirm or correct you.
-
Keep the focus tight. Participants will volunteer adjacent stories, edge cases, and complaints about other tools. Note them, but bring the conversation back to the workflow you came to observe. The principle is focus: a session that drifts produces broad context but no usable signal.
-
Note what’s around the work. Sticky notes, dual monitors, printed-out cheatsheets, a chat window the participant keeps minimized, coworkers wandering by. The environment is data. A printed-out cheatsheet next to a software interface is the participant’s own admission that the software doesn’t work the way they need.
-
Run the remote variant when in-person isn’t possible. For distributed teams or software-only workflows, ask the user to share their screen on a video call while they work through a real task — not a demo, but actual work they’d do anyway. Record with permission. You lose physical context (desk setup, body language, interruptions), but for software products screen-sharing often reveals more about the digital workflow than an in-person visit would.
-
Wrap with a summary and clarifying questions. In the last five minutes, summarize the workflow back to the participant and ask any remaining clarifying questions. Confirm permission to follow up by email if you have a question after debrief.
Analysis
-
Debrief while it’s fresh. Within an hour of the session, sit down with your notes and the recording and write up: the workflow as observed, every workaround noticed, every place the participant hesitated, every place the environment intruded. Two hours of debrief per session is normal.
-
Run an interpretation session. With your team, walk through each session’s notes and surface every observation as an explicit interpretation: “When the participant copy-pasted the report into a spreadsheet, that means the built-in sort is unusable for their workflow.” This is the team’s chance to challenge each interpretation. Disagreement means you don’t yet know what you saw and need to look at the recording or follow up with the participant.
-
Group similar observations together. Take every observation, every workaround, every interpretation across all sessions and put each on its own sticky note (physical or digital), then group them by what they have in common, not by which session they came from — a technique called affinity diagramming. The clusters that emerge are the patterns. Single-session observations that fit no cluster are anecdotes — note them, but don’t build on them.
-
Identify workflow patterns. Look across the clusters for repeated structures: the same workaround appearing in different sessions, the same decision point repeatedly going wrong, the same environmental constraint appearing across different participants. A pattern that shows up in three of five sessions is a pattern. A behavior that shows up in one session is a hypothesis worth probing further.
-
Be honest about sample size. Five participants is enough to surface patterns; it is not enough to claim those patterns generalize. State what you observed, in how many sessions, with what variation. Resist extrapolating qualitative observations to the entire population — write findings as “in five sessions we saw X” rather than “users do X.”
-
Synthesize into a hypothesis worth testing. The output of analysis is one or two clear hypotheses for downstream evaluative testing — a paper prototype to test against a workaround you discovered, a closed-ended survey to size how widespread the workflow pattern is, a comprehension test on a value proposition you can now articulate. Contextual inquiry doesn’t end the research; it sets up the next round.
- Confirmation bias The researcher arrives with a hypothesis and notices only the evidence that supports it. Mitigate by writing your assumptions down before the session and assigning a teammate to actively look for evidence against them.
- Observer effect The participant changes their behavior because they know they’re being watched, especially in the first ten minutes. Mitigate by asking them to start with a routine warm-up task before getting to the work that matters, and by making your framing statement explicit that there’s no right or wrong way.
- Leading interpretation When voicing your interpretation, you can phrase it in a way that traps the participant into agreeing. Mitigate by phrasing interpretations as questions (“It looked like X — is that right?”) rather than statements, and by inviting correction explicitly.
- Sample bias Participants willing to host a contextual inquiry skew toward those who are organized, articulate, and like to demonstrate competence. The people who would benefit most from your product may be the least likely to volunteer. Mitigate by recruiting through multiple channels and noting which segments you couldn’t reach.
Learn more
Case Studies
Christensen: Milkshake jobs-to-be-done observation
Clayton Christensen’s account of observing when and why customers bought fast-food milkshakes, finding they were “hired” as a commute breakfast rather than chosen as a dessert.
Lucky Iron Fish: Living with Cambodian families
Researcher Christopher Charles lived with rural Cambodian families to develop an iron-deficiency intervention; Gavin Armstrong later founded Lucky Iron Fish to commercialize the product.
Moen: Cameras in shower heads
Moen placed tiny cameras in shower heads of volunteer participants to observe actual showering behavior, then redesigned a shower-head line around the findings; the redesign won the 2013 GOOD Design Award.
IDEO: Shopping cart redesign on Nightline
In the 1999 ABC Nightline “Deep Dive” segment, IDEO designers observed how shoppers actually used carts in stores, then redesigned the supermarket cart in a week as a demonstration of observation-driven design.
LEGO: Home visits during 2003 near-bankruptcy
Marketing visited an 11-year-old German skateboarder whose worn Adidas sneakers — held up as his proudest possession — revealed that mastery and the social status it conferred mattered more than instant gratification, shifting LEGO’s strategy toward complex brick sets.
Intuit: Follow Me Home program
Intuit’s long-running “Follow Me Home” program sends employees to observe customers using Quicken, QuickBooks, and TurboTax in their own homes and offices to surface workflow interruptions that interviews alone would miss; the team mantra is “look to be surprised.”
Further reading
- Beyer, H. & Holtzblatt, K. (1997). Contextual Design: Defining Customer-Centered Systems. San Francisco, CA: Morgan Kaufmann.
- Holtzblatt, K., Wendell, J. B., & Wood, S. (2004). Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design. San Francisco, CA: Morgan Kaufmann.
- Whiteside, J., Bennett, J., & Holtzblatt, K. (1988). Usability engineering: Our experience and evolution. In M. Helander (Ed.), Handbook of Human-Computer Interaction. New York, NY: Elsevier Science Publishing. 791-817.
- Nielsen Norman Group: Contextual Inquiry — A UX Research Method
- InContext Design — About
- Intuit Developer Blog: Why every company should be doing a Follow Me Home (2021-01-21)
- Guiseppe Getto — Contextual Inquiry with AI (2025)
- Nikki Anderson-Stanier — Behind the Scenes: Contextual Inquiry (Dscout People Nerds)
Got something to add? Share with the community.