A recent project had me dust off some personal notes on the topic of Contextual Inquiry. I’d like to share here and archive for future reference and public consumption.
Contextual inquiry is a specific type of interview for gathering field data from users. It is usually done by one interviewer speaking to one participant at a time. The aim is to gather as much raw data as possible from the interviews for later analysis.
Benefits of this type of interview are:
- Interviewees are interviewed in their context, when doing their tasks, with as little interference from the interviewer as possible.
- Data should be gathered during interviews with little or no analysis, interview should result in raw data.
I noted a quote that I found and it resonates well with me that “Contextual Inquiry is apprenticeship compressed in time.” It tailors apprenticeship to the needs of design teams: “Not do the work, just learn about it. Not study a single job, but several.”
Running a successful contextual interview is less about following specific rules than it is about being a certain kind of a person, an apprentice, for the duration of the interview.
As a quick aside, what I enjoy most about the process is how it’s different from the strict, but unstructured method for generative/exploratory interviews. While both are considered to be non-leading, Contextual Inquiry allows me to look through the eyes of a designer while the latter follows a much more rigid perspective of “researcher.”
I find that during interviewing in a more generative/exploratory manner- a leading question can potentially undermine the interview. However, during Contextual Inquiry it’s such the pleasure to partner with participants to learn a system and solve for it together.
I buy in to the concept of letting the four principles (Context, Partnership, Focus, Interpretation) guide you to adapt this master / apprentice model. Quick notes:
1.) Context -> Go where the work is to get the best data
* Gather ongoing experience rather than summary data. Gather concrete data rather than abstract data.
* Start with real experiences, not abstractions
* You will abstract when you consolidate
* Indicators of abstraction in interviews: Lean back and look at ceiling vs. lean forward and handle work
* Heads up on words “generally”, “we usually” or “in our company”
* Focus on present tense vs. the past tense
* Avoid abstractions by returning to real artifacts and events
* “We usually get reports by email.” -> “Do you have one? May I see it?” ->“I usually start my day by reading email.” -> “What are you doing this morning? Can you start?”
* Sometimes you need to understand things that happened in the past -> Span time by retrospective accounts.
* Span time by replaying past events in detail
* Avoid tendency to skip details and give summary
* Look for holes. Ask questions to fill in those holes
* Use artifacts to provide context
* If story has not yet ended, go back to a story in the past that did end
2.) Partnership
* Traditionally, interviewer has too much power
* Contextual Interviews: You don’t know what will turn out to matter!
* Apprenticeship model tilts power back to the user. Interviewer should create a partnership, though not just an apprenticeship
* Alternate between watching and probing, withdrawal and return
* Teach the user how to see work by probing work structure. Users often to start interrupting themselves to reveal aspects of work or discuss design ideas. A partnership develops
* DON’T squash design ideas if they arise (unlike the generative interview)
* Get instant feedback
* If it works, you understand the work practice and have a solution
* If it fails, you can improve your understanding of the work
* Find the work issues behind design ideas
* Let the user shape your understanding of the work
* Leads to truly human-centered design
* Partnership creates a sense of shared quest
3.) Focus (probably most important)
* Focus defines the point of view. Clear focus steers the conversation
* Everyone in the team should have an entering focus
* Focus lets the interviewer see more
* Focus reveals detail
* Focus conceals the unexpected
* Focus on one, and loose the other
* Trick – start with a focus and then expand
* Internal feelings guide how to interview (I must say this once a day)
* Opportunities to expand focus:
** Surprises, contradictions, idiosyncrasies, nods
** What you don’t know
** Treat the interview as an opportunity to learn new stuff
** Something technical
** Even if user is not knowledgeable, the extent of knowledge / misinformation will be useful
* “Convert a statement of solution to statement of user work”
* Start with explicit assumptions
* Commit to challenging your assumptions, not validating them!
4.) Interpretation
Interpretation during inquiry session AND go back to the project team with your results from the interviews and try to reach a common interpretation, as well.
* Look for related issues
* Look for duplicate issues
* Clarify questions in further interviews
* Keep interviewing until nothing new comes up
* Interpretation is assignment of meaning to observation
* Good facts are only starting points
* Design is built upon interpretation of facts
* Design ideas are end products of a chain of reasoning
* So interpretation had better be right
* Fact -> The observable event -> Hypothesis
* An initial interpretation of meaning or intent
* Implication for design
* Design idea is realization of implication
* Share interpretations with users to validate
* This will not bias the data!
* Teaches the users to see structure in the work, again!
* Instead of asking open ended questions…
** “Do you have a strategy to start the day?”
** “Not particularly.”
** … give users a starting point (another contrast to generative interviews)
** “Do you check urgent messages first, no matter where they are from?
** “Actually, things from my boss are important, because they are for me to do. Messages or faxes may be for anybody.”
* Assume that people have not had others pay attention to what they are doing
—
Now, here are the steps I noted and practice (from various sources and much more important- experience of what works):
1.) Introduce the project and focus
* Promise confidentiality
* Get permission to tape
* Explain that the work is primary and you are here to learn
* Break ice – 3-4 factual questions: Name, age, education, family, demographics
* Ask 1-2 open ended questions
* Opinions of tools, overview of the job
* You will do your work while I watch…
* I will interrupt whenever I see something interesting. Of course if a bad time you will tell me to hold.
* We are partners here and to go further think of me as an apprentice so eager to learn.
2.) The Transition
* Explain the rules of a contextual interview
* User will do the work
* You watch and ask questions
3.) The Contextual Interview
* Observe and probe ongoing work
* Suggest and validate interpretations
* Analyze artifacts
* Elicit retrospective accounts
* Keep the user concrete
* Take copious notes
* Be nosy, allow interruptions
* Remember: context, partnership, interpretation and focus
4.) The Wrap Up
* Summarize what you learnt from your notes
* Feedback and comprehensive interpretation
Once you’re done with the session, assess whether you met your goals for the visit. Analyze your notes to determine questions for your next visit. In a contextual interview, we watch and listen as the user does his or her own work. We don’t usually impose tasks or scenarios on the user. The observer listens to the user but may also ask clarifying questions and probe to gain greater understanding of what the user is doing and thinking. Naturally, the results are usually qualitative rather than quantitative. Hence, results are then analyzed by Affinity Diagrams and, for me, lead to Mental Model, Persona, and light weight user scenarios that can inform requirements gathering and further design thinking.
Here are some main points to keep in mind as output for an inquiry effort:
What Are Their Tasks?
It’s important to know what users do, or will do, with app. We often have an ideal model of the kinds of tasks we’re trying to support. This is risky because we may be unaware of important aspects of the task. This is particularly true in a corporate environment (for example, when Gathering requirements for an enterprise application). In such cases, there will be a significant gap between the official description of a task and the way it’s actually conducted by users.The best way to get a grip on these kinds of user objectives (and hurdles) is to spend time watching users carry them out — a task that lies at the heart of contextual inquiry. For an intranet project, this will mean spending time with users in relevant departments.
So What Are Their Goals, Values, Concerns and Issues?
If you know what users value, you’ll be able to cater to those values in requirements / designs. If you know users’ concerns, you can address them. Some of the values and concerns are generic (e.g. privacy, security, speed), but others will be specific to project. Issues provide opportunities if you can address them, but they become pitfalls if you’re unaware of them, and fail to allow for their effects on users. Once you’ve identified what it is you need to know about your users, it’s time to work out how to get that information. Understanding that you need to get to know your users is one thing. Naturally, actually doing something about it requires the strategic thinking. Taking a strategic approach to usability research (of any sort — not just contextual inquiry) helps minimize effort and maximize effectiveness.
Conducting the Task Analysis (I like to do this in form of User Scenarios)
One of the first things to do is to identify the tasks that were carried out. Usually, there will be a relatively small set of tasks, but there may be multiple variations. Here’s an example I noted and like: “imagine we’re building a Web application to allow people to book DVDs online. If you spent some time in a video store, you might discover a small set of tasks, such as ‘find a movie’, ‘hire a movie’,'return a movie’ and so on. However, ‘find a movie’ might have several variants: some people would just browse new releases; others might look for a movie by name, or by the name of a director or actor, and so on.”
It can be a good idea to draw flowcharts to represent the tasks. The flowcharts should identify triggers (what starts the task?), systems usage, interactions with people or departments, what marks the conclusion of the task, and discontinuities. Although there may be many variations to the flowchart, it can be very useful to have a consolidated view. A clear, systematic task analysis will help develop effective IA and aid user interface design and/or requirements.
So how do we analyze the data? Affinity 
- Immediately after each site visit enter data into a word processing program. Notes should be at the lowest possible level of granularity.
- Number each note, and print them out on labels or cards. Use a system that allows you to trace every individual note to its source
- Use the notes in sequence to construct sequence models of the tasks carried out. Use affinity diagramming to group all related issues.
Build models (yup, Personas) with contextual inquiry data
Contextual data is a natural raw material for personas that reliably reflect the archetype characters that make up the profiles being supported. By collecting enough data to really characterize users, your persona characterization will be a more complete representation of the people and issues we design for. Once we define the persona, we characterize their activities with contextual data. We use the consolidated data to drive these descriptions. For example:
* Roles and responsibilities
* Tasks from User Scenarios
* Values / Goals
* Issues / Pain Points / Frustration
Because the consolidated data comes from actual people we can write up little stories or attach videotape clips of the actual users behind the persona to make it real. The persona becomes another way to access and structure the data. Personas are just one technique – many other ways to model data
More on the Interpretation Session
We captured affinity notes and models, as well as other artifacts. We built the affinity, and then walked it through scenarios for design ideas or… requirements – Contextual Inquiry is a wonderful technique for generating those user requirements!
User Needs Analysis
Make a list of the things that users explicitly need, or that you noticed would have helped them. Consider whether these needs can be met by your application or Website. Consider also whether there are proposed elements of a new design that will not be valued by users; perhaps effort can be shifted from them and into the areas that are perceived to be more important.
This all stem from interviews and interpretation sessions, modeling, and visioning. Your visioning will be scoped by business analysis and/or by marketing input. Yes, visioning is part of the user needs analysis.
How else can you decide what to do?
Because contextual inquiry is design process scaffolding, it is robust enough to include new techniques and replace existing techniques without losing its coherence. So teams who want to use personas can still be guided through a human-centered design process that works for the team, the organization, and the users.
I can’t emphasize enough that focus setting plans contextual interviews for maximum impact. Good focus setting dramatically increases the chances of project success. It lays the foundation for an efficient, high-quality effort. It articulates the project scope, the work that the team will be doing and the level of resource commitment involved, the limitations of what is being attempted, and the time line. It makes explicit the intent of the project, the primary user roles and activities, and the major work practice variations of interest. It produces an outline for the number and type of interviews. Once focus setting is complete, the project can move forward with confidence.
Remote Contextual Inquiry
I’d like to conclude with the the following link on the topic of Remote Contextual Inquiry from Boxes and Arrows. The article was written years ago but still stands strong. Because in-person inquiry is often impossible and many web applications serve a global audience- Remote Contextual Inquiry is a powerful tool in a practitioners tool box!
