Need Research Insights in a Flash? Try the Lightning Synthesis Method

Synthesis is time-consuming—and usually, we needed to do it yesterday. I don't know about you, but this part of the process is always the one everyone wants to speed up.

Unfortunately, proper synthesis is meant to take a long time. It is the most rigorous part of the research process and not one we can simply speed through. When we synthesize research too quickly, we can miss crucial insights, minimizing something important or maximizing something that shouldn't be a priority.

So, how do we balance rigor with the need for speed in the tech world?

Can we skip synthesis?

It's not always possible to go through the ideal synthesis process. For example, while I would love to spend at least two hours synthesizing every one-hour interview, it isn't a realistic expectation. My colleagues would give up on me, and I'd be incredibly behind on my work.

Typically, we don't only juggle one project at a time. Instead, we might have several studies happening at once. When it comes to synthesis, it can be even more imperative to get it done so we can focus on the next project.

However, we can't entirely skip this step. If we do, we might as well not do the research in the first place.

The consequences of skipping synthesis

Skipping synthesis leads to detrimental results, such as:

• Unclear results and trying to interpret them without taking the time to understand trends or patterns
• Confirmation bias based on what we want to hear
• Lack of action if no one knows what to do next
• Risk of building the wrong thing
• Ignoring research and acting on assumptions

I know because I have skipped synthesis several times. I was involved in several projects we needed to complete at an inhuman pace. There was no way I could spend time synthesizing the research. So I decided to experiment with no-synthesis-research.

Instead, the stakeholders came to 80% of the sessions, and instead of synthesizing at the end, we had a one-hour discussion where we spoke about potential solutions.

At first I thought this might be able to work, but I quickly saw the red flags. Rather than referring back to the research sessions, people started to argue about solutions. Curiously, they were arguing about solutions they originally wanted to validate or implement (confirmation bias: check).

Since not everyone had been to every session, there were gaps in knowledge. People had grasped onto things they heard and wanted to hear. They ignored—or didn't see—the other more pressing patterns.

At the end of the discussion, no one knew what to do. The spot where we were meant to list action items was empty, everyone was frustrated, and we walked away disappointed. In the end, we created the feature we had initially planned, and it was just short of a disaster.

I tried a few more times, wondering if that one session was a fluke. But skipping synthesis always led to a less than ideal outcome that left people questioning why we did the research in the first place.

If you cannot do synthesis or your team has already decided to move forward with the design regardless of the research outcome, reconsider whether you need to support that project. If this is the case, I usually run a low-effort study, such as unmoderated usability tests. Alternatively, I might recommend A/B testing or watching specific data or product analytics.

Compromise with lightning synthesis

When we can't synthesize, but we also can't take our time, where is it that we can compromise? Well, it depends. There are a few mechanisms that we can use to speed up synthesis, but it is also up to you to make your boundaries clear with stakeholders.

When I got to the point where colleagues constantly bombarded me with requests to speed synthesis up, I created the concept of lightning synthesis.

Lightning synthesis employs different ways of speeding up the synthesis process without compromising the data. To create this process, I looked at each step of the synthesis process to see where I could speed it up while maintaining quality.

My synthesis process, when I have time, looks like this:

1. Record the session
2. Take small notes during the session
3. Do a 30-minute debrief right after the session
4. Transcribe the session within 24 hours (approximately one to two hours)
5. Tag the transcript (about 30-60 mins)
6. Write a summary or snapshot of the session (generally one hour)
7. Repeat for all remaining sessions
8. Hold a half- or full-day synthesis workshop (4-8 hours)
9. Conduct post-synthesis that didn't get done in the synthesis workshop (one to two days)
10. Create the report (three days)

If we look at that, it is more than twice the amount of time of the interview to synthesize it. So as much as I loved following this process because it was familiar and brought great results, it wasn't possible. If I took this much time on each research project, my colleagues would run away screaming, wishing they had never engaged with a user researcher.

So, that's when I started to lean down the process as much as I could. Lightning synthesis is a great way to do this and helps make the process more efficient in several ways by:

1. Allowing you to present your findings directly from the affinity diagram, avoiding the days it takes to write a more formal report
2. Highlighting and sharing essential needs and pain points, which are the crux of improving or creating a good experience
3. Creating action items and next steps directly from your board and presentation

How to use lightning synthesis

Instead of the steps above, lightning synthesis has significantly fewer. Let's break each of these steps down.

