01 / UNDERSTAND
What is contextual inquiry?
Contextual inquiry combines observation of real activity with questions asked close to the work. Associated with Hugh Beyer and Karen Holtzblatt’s Contextual Design approach, it treats the participant as an expert in their own practice.
The aim is to understand what people do, what shapes the activity and why their choices make sense in context. It is more than moving an ordinary interview into someone’s workplace.
Why use Contextual Inquiry?
People often omit routine details when describing a task. Watching the work can reveal documents, interruptions, informal coordination and workarounds that a product focused discussion misses. Asking about those moments helps prevent the team from assigning its own explanation to what it sees.
When to use it
USE IT WHEN
Work depends on a physical setting, other people or multiple tools.
A stated process differs from what seems to happen in practice.
The team needs to understand tacit decisions before redesigning a workflow.
When to choose another method
Use User Interviews when observation is impractical or the event has already occurred.
Use Diary Study for experiences spread across time and locations.
Use Usability Testing to evaluate a particular interface against a defined task.
What you’ll need
Agree a research focus, access arrangements and appropriate consent. Decide what may be recorded and how to protect bystanders and sensitive material. Recruit people doing relevant work, not only those comfortable demonstrating it. Prepare broad prompts and a note taking approach that distinguishes observation from interpretation.
What the method needs
Keep the elements that help answer your question and support a decision.
The actual setting, tools, people and constraints around the activity.
The participant explains the work while the researcher follows and asks.
Emerging explanations are checked with the participant.
A research purpose guides attention without excluding unexpected evidence.
02 / PUT IT INTO PRACTICE
How to conduct contextual inquiry
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Agree the activity and boundaries
Explain the purpose and what the visit will involve. Establish when the participant can pause or stop recording.
Ask which documents or conversations must stay out of the record.
02
Begin with the real workflow
Invite the participant to continue ordinary work where possible. Note when they are demonstrating or reconstructing instead.
A rehearsed example and a live case provide different evidence.
03
Observe before explaining
Record actions, artefacts and transitions in sequence. Keep your interpretation in a separate column.
Write that a person checks a paper list before inferring distrust of the system.
04
Ask at an appropriate moment
Use brief questions to clarify a decision without interrupting a critical action. Return to a moment when necessary.
What were you checking there? is more open than Why is the software unreliable?
05
Check the interpretation
Offer a tentative account and invite correction. Preserve disagreement rather than forcing confirmation.
Ask whether the workaround is routine or specific to this case.
06
Compare and model the work
Look across sessions for recurring dependencies and exceptions. Keep role, setting and source visible.
A useful Service Blueprint can distinguish customer interaction from supporting work.
07
Identify a change to investigate
Connect the observed constraint to a design question. Check what the current workaround protects before removing it.
Prototype the changed handoff, not just a cleaner screen.
Example: checking a repair request
Illustrative fieldwork scenario: a housing repairs coordinator checks a paper list before assigning an urgent request in the digital system. An observer might label this duplicate administration. In the invented account, the paper list holds contractor availability that the system does not yet reflect.
A follow up question reveals that assigning work too quickly can create a promise the contractor cannot keep. The paper step is compensating for a delayed update, rather than simply reflecting resistance to software.
The proposed design question becomes how to make confirmed capacity visible at assignment. Further sessions would examine whether this dependency recurs. The example does not establish that every coordinator works this way or that the paper list is the best solution.
03 / BELOW THE SURFACE
Below the surface: workarounds may carry a control
An apparently inefficient step can prevent an error that the formal process does not acknowledge.
FUNCTION
What does the workaround protect?
Look beyond its visible inconvenience.
REMOVAL
What could happen if it disappeared?
Trace the consequence to people and service delivery.
REDESIGN
Can the function survive in another form?
Compare a new arrangement with the current one.
Removing the paper check could make the interface faster while making the service less dependable. Before eliminating a workaround, identify what it protects. Ask what would happen if the step were skipped, who would notice and who would recover.
Then distinguish the protective function from the particular workaround. The team may be able to preserve the capacity check through a better arrangement. It should not preserve every legacy step merely because it exists.
This guide’s editorial lens is to compare the consequence of removal with the cost of retention. Observation supplies the episode; further evidence is needed to decide how broadly it applies.
Contextual Inquiry companion worksheet
The fieldwork worksheet separates an observed episode, a participant explanation and a researcher interpretation. Page two records the function of a workaround and the evidence needed before changing it.
Practical tips
Ask permission again when recording circumstances change.
Note interruptions and exceptions as part of the activity.
Common mistakes
Treating a demonstration as entirely natural behaviour.
Explaining a workaround before asking about it.
Removing friction without checking its protective role.
What you’ll get
A grounded account of activity and its dependencies, with traceable design questions. Use it to improve the work system as well as the interface.