Contextual Inquiry: A Field Method for UX Research

An open-plan office at an industrial company, somewhere between filing cabinets and two monitors. A handwritten note is taped to the right-hand screen: an abbreviation, a click path, a memory aid for a software step the tool should really explain on its own. No one on the development team knows about this note, because no one ever stood in that office while someone actually used the software. It would probably never have come up in a one-on-one interview either, it has become so deeply embedded in the person's daily routine. This is exactly the gap Contextual Inquiry closes.

Contextual Inquiry is a research method in which researchers observe and interview users in their own environment while they are actually using a product. No lab, no script, just real everyday work with all the detours, workarounds, and improvised fixes that come with it. Who benefits from this method and where it reaches its limits is what this article covers, including insights from our own project work at uintent.

Key Takeaways

• Contextual Inquiry combines observation and interviews directly where a product is used, usually for complex or expert applications

• The method reveals workarounds and habits that users themselves are often no longer aware of

• It works especially well for open questions, complex systems, and poorly understood use cases

• The effort involved is high, though: travel time, coordination, and experienced researchers are required

• Results are often less representative than with more standardized methods and need to be put into context or quantified afterward

• Working in pairs, one person leads the conversation and one observes, noticeably improves quality

• Common mistakes come from sticking too rigidly to a script or neglecting documentation

  
  

What Is Contextual Inquiry?

Contextual Inquiry combines two things that classic interviews often keep separate: watching and asking. A researcher goes to where a product is actually used, for example a workplace, a workshop, or an operating room, and observes the use directly on site. Questions are asked during the observation or right afterward.

The note on the screen from the introduction is a small example of what this kind of observation reveals: knowledge a person has worked out for themselves because the product does not provide it.

The method is especially common for expert applications: software for employees, medical devices for physicians, complex B2B tools. Anywhere a lot of experience-based knowledge is involved that a plain interview would struggle to capture.

What Is Contextual Inquiry Best Suited For?

Contextual Inquiry shows its strengths with open questions, where it is not yet clear what exactly to look for. This applies above all to complex systems with many dependencies, for example when several other systems, vendors, or processes are intertwined.

The method also provides valuable first insights for new types of applications that are not yet well understood. The same goes for situations where a high number of usage errors lead to dissatisfaction without a clear, identifiable cause. For requirements analysis on new systems where the problem itself has not yet been defined, and for competitive comparisons, Contextual Inquiry is likewise a good fit.

What Are the Advantages of Contextual Inquiry?

The biggest advantage lies in the real, actual context of use. Workarounds that users have developed in their daily routine only show up where they actually happen. Not in a lab, which inevitably creates an artificial situation.

These kinds of workarounds don't appear by chance. They reveal exactly where a product leaves a gap: a need that the technology does not meet, or does not meet fully. The person builds their own solution around it, usually with more effort, more time, and an extra step. This solution is often completely unstandardized, which in turn makes onboarding new colleagues harder. Contextual Inquiry surfaces exactly these connections, because they become visible on site instead of having to be reconstructed afterward in conversation.

There is also room for the unexpected. That is exactly what makes Contextual Inquiry strong for open questions: things come up that no one could have thought to ask about in advance. The method often reveals workarounds that users themselves no longer even recognize as such, because they have long since become routine. That routine is part of the problem, and at the same time the reason observation achieves more here than any question could.

Where Are the Limits of Contextual Inquiry?

Contextual Inquiry is time-consuming and costly, usually involving travel and considerable coordination effort before everyone involved is aligned (access permissions within the company, in halls or production facilities, a fixed point of contact on site, and agreed-upon processes to observe).

The results are also rarely representative. Individual opinions get heavily weighted, observations often remain anecdotal, and need to be quantified or put into context later. Add to that observer influence, an effect every type of study shows in some form, but one that is especially noticeable in Contextual Inquiry because observers are physically present.

The method also requires experienced researchers. Anyone on site needs to react flexibly to situations no one could have anticipated. And documentation is harder than at a desk, since observing, listening, and thinking all happen at the same time.

How Does a Contextual Inquiry Work in Practice?

At its core, the process is simple to describe: at least one researcher goes into the environment where the product is actually used, observes the use, and interviews the users during or after. What sounds simple requires a lot of sensitivity in practice. There is no rigid script. No standardized interview guide to fall back on.

