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.
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.
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):
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.
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.
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:
Time: 3 min per need statement
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.
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.
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.