Jump to...

1. Gather the data
2. Create/choose lean global tags
3. Tag each participant through affinity diagrams
4. Look at 3+ patterns
5. Write insights
6. Assign next steps

1. Gather the data

For this first step, gather the data from the participant. There are a few ways you can do this, depending on the resources you have available:

• Get each session automatically and immediately transcribed (most lean)
• Have stakeholders come to at least 80% of the sessions and take notes (medium)
• Transcribe each session yourself (highest effort)

To be as lean as possible, I recommend trying to get the sessions transcribed or teaching colleagues how to take great notes that resemble a transcript.

2. Create/choose lean global tags

There are a few ways to create tags for data. However, when it comes to leaning down the process, I usually go with global tags. These are general tags that aren't project-based but can still identify patterns in data that your team can act on.

The global tags I use include:

1. Goal: What the person is trying to accomplish as an outcome
2. Need: Something a person needs to fulfill a goal (generally something they are uncertain about)
3. Pain point: A barrier or difficulty towards accomplishing a goal
4. Tools: A tool a person uses to try to achieve a goal
5. Quick fix: Something that is painful or annoying for the user that the team can quickly fix

3. Tag each participant through affinity diagrams

After each session, I dedicate 35 minutes to affinity diagramming using the above tags. So, I go straight into a 35-minute download for each participant.

This part is where I bought the most time in the process, because it’s also where the rest of the components of lightning synthesis come together.

As I mentioned, I dive right into this session after the interview. If there is no time to do this right after the session, you must rely on the above note-gathering. However, if you can go right into affinity diagramming, you can potentially bypass the transcript portion.

In each session, I have a Miro board ready with the tags. We spend three minutes on each tag and then move on to writing any insights and next steps.

How does this look? Here is a sample plan from one of my most recent lightning synthesis sessions:

• Goals brainstorm: 3 minutes
• Goals discussion: 3 minutes
• Needs brainstorm: 3 minutes
• Needs discussion: 3 minutes
• Pain points brainstorm: 3 minutes
• Pain points discussion: 3 minutes
• Quick fixes brainstorm: 3 minutes
• Quick fixes discussion: 3 minutes
• Identifying patterns: 5 minutes
• Insights + next steps: 5 minutes

For each tag, everyone individually brainstorms all the goals, needs, pain points, or quick fixes they can within three minutes. Then, you come back together and discuss what you found for three minutes, clustering similar ideas that stood out to multiple people. I know three minutes feels like a short amount of time, but it can work since we are focusing on one participant at a time.

4. Look at 3+ patterns

Within this same tagging session, we already begin with identifying patterns. While this part doesn't make sense for participants one and two, you might already start seeing emerging patterns by participant three.

What does this look like? For five minutes, you look back on previous affinity diagrams and highlight anything that is starting to look like or already is a pattern. A pattern means three or more people have mentioned the same need, goal, or pain point.

While three isn't necessarily a magic number, it works for most studies. The more participants you have in your project, the longer you may need to wait to identify patterns. For example, if I interviewed 15 people, I would wait until five people said the same thing to determine a pattern.

However, if you can start doing this after three participants, you are identifying patterns while you synthesize.

5. Write insights

During this session, begin to write your insights when you see patterns. An insight is a nugget of truth about human behavior that pushes us to challenge our preconceived notions about how people act or perceive the world. In addition, they reveal to us the underlying motivations behind behavior.

Since this section is only about five minutes, it's essential to get your insight writing down to a science.

The way that I write insights-to-go is by including:

• The key learning. This learning may be an unexpected attitude or behavior. It could also be a problem or barrier your participant experienced
• The why. Explain why a particular behavior or attitude is coming up in the research or why a participant is facing a specific problem
• The consequence. What does this particular insight lead to, or what impact does it have on your product/service? Explain what will happen if you don't act on this insight

Generally, I will write an insight for each new pattern we identified, or tweak a previously written insight based on new information. If I use that as my presentation, I write these insights on the board. If I decide to write a report, I will put them directly into the slides.

6. Assign next steps

Once we’re done with looking at patterns, we take whatever remaining time to assign any necessary action items.

Then, rinse and repeat for each participant. By the end of the study, you should already have some great insights written in whatever report format you originally chose.

While it's challenging to push user research to its limits, sometimes we have to. Of course, not all projects benefit from lightning synthesis—but it’s an approach worth trying if you’re time-starved.