Method category: Generative market research
How to Use This in GLIDR
Contextual Inquiry is an important method for figuring out the problems that your users have in the real world via direct observation.
In GLIDR, you can consider each user's experience one Evidence - Interview and look at overall trends and patterns across the pieces of evidence at the end of your Research. You can write detailed notes in the Notes section and then summarize the overall patterns in the Key Insights section.
Learn more about each of those aspects of GLIDR:
Article excerpted from The Real Startup Book
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
Time Commitment and Resources
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 spent 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 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
Case Studies (external links)
Got a case study? Add a link by emailing: email@example.com
References (external links)
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: firstname.lastname@example.org
Bring this data into your roadmap, using Evidence to connect your data and Ideas.