Contextual inquiry combines observation of real work with questions about what is happening. Watch a relevant task in its normal setting, ask for clarification at a sensible pause, check your interpretation with the participant, and turn the evidence into a specific design question. The useful result is an explanation of the workflow, including the interruptions and workarounds that an interview summary may leave out.
Use it when a product depends on how people coordinate information, tools, and other people. A library circulation desk, for example, involves more than the borrowing form on a monitor: returned items, reservation slips, conversations, and staff handovers can all change the next action.
After the fieldwork, use a workflow prototype to explore the design implications with your team. Keep observation and design separate: first establish what happened, then propose an interface response. The library example below is an illustrative scenario, not a report of completed research.
When contextual inquiry is the right method
The method is especially useful when people say that a process is straightforward but cannot explain every exception from memory. You might need to understand how a support agent finds the right record, how a coordinator handles an interrupted request, or how a worker decides which of several documents is authoritative.
Nielsen Norman Group describes contextual inquiry as observation and interviewing in the user's natural environment. Its distinguishing feature is the opportunity to clarify a particular action in context, rather than asking someone to reconstruct the whole process later.
Choose a different approach when the question is narrower. To investigate whether a new interface supports a defined task, run a usability test. To understand a participant's account of a past decision, a user interview may be enough. When relevant events occur unpredictably over several days, a research diary study can capture experiences you would otherwise miss. These methods can complement one another without producing interchangeable evidence.
Define the work episode you need to understand
Start with a question that identifies a process and a gap in understanding. “How do staff decide where a returned reserved item goes?” is more useful than “How do people use our software?” It gives you a reason to observe particular work without prescribing what the participant should do.
For the library scenario, include the period from accepting a returned item to placing it in its next physical location. Note the people, screens, slips, and shelving areas involved. If the software team only studies the screen after a barcode is entered, it could miss the handoff that determines whether the item is ready for collection.
- Recruit for relevant experience: people who actually perform the work, including meaningful differences in responsibility or setting.
- Choose a useful time: the task must be likely to occur. A quiet hour may reveal a different workflow from a busy shift.
- Agree the boundaries: explain observation, recording, who can see the material, and how the participant can pause or stop.
- Prepare a fallback: if the task does not occur, record that limitation. A narrated demonstration can help, but label it as a demonstration.
Do not ask people to reveal unrelated customer information just to make the session realistic. Arrange approved masking, restrict what is recorded, and follow the site's access rules. If an interruption could create a safety or service risk, save the question for a later pause rather than making the research protocol the priority.
Observe the sequence, then clarify the decision
Begin with a short introduction to the task and setting. Let the participant continue their normal work. Record a sequence of actions rather than a list of impressions: which item was opened, which information was checked, what caused a pause, and where responsibility moved next.
In the illustrative library episode, a staff member scans a returned book, places a small slip inside it, and moves it to a separate trolley. A colleague asks a question before the staff member completes the on-screen action. The interesting question is not whether the person likes the interface. It is how they recognize unfinished work after that interruption.
| What you notice | A neutral clarification | A leading question to avoid |
|---|---|---|
| A slip is inserted into the book. | “What does this slip tell you?” | “Is this your workaround for the bad software?” |
| The person checks another screen. | “What are you looking for here?” | “Would a dashboard solve this?” |
| An item remains on a separate trolley. | “How do you decide where this goes next?” | “Should this be marked ready now?” |
| Work resumes after a conversation. | “How did you know where to pick up?” | “Did the interruption make you forget?” |
Ask about the event you saw. If the person offers an explanation, distinguish it from the observation in your notes. “I always put them here” is a participant's account of a routine; one observed item does not establish how often that routine occurs.
Make space for correction. “I think the slip identifies a reservation, but it does not mean the book is ready to collect. Have I understood?” exposes your interpretation so the participant can challenge it. Do not turn that check into an argument for the feature you wanted to build.
Keep evidence, interpretation, and ideas in separate fields
A useful field note lets another researcher follow your reasoning. Include an event reference, the observed action, any relevant words, your interpretation, and an unresolved question. Use approved pseudonyms or identifiers; the design team usually does not need the person's name or a patron's borrowing history.
For the library example, an illustrative note might read:
| Field | Example note |
|---|---|
| Observed event | After scanning a reserved item, the staff member puts a slip inside it and moves it to a separate trolley. |
| Clarification | The staff member explains that a colleague still needs to check the collection location. |
| Interpretation to investigate | “Returned” and “ready for collection” may be separate operational states. |
| Open question | What evidence allows the next staff member to complete that check? |
| Possible design response | Show a distinct pending-location-check state with an assigned next action. |
The last row is a proposal, not an observed fact. A visible status may help, but it could also duplicate a reliable physical process or expose information to the wrong role. Investigate the handoff before deciding that a new screen is the answer.
A single episode is a useful lead. Look for confirming and conflicting cases across relevant participants and situations. Do not convert a qualitative observation into a statement such as “most library staff lose their place” without evidence supporting that population claim.
Turn the finding into a bounded prototype question
Suppose further investigation supports the distinction between returned, awaiting a location check, and ready for collection. The design question becomes: can the next staff member understand the item's current state and the action they are responsible for? This is specific enough to explore without redesigning the entire circulation system.
Create a small sequence with fictional records: an item awaiting a check, the relevant location information, and the confirmed result. In Mockitt, connect the screens to make that sequence reviewable. Add a screen-specific comment containing the design question and an approved reference to the research finding. Keep detailed research records in the agreed research location.
For this example, the comment could say: “Can a colleague distinguish a returned item from one ready for collection? Review the pending check and confirmation states.” It should not contain private patron details or claim that the prototype already proves the solution works.
The follow-up study should exercise the proposed handoff. Ask a relevant participant to determine what can happen next from the available information. Observe whether the proposed labels and states support the task, including what happens after an interruption. A positive reaction to the screen is different from evidence that the workflow is understandable.
Deliver the workflow evidence, not just a feature list
A useful handoff includes the current sequence, important variations, supporting observations, and the design decisions still open. Include the artifacts and people that influence the work, even when they sit outside your product. A paper slip may carry context that a digital replacement must preserve.
Also state what you did not observe. Perhaps the session covered returns but not closing-time reconciliation, or only experienced staff were available. Those limits guide the next research choice; they do not make the observed evidence worthless.
Contextual inquiry earns its place when it changes the team's understanding of the work. In the library example, the valuable outcome is recognizing a separate handoff and checking what makes it complete. The prototype then gives the team a focused way to investigate a response to that finding.