A Practical Synthesis Strategy for Busy UXRs

Synthesis is a tricky topic for researchers. If we take the most common definitions and mash them together, we have something along these lines:

“Making sense of user research by bringing it together, finding common patterns/trends and creating a coherent summary that enables team members to take action.”

I’m not against this definition; I think it is fairly accurate. We bring the research into one place, find concepts that repeat themselves and try our best to help teams make better decisions.

But accurate doesn’t always mean useful.

We talk about synthesis as if it appears in a magical, productive, uninterrupted vacuum. You go into a workshop with hours of raw data and, poof! You come out with action items the team is empowered and interested in working on.

The problem we never know what prompts the “poof.” When you seek out advice—online or in person—you’re met with fairly generalized next steps.. Create an affinity diagram. Build a customer journey map, or an empathy map. These are great ways to visualize your research findings, but how do we get to these deliverables?

FYI: We set out to systemize an entire analysis process for tight timelines. Read: Foolproof Qualitative Analysis Tactics—For Whether You Have a Month or an Afternoon.

Your standard advice for synthesis (and when to ignore it)

Tip 1: Get into a group with other researchers to see if they have the same finding

Problem: Research team of one? Small team with a lot to juggle? Roping someone else in might not be an option.

Tip 2: Invite your team to a synthesis session where you deep-dive into the research and come out with post-it notes and action items

Problem: Teams are busy. Scheduling is hard. Team members are remote.

Tip 3: Take your time to synthesize. Dedicate at least 2-3 hours of synthesis to each 1-hour interview

Problem: If you’re working on an agile system and are responsible for planning studies, recruiting participants, interviewing, synthesizing, and providing a report—carving out 30 hours for 10 hours of interviews, probably is out of reach.

Tip 4: Gather feedback from multiple channels to validate/disprove hypothesis/assumptions from interviewing or quantitative data

Problem: Synthesis that requires more synthesis? See problems 2 and 3.

Tip 5: Use a research repository or build your own

Problem: Repositories take time and budget—and organization doesn’t guarantee an “a-ha!” moment.

TLDR: Synthesis is where the spoken about (or bragged about) idealized world of user research and reality come crashing against each other.

The ugly synthesis reality we should be honest about

Most of us are trying to synthesize alone, with limited time and resources.

I’m the sole user researcher at a small start-up. I have a few people to bounce ideas off of occasionally, but it isn’t consistent. I can’t always bet on other people joining my research sessions to help with note-taking. The product team is understaffed, so they definitely don’t have time to review the research and take part in a full-day synthesis workshop.

And I know that my situation is not unique.

Here’s a situation that might sound familiar to you:

I find out (too late, despite my bi-weekly meetings with product owners and designers) about a new feature we are releasing in the next sprint. Uh oh, is what I think as I review the feature on staging. I request that we put this in front of five users in the upcoming few days. Luckily, I had some research interviews planned for a different project and can shuffle and reprioritize.

We put the feature in front of users and they are generally confused. I’m pleased because the participants are giving really awesome and useful feedback. But I’m also disheartened. I don’t have the proper amount of time to interview the participants, synthesize the sessions, include others in the synthesis and create a helpful report before this feature goes live.

Teams need to make last-minute decisions and synthesis might have to happen in a biased vacuum by one person. This is real-life research, so how do we conduct real-life synthesis?

If you need some help setting stakeholder expectations, we built this downloadable one-page Guide to Working with a UXR you might like to pass along. 

A practical synthesis short-cut

As I’ve struggled with this time-strapped-synthesis frustration, I’ve repeatedly asked the same questions:

• What would real-life synthesis look like?
• How do we shape synthesis for the future?
• How do we get the team members involved in a relevant and engaging way?

I want to share how I currently synthesize research as a team-of-one at a startup where people usually don’t have time to review the research with me.

Last year, I was simultaneously juggling a Jobs To Be Done Initiative and two usability tests.

My deadline for the evaluative project was two weeks, as the developers needed to start working within three weeks, and the designer needed to be able to iterate on the prototype we were testing.

I quickly recruited participants. I conducted seven usability tests on this particular prototype and then got to work with the synthesis.

Steps to synthesize:

• Step 0: Make sure you are able to record each research session (audio or video is fine), as this will make your life 1000 times easier. If you are unable to record, beg someone to come in and take notes for you. If no one can, apologize profusely to the participant and say that you will have to take notes if you can’t audio record the session.
• Step 1: I review each one hour interview within 24 hours of the session. During this time, I essentially write a transcript of the interview in excel.
• Step 2: I review the transcript and highlight any important notes or quotes. I then will timestamp these, so I can easily make video/audio clips later on for presentations or reports.
• Step 3: I start going through each line noting them as an emotion (and which emotion), reaction, fact or need.

• Step 4: I do this across all the different transcripts.
• Step 5: I bring the transcripts together and start to highlight the commonalities between them (ex: through affinity diagramming or through a rainbow chart, see below). 

• Step 6: I try to contextualize my findings with the greater problem we are trying to solve. For instance, if several people have mentioned they want an explore feature to find inspirational travel within their budget, I try and pull out the deeper context of this as the insight. I don’t want to offer solutions, just problems, and context.
• Step 7: I write down the biggest problems the users are facing with some video/audio clips if I have time.
• Step 8: I present or send this information to the relevant team members (ex: product owners, designers, developers).
• Step 9: I follow-up with them within a few days (okay, sometimes a week) to make sure everything is understandable and see what the next steps are.

I do the majority of this practice alone. It is far from my ideal, and I know people with more resources that may frown upon this hacky way of tackling this project.

But I also know people with fewer resources who would envy my flexibility.

Either way, we are left with a large spectrum in our abilities to synthesize and, as a community, we should come together and tackle the real problems many of us face day-to-day. In a way, this is my call-to-action to all user researchers around the world: how do we shape the future of synthesis in a way that reflects our daily struggles and needs?