In the early 2000s, I was helping improve the usability of an application for commodity traders.
It was an app built for tablet computers. This was a decade before the iPad.
We had a good idea about the functions and tasks the app was intended to support.
But we didn’t really know how traders actually used the app or what they wanted to accomplish with it. So we spent the day on the floor of the very loud CBOE and watched four different traders use the app as they went about their jobs.
We watched as traders carried their tablets and used the software, usually successfully, but not always. And in between the shouting and the trading, we talked one-on-one about what the traders were doing and why.
What Is a Contextual Inquiry?
We were conducting a contextual inquiry. The contextual part emphasizes the importance of watching participants in the context of how how they use a product and how the physical environment influences their attitudes and actions.
The inquiry part refers to the semi-structured interviews you have with your participants to better understand their background and motivations. It’s semi-structured in that you want to have some script to follow and ask a core set of questions, but you should be ready to deviate from the questions where you can uncover potentially useful threads.
Where Did Contextual Inquiries Come From?
Like many UX methods, contextual inquires come from other fields of research, primarily the social sciences like anthropology and educational research. It’s based on the idea of observation as an important qualitative method.
One of the earliest uses of contextual inquiries in the field of what we now call UX research was from an influential paper by Whiteside, Bennett, and Holtzblatt in 1988, who described this style of inquiry as a “phenomenological research method.” The paper became the foundation for the book, Contextual Design, which is considered “the bible” of using contextual Inquiry in UX research.
When Would You Use a Contextual Inquiry?
Contextual inquiries are one of a number of methods used to help identify unmet user needs. They provide insight into:
- What problems people are trying to solve.
- What points of friction they’re encountering.
- How they go about solving them.
It’s particularly helpful for generating ideas for new features and or new products. Here are some examples of when contextual inquires can help:
- Small business merchants checking out customers
- Realtors needing listing information while at a house with clients
- Drafters using CAD software on a job-site
- Farmers harvesting crops with combines
A number of companies have embraced contextual inquires as a means for developing better products. For example, at Intuit we called the technique “Follow-Me-Home.” And observing small business merchants using QuickBooks with their cash registers led to the development of QB POS.
Some Tips on Conducting a Successful Contextual Inquiry
Here are some things to keep in mind to make your next contextual inquiry a success:
- Have a set of research questions and goals. You don’t want to just show up and watch. You’ll make the most of the time by having a standard set of questions that you can use to get to know this participant’s background and their typical challenges and goals.
- Have something for the participant(s) to do. In theory you’re watching people do their jobs and use the products as they normally would. But you may need to observe particular events or actions that don’t happen frequently (e.g. running payroll). In addition to this impacting your schedule, be sure the participant knows you want to see them do particular tasks.
- Decide on the role of the observers. If people are there to observe, be sure they’re not interrupting or helping participants with problems. We’ve had some experiences when eager product managers just couldn’t help telling participants about all sorts of cool features that would help them.
- Be sure this isn’t some product demo or wish list. It’s OK if a participant suggests features or improvements, but you don’t want to spend the hour talking about feature requests or make it a sales pitch for an upgrade to the next version.
- Be sure you understand as much of the domain and product as possible. While you can’t turn into a CPA or electrician overnight, you can and should have some idea about core terms and tasks of whatever you’re observing. For example, when we wanted to study architects, we first talked to two architects in our office and had them explain how they use CAD software and what certain terms meant and what we should look out for.
- Let the participant do the talking and act as the expert guide. You generally want to treat this as a show and tell—where the participant is doing most of the showing and telling. You can rarely observe everything naturally; instead, when a participant references something, have them “show” it to you instead of just telling you about it.
- Decide how many participants to observe. The number of contextual inquiries needed is a function of how common the behaviors you want to observe are. As with usability testing in the lab, redundant themes will become apparent after just a handful of participants. In general, the more common a behavior or attitude, the fewer participants you need.
- Decide what to do with your notes. Take good notes and record the session if you’re able (get permission first). You’ll want to turn your raw notes into meaningful insights, themes, and visualizations like process maps, customer journeys, and affinity diagrams.
The next time you see users encountering problems solving tasks, look at it as an opportunity. A contextual inquiry might be the first step into developing an innovative product that makes all our lives easier—like a cooler with a blender and sound system all in one.