The Carbon Five Guide to User Research: Interview Synthesis

So you’ve conducted a round of user interviews. Great! You’ve got video or audio you can revisit if you or your partner weren’t able to jot down everything in time. Wonderful! You recorded your thoughts during the session and kept track of conclusions and interesting observations immediately after. Amazing!

We’ll be using a fictional story about a hotel that wants to boost its appeal among business travelers. They’ve interviewed a group of experienced travelers and are about to break down the results. This story is loosely based on the DoubleTree cookie.

Synthesis

It’s time for your user interview team to process what they learned. You can invite other stakeholders in too, but they must have watched the interviews and taken notes. This is a great way of getting stakeholders in the company to meet their users. Since the goal is to keep this exercise grounded in the objective experiences of the users, we don’t want stakeholders who haven’t participated in the process to generate feature ideas in a non-user centric way.

Synthesis can feel a little bit magical. You’ll go into it with a bunch of scattered impressions and a lot of raw information, and you’ll come out with smart insights about your users.

Break Down the Interview Into Quotes

Time: 30 minutes per interviewee

Materials: A big wall, stickies, sharpies, the people who were present in the interviews

For every user you interviewed, go around the table and talk through things you noticed. You can do this right after the interview or later, but try to do it when it’s fresh in your mind. Try to capture (writing down one item per sticky):

• Quotes or paraphrases
• Observations about their work/interview environment (if you were able to interview on site)
• Emotional state: Were they tired? Nervous? Where there parts they seemed more confident talking about than others?
• Conclusions: Are there any themes to what they’re saying that are worth capturing as a whole? Use these sparingly and make sure the whole team agrees so you don’t formalize an assumption

When you get to an interesting item, write it down on a sticky and hand it to a moderator. The moderator will put the quotes up on the board. It’s important to moderate this exercise so the group reaches a consensus on what they saw and experienced during the interview.

When the group can’t come to a shared conclusion about a part of the interview, capture the disagreement and come back to it later. Differences in perception can be valuable and worth unpacking later, when it doesn’t slow down the meeting.

Do this for each person you interviewed, creating a separate cluster for each. You can add a picture  if it’s relevant to the research statement, but you don’t have to. Then, take a picture of the board. You’re about to scramble it all up.

Combine the Quotes into Themes

Time: 1 hour

Materials: A new color of stickies and even more wall space

Now we’re going to find places where our interviewees described similar parts of their process and combine them into shared themes. (Ever organized a retro into themes? It’s like that.) As you work on forming these themes, watch for why different users might have different responses—these differences can yield some of the most interesting insights. Capture any conclusions or insights about the themes as a group. You can organize your quotes into themes at the end of every day, or keep a running list of themes and trends you’ve noticed to combine at the end.

Writing Conclusions

Time: 1 hour

Materials: Another new color of stickies

Conclusions and core themes should be supported by evidence from your user interviews. Think of your research statement as your thesis, quotes from your users as evidence, and conclusions as commentary. You’ve known how to do this since high school!

Here are some examples of conclusions you can draw from looking at your interviewee’s responses grouped into shared themes:

• What tasks are your users trying to complete? (The Jobs to Be Done framework is a great resource for this)
  • How often do they do these tasks?
  • How long do they currently take to complete?
• Why are they trying complete those tasks?
• How are they currently accomplishing these tasks?
  • What is painful about the existing solutions?
  • What do they like about the existing solutions? (If it ain’t broke, don’t fix it. Removing positive parts of a workflow can lower adoption.)
• How will your users want to interact with your product?
  • What kind of brand, tone, and voice do your users respond to? (How did they communicate with you? Were they guarded, effervescent, sarcastic? If you were able to get a glimpse into their office, how was it decorated? Your product will take a place in their lives next to the other products they work with; watch their language and environment to keep your product in their context.)
  • How are your users feeling when they accomplish a task? (What makes them nervous? What makes them proud? Where are they most likely to get frustrated? Watch their nonverbal communication and facial expressions; a muttered ‘huh?’ can speak volumes.)
• What demographics do your users belong to? (Be careful with demographics as a means of developing personas, as age, gender, or job title may not be the right way to divide up users. Focusing on tasks users need to accomplish, the context they are in when they perform them (i.e. the time of day, the physical environment, and information & devices they have access to) are more effective ways to identify user archetypes.)

User Need Statements

Time: 3 min per need statement

Materials: Whiteboard

Take all these conclusions and write them as needs statements. A needs statement is written from the point of view of the user, and gets at an underlying motivation or desire. If you’ve got a lot of needs, prioritize them by urgency so the exercise doesn’t run overly long.

Personas, Part Two

Now is a great time to revisit your proto personas. You’ll be surprised at how detailed you can make an aggregate portrait of your user now! Make sure you capture the ways these have changed, because you’ll be referring to them a lot in the prototyping and story writing process.

Brainstorm Features

Keep in mind that the things you’re going to write down now may or may not make it into the final product. We want to cast a wide net for solutions to the needs in front of us and make sure that those needs work together and satisfy the business needs we came to achieve.

At Carbon Five we use an exercise from Design Thinking called a “How Might We…” brainstorm. Give all the research participants three minutes (timed) with each need statement to write down as many potential solutions as possible. Encourage everyone to ignore practicality. The suggestions you write down might not be technology based: sometimes the biggest adjustments to a workflow are interpersonal or structural and would not be well solved with an app. Go wide and consider every solution.

We’re keeping the time to generate ideas short on purpose, since we’ll have a lot of needs to get through and we don’t want to over define features. Time pressure also helps creativity.

The goal is to get assumptions the team has already made and force them to consider new solutions. This has the added benefit of opening stakeholders to the more creative solutions from the rest of their team.

Now we’ve broken our interviews down into clearly defined needs (backed up with quotes from actual users!) and generated a wide range of potential solutions to each, it’s time to define our feature set, which we’ll be doing next week.

One last thing—if you need help or want to try this firsthand with Carbon Five, look into our User Research Sprint.