Contextual Inquiry Part 1: The Power of Being in the Room Where it Happens

Imagine your design team has a great new idea for a product that you think has the potential to be a real game-changer in the marketplace. For the sake of discussion, let’s say it’s a new app that will let small business owners manage their supply chain, so they know when their products will arrive when they need to restock, and so on. Now, if your design team already works in the supply chain space, they might already know a lot about the user requirements. But what if all of your previous products are corporate enterprise-level software, and you don’t really have a good idea of how that scales down - which features your typical small business owners need, and which ones they will never touch?

When you want to understand how someone uses your product in their day-to-day work, or does whatever it is they do that your app is going to streamline, it’s not enough to interview a bunch of users and assume that will let you sift out the key business requirements. Interviews can be useful for getting the broad strokes, but to really understand how they actually might use your tool at work, with all the demands on their time and attention, you need to see what they do and where they do it. In other words, in-context and on-site. In order to get the full picture, you need to be in the room where it happens.

Contextual Inquiry is a method adapted from ethnographic research which combines interviews, observational research, and task learning sited within the operational (work) environment. Exploring user behavior in the context of their actual work instead of a simulated setting often reveals underlying elements of the work process or environmental constraints that might not surface in a more controlled lab-like setting. It also often prompts users to reflect on their own behaviors and motivations in the moment, often revealing more than mere declarative interviews or simulated task operations would.

A few quick examples of the rich details that can be uncovered:

A team designing a bedside medical monitoring device debated what the appropriate alarm sound is. They discovered when they visited a hospital ward that their newly prototyped device’s audible alarm sounded too similar to several others and was difficult to locate.
Researchers shadowing radiologists learned that they typically assigned themselves cases from a common pool, or shared them with colleagues for a consult. They needed to see the overall caseload to plan out their day.
Researchers rode along with law enforcement officers and watched them interact with technology on the road. The officers were constantly listening to the radio, typing and searching license plates on their mounted computers, and receiving text updates on the phone. Juggling multiple devices constantly, they often built their own device mounts, and routinely improvised solutions to the technical challenges they faced working on the go.

Contextual inquiry is typically used:

Early in the research/design process
When you want to know how users act AND think they act
When you want more descriptive data
When you want to find out more about the environment in which your users work

The core elements of contextual inquiry are:

In-Context - the researchers must spend time where the work happens to understand the ongoing work experience.
Inquiry - contextual inquiry is an exploratory method that generates rich descriptions providing enough information to create design hypotheses (rather than validate them) and better understand how your users actually act and think when they’re at work.
Partnership - the user is the subject matter expert and generally has more control over the study process, as they perform their normal work as they’re being observed, and shapes the degree to which the researcher interacts and questions them. There’s a range of interaction in contextual inquiry ranging from simply shadowing the user (and saving questions for later) when it’s not safe or practical to interrupt the user, to a fully participatory model where the researcher is treated as an apprentice by the user, learning to perform some of the tasks themselves.

The format is usually as follows:

individual semi-structured interviews with the participants to establish a rapport and the basic framework for understanding whatever tasks or processes are being studied
A period or ideally several periods of observation in context where the participant works at the tasks being studied and the researcher observes with the level of interaction previously agreed to (discussed above.)
Where possible, the research debriefs with the participant afterward to share and validate their observations with the participants, and gain additional feedback about what they’ve observed.

Contextual inquiry with enough participants for a representative sample of users can be time-consuming and typically requires more time for analysis than more structured methods such as interviews or a usability test, but done right, it can provide a level of rich contextual detail about your users and their work that is impossible to obtain any other way.

In our follow-up article, we will examine three common objections to using contextual inquiry for an exploratory study, and provide potential solutions for each one.