From our own project experience, one rule of thumb has proven useful: go into the field in pairs. One person leads the conversation, the other observes and takes notes. This provides a better overview and makes it easier to respond to individual users' personalities. The team can also split up spontaneously when needed, and the situation becomes less overwhelming for a single researcher than it would be alone.

Anyone who frequently works with subject matter experts, physicians, engineers, experienced case workers, also needs the ability to translate expert knowledge well, and a sense for when a question makes sense without disrupting the observed person's workflow. Perhaps most important: you need to be very good at engaging quickly with people you don't know. At thinking your way into a company and its culture, recognizing the real needs at play, and staying open to workflows you have to have explained to you instead of already knowing.

What Mistakes Commonly Happen in Contextual Inquiry?

The most common mistake is sticking too closely to a mental script, even though the method thrives on flexibility. Anyone who goes into the field with a fixed list of questions and holds rigidly to it misses exactly the unexpected moments that Contextual Inquiry was chosen for in the first place.

A second mistake is underestimating observer influence. People behave differently when they know they are being watched, even without doing so consciously. Ignoring this effect makes it easy to overestimate how much individual observations really say.

Another common pitfall: working alone instead of in a team. Without a second person observing and taking notes while the first leads the conversation, either the quality of the conversation or the depth of the documentation suffers, often both at once.

And finally: declaring documentation finished too early. Because notes are harder to take in the field than at a desk, it pays off to write up impressions together with the second researcher right after each session, while they are still fresh.

What Should You Keep in Mind About Confidentiality and Data Protection?

Contextual Inquiry often takes place in sensitive environments, such as offices with confidential documents, factory floors, or clinics. Before each session, it is worth doing a quick check: What can be photographed or written down, and what cannot? Are there screens, documents, or materials that need to be covered or kept out of the notes during the observation? In regulated industries, this is often covered contractually through NDAs. In less formal settings, a short, clear conversation on site usually works just as well.

An Example From Practice

Contextual Inquiry often reveals on site what an interview alone would never have brought to light. In one of our projects, a production plant for large-format components, watching people at their workstations made it clear that employees were maintaining their own, self-built solution alongside the official system. It also became clear that key prioritization decisions were often based entirely on experience that was not documented anywhere, existing only in the heads of individual people. Neither of these comes up in interviews, because for the people involved it has long since become normal. They themselves no longer notice how unusual their own approach actually is.

Environmental factors also only become apparent once you are there: touchscreens that are hard to operate while wearing work gloves, or a noise level that makes documentation on the side impossible. These barely come up in a requirements conversation, yet they directly affect how well a digital solution actually works later on.

The real insight, though, only emerged from how several roles played together. Only by observing how information travels from one person to the next, by shouting across the room, on a note, or in a quick exchange between doors, can you see exactly where it gets lost along the way. Interview each role separately, and their part of the process usually sounds coherent on its own. The actual problem only becomes visible once you see the system running as a whole.

Conclusion

Contextual Inquiry is not a convenient method. It costs time, requires experience, and rarely delivers results that fit neatly into a table. That is exactly why it is hard to replace for certain questions: when the context itself is part of the problem, there is no way around observing it in the field. Anyone facing a complex system with many open questions should at least keep this method on the table, even if it is less convenient than a usability test in a studio.

Anyone who wants to make user research a permanent part of the team's routine, rather than a one-off project, will find practical approaches in our workshop, The Fundamentals of Successful Continuous Discovery, which shows how to build exactly this kind of observation into everyday work on an ongoing basis.

One more thing to close with: now that video calls and screen sharing are part of everyday work, the question of whether and how Contextual Inquiry can be done remotely is becoming more relevant. An interesting discussion, but one that deserves its own article.

FAQ

What is the difference between Contextual Inquiry and a classic interview?

A classic interview usually takes place separately from actual product use, often in a studio or over video. Contextual Inquiry combines the conversation with direct observation at the point of use, which surfaces workarounds and habits that would never come up in a plain conversation.

How many participants does a Contextual Inquiry study need?

The method does not aim for representativeness but for depth. Even a small number of carefully selected observations can provide valuable insight for complex expert applications, which can later be put into context or supplemented with other methods.

Why do researchers often work in pairs for an observational study?

Working in pairs separates the conversation from the documentation. One person leads the interview, the other observes and takes notes. This improves both the quality of the conversation and the depth of the documentation.

What kind of field research in user research is Contextual Inquiry not suited for?

For simple, well-understood use cases, or when reliable, representative numbers are needed, this method is usually not the best choice. Quantitative methods or larger-scale usability tests are a better fit there.