Contextual inquiry is a User Centered Design (UCD) technique where you interview the user in context of their work while they perform real tasks.
A saying we often hear in design studios and product labs these days is to “fall in love with the problem.” In my opinion, the best way to start that relationship is to make a date with it by doing contextual research.
This ethnographic research method, which ideally should be completed before any solutions or designs are in place, is when you go “into the field” and sit with a user and interview that user while they complete specific tasks. Contextual inquiry is a powerful methodology, because when you immerse yourself in the world of the user you will uncover not only what the problem is, but you will also uncover why the current solution is a problem for a user.
The following is a list of “tips and tricks” I use when applying this research method in the enterprise setting.
Before you go onsite:
- Scope and prioritize your problem. Contextual research will uncover a treasure trove of data. In order to ensure that the data you collect is relevant and manageable, make sure you have scoped your research and prioritized what tasks you want to observe when you are onsite.
- Conduct a short telephone interview prior to arriving onsite. This is a technique I have come to rely on. A conversation with the participant prior to going on site is critical to defining how your day of onsite research will unfold. Your enterprise user is probably a knowledge worker and the tasks that you might be investigating might only a subset of their daily work duties, so this interview is a good time to understand how frequently they complete the tasks you want to observe. If the user doesn’t complete the tasks you want to observe on a daily basis, ask them to save those tasks for the day you visit them so you can observe them completing them in person.
The telephone interview is the best time to confirm if you can take photos and record the session. I also find it valuable to confirm whether or not I will have access to proprietary or confidential information.
When you are onsite:
- Go in teams of two to observe your user. User research should be a team sport – ensure that representatives from Product, Development and any other key Stakeholders attend contextual interviews. This opportunity to see a user in the “real world” will create empathy for the user and also help you build alignment as you design a solution for problem.
Create a note taker template for team member to create a “baseball card” for each user that they meet with.
- Have a high-level script (or even better, a list of themes) to reference on a clipboard when you meet with the user. A contextual interview is an in-person conversation that will require acute observation and eye contact when you are engaged in conversation. Be aware that you will not be able to follow script in the same way you would with a usability study. A technique that I use is to have a list of themes that I want to cover on a clipboard, instead of a list of interview questions. Notes can be jotted down next to conversation themes, and when a theme is complete it can be easily checked off.
The clipboard also to not rely on your user’s space and enables you to be mobile and change your vantage at any point during the conversation with your user.
- Use the Master/Apprentice Model when Conducting the Inquiry. There are many different interview methods that you can employ when doing a contextual inquiry, as suggested by Beyer and Holtzblatt in their seminal book: Contextual Design. I prefer the Master/Apprentice Model. Using this method, think of the participant as the Master and yourself as the Apprentice – you are there to learn her craft. As an Apprentice you can ask intermittent questions to understand discrete steps and user rationale as the participant narrates their process to you.
- Watch how the person completes tasks. Contextual research will unearth core user behaviors and needs. As you sit with the user, you will be able to see what tools they use and what work-arounds they have.
Keep a keen eye to see
when they are using a calendar, a checklist or a notepad to track their work.Workarounds typically indicate that the systems the users are implementing are not comprehensive in helping them complete their work.
- Understand how the user interacts with others in the enterprise, and how it impacts their employee experience. Who is it in the enterprise that directs their work? Who approves their tasks? What or who can interrupt or derail their work? This information will provide some additional context to how the user’s work intersects with the work of others in the enterprise.
- Collect artifacts. Simply put, you are on a field trip – bring back valuable photographs, photocopies and screenshots. These “postcards” from the trip not only help document your story, but will also be triggers to help you remember the conversations you had when you were onsite.
After the Onsite:
- Create an affinity diagram to analyze the data. Have each person that attended an onsite interview participate in helping to identify key learnings. Each team member can reference their “baseball card(s)” and the artifacts collected, to create post-its that encapsulate the data points they learned. Holtzblatt and Beyer suggest 100 post-its per person. As the post-its accumulate, group them together. Build consensus until, as a team, you feel you have merged together the ideas into a manageable number of insight groups.
- Create a UX deliverable that tells the story. The data gathered from a contextual inquiry is foundational research – it can be referenced throughout the development lifecycle. With the insight groupings you identified through affinity diagraming, you will be able to determine if a video diary, infographic, persona, user journey, empathy map, flow chart or another suitable deliverable will best tell the user story.
Contextual inquiry will be the spark that will ignite your relationship with the problem. As a design is developed, the insights gathered from the discovery phase will accurately inform you if the solution you design solves the user’s problem.
ps: Contextual inquiry can also be done between development cycles to understand how users are using the design/application. Continuing contextual research can inform the team as to which features are accepted by users, what gaps still exist in the product, and help define the next set of requirements for the product release.