There are many ways to learn what users think and believe. There are user interviews, surveys, usability testings, etc. It’s pretty hard to question the business value of proper user intelligence the latter research methods provide. However, what these things have in common is they usually lack context. This is exactly what brings us to this article’s topic, i.e. contextual inquiries.
Let’s dive right in.
What’s contextual inquiry
As the name suggests, a contextual inquiry is a research methodology that involves interacting with the users within their usual context. This approach contrasts with the usual “in-lab” or remote user research activities that take place outside of the users’ “natural habitat”. For the sake of this article, we’ll define contextual inquiry as a user research endeavor that takes place within the context of product usage.
Why use contextual inquiry?
Context always matters. However, the degree of its vitality varies depending on the product. An example of a digital product the context of the usage of which is essential would be an app for Emergency Room healthcare personnel.
You can’t have nurses or doctors test said app in an office because if you do the validity of the user research is questionable at best. We’ve intentionally used healthcare professionals as an example since their working conditions are often stressful and demanding.
There’s an additional major benefit of observing users in their context. When you ask users a question, especially outside of their usual environment, they tend to solely rely on their memory.
Human memory isn’t perfect, of course. Therefore, the data you gather might be incomplete or users might unintentionally omit some details they might think are obvious or irrelevant. User bias is a whole subject within itself.
When should you do contextual inquiry?
It shouldn’t come as a surprise that contextual inquiries work best for apps that heavily rely on the context. Remember the nurse example in the previous section? Think of your potential users and their operating environment. The more “out of the ordinary” their work setting is, the more you should think about conducting contextual inquiries.
In terms of the design process, there are a few stages where such an inquiry might come in handy. The best time to hold contextual inquiry sessions is at the very beginning of product development. That way you won’t have to redo anything that has to do with the usage context.
In the midst of the hands-on product design, the other instance when you might want to borrow the contextual inquiry processes is usability testing. Again, this mostly applies to context-heavy apps. Generally, usability testing sessions are conducted to validate early clickable prototypes and high-fidelity prototypes. Hence, contextual inquiries can also take place at that time.
Why doesn’t everyone do contextual inquiries then?
TLDR; It’s time-consuming and expensive. Just think of the difference between the logistic of a remote 30 min. usability testing session and an on-site contextual observation session.
Time and costs aside, taking into account the quarantine restrictions, it’s harder to provide safe conditions for close user observation. Finally, sometimes digital products just aren’t that dependent on the context of their usage.
When not to use it
The contextual inquiry research method could be less potent in two cases. The first one concerns observing behaviors that have very little room for variation. This is true for very simplistic flows. An example would be spending time on testing “sign up” and “sign-in” flows.
The second case, when a contextual inquiry might be overkill is for the product or flows that aren’t very dependent on the context. Think of a work productivity app. It’s likely going to be used in the office, or from a work-from-home environment. Observing users in their homes, as they use that productivity app could be overkill.
The principles of contextual inquiry
As a research method, a contextual inquiry (CI) has a few principles that serve as a basis for this approach. That's not to say that these principles are unique to CI but they certainly are greatly emphasized. Let's go through each of these principles.
Context (duh). You should observe users in their "natural habitats" within their usual context.
Partnership. Both observer and the observee are free to direct the interview/research session, as they see fit. This principle is meant to show that interviews should not be one-sided or fully scripted.
Interpretation. Once you gather data from the studies, the interpretation should rely mostly on user-generated data to eliminate bias and ungrounded assumptions.
Focus. Don’t do research for research’s sake. Shortlist hypotheses and document your goals, or else you'll end up with just a bunch of inconclusive pieces of information. Focusing on your assumptions and specific questions will make it a lot easier to conduct interviews.
Pros and Cons of contextual inquiry
Now that we’ve gone through multiple aspects of contextual inquiries, let’s summarize the pros and cons of this research method.
Pros
The data you gather will be more complete and comprehensive, than research outside of the normal context;
You can gather details that the participants wouldn’t have otherwise thought of sharing. The same applies to you. You might not have thought of asking as well.
Cons
Despite the importance of context, the behavior of a person being observed vs their actual behavior will not be identical;
Much harder to organize and conduct remotely than a regular usability testing or an interview;
Works best for context-heavy apps, and is likely to be an overkill for apps that aren’t heavily reliant on context;
You’re prone to bias, so is the user.
Conclusion
This article kind of had an unintentional running theme, which is that contextual inquiries are a pain to set up. And that’s definitely true, especially when contrasted by remote user research methods. However, that should not sway you against considering said it.
Context-heavy apps should definitely involve contextual studies so that you can build something that is used, useful and useable.
