Contextual inquiry is a combination of semi-structured interviews and observations done in the actual location where the problem occurs or the solution will be used. This method avoids hypothetical statements and helps reveal knowledge that the customer may have but is unaware of and thus unable to communicate in a traditional interview. It may also reveal substitute products, competitors, or workarounds that will help define the optimal solution.
What are the customer’s pain points?
What are the jobs to be done?
How often does this problem occur?
Are there makeshift solutions the customer is currently using?
Does the customer have any tacit knowledge about the problem space that would help create a solution?
Jobs to be done
Contextual inquiry can be very expensive depending on the proximity to the customer and the frequency of their problem. In some cases, the problem is unpredictable and a lot of time can be wasted either waiting for the problem to occur or simulating an occurrence.
Expect to spend at least one hour per customer with a minimum of five customers, and two hours to debrief.
It is helpful to have already conducted customer discovery interviews and have both customer personas and a preliminary storyboard of the user experience.
Arrange the time and place for the interview, making sure it is the time and place where the customer would typically have the problem.
Prepare a framing statement.
Conduct the Interview
Frame the interview.
The researcher must establish rapport and put the customer at ease.
The customer must not feel judged.
The researcher is there to learn.
Establish the rules for observation.
The customer will be doing work, so the researcher must establish up-front when they can or cannot interrupt the workflow to ask questions.
The researcher should take notes on the workflow, asking questions to clarify any points of confusion.
Take care to note extraneous activities that may be outside the scope of the solution to be designed but may impact the user's workflow, e.g., coworkers engaging in distracting chitchat.
Summarize the observations and ask the customer for confirmation.
Ask any additional clarifying questions.
A number of debriefing methods, such as affinity diagramming, card sorting, or creating jobs to be done can be used after reviewing recordings or notes.
Since the data is primarily qualitative and sample sizes are small, researchers must be careful not to extrapolate a pattern of behavior to the entire population, but they can usually synthesize a clear hypothesis for further evaluative testing methods.
“Apprentice yourself to the customer and learn how they are currently solving their problems without your product.” —@TriKro
Got a tip? Add a tweetable quote by emailing us: firstname.lastname@example.org
Got a case study? Add a link by emailing us: email@example.com
Got a tool to recommend? Add a link by emailing us: firstname.lastname@example.org
Whiteside, J. Bennett, J., & Holtzblatt, H. (1988). Usability engineering: Our experience and evaluation. In M. Helander (Ed.). Handbook of Human-Computer Interaction. New York, NY: Elsevier Science Publishing. 791-817.
Got a reference? Add a link by emailing us: email@example.com