Research synthesis workshops

You've conducted the interviews, analyzed the data, and compiled your findings into a comprehensive report. But weeks later, it sits unopened in stakeholders' inboxes. Sound familiar?

In this Q&A, we speak with Odette Jansen, a UX research leader who manages research, content, and service design teams at ING. She's also co-founder of UXR Study, a learning platform for UX researchers. Odette shares her approach to synthesis workshops and how they help bridge the gap between research findings and business action.

Why research reports don't get read

There are so many reasons why reports don't get read. They're too long, they're too academic, they're too vague. They're not actually connected to the question that was asked that led to the research being done.

I love writing reports, but there are many researchers I know that absolutely detest it, which means in the beginning the report may be good, and then as they progress through the report, the quality goes down. And so you end up not delivering the right thing.

What I see the most is the disconnect between how research communicates and how the business wants to receive information. So it's, "I need an answer to my question and you are not giving me the answer, and I also don't want to spend five hours trying to find it."

Running synthesis workshops

Treating workshops as a product

So I have a bit of a format that I use, but it’s not really set in stone because I adapt it based on the people that I’m trying to get on board with the research. It also depends on the UX maturity of the organization. It’s also about the experience that you’re trying to create.

To me, the workshop is a product in itself. I look at it as, okay, who is the user of my product? My stakeholders. Who are they and how do I make sure that the experience that they have leads to solving their problem, which is "I need an answer to my question, I need to move forward."

Your users are the people that use the product you're doing research on, but your actual users are the stakeholders that need to work with what you've found. And that’s often forgotten – it's those users that you need to understand and that you need to serve with your workshop.

So I look at the situation, the organization, the project, and the prioritization of the project. I don't run synthesis workshops for everything – I run them for high stakes projects, the ones that are important, or the ones where I feel like the teams could use it to learn more about research or to get more involved in research. I usually involve developers, business people, product owners, designers, researchers.

The whole point of doing this is that we're all going in the same direction. So it starts a little bit with, okay, what's our goal here? What are we trying to get out of this? Why did we do this research?

This gives a little bit of an overview of the things that we found so far – sort of like a little tease of information and making them curious. At the end, you walk away after a two hour workshop knowing exactly what to do next.

How synthesis workshops work

We go through the data, which is preselected, because I'm not bringing tons of raw data to a session like that. Most of the time, I do pre-synthesis work beforehand to identify key themes and patterns. This preparation allows me to guide stakeholders toward meaningful insights during the workshop, rather than getting lost in raw data.

We then discuss together: What does it mean, what's being said here? And it's also a research exercise for myself to figure out, okay, how do these stakeholders look at the data? What do they find interesting?

Afterwards, I let them shine from their perspective. After we've done the theming and started discussing the possibilities, I have participants get into 'lanes' based on their roles. I prefer to run these physically when possible. Product owners go in the business lane, researchers in the user lane, and designers in the design lane.

I have a few pre-made questions, depending on the project, the goals, the metrics, KPIs, whatever. And I have them answer those questions based on the findings that we've just found. Then they talk about that together. They see where the overlap is – the findings are always the same for everyone, just from a different perspective.

The goal is to connect them to each other, to show, "Hey, we're all working towards the same thing, we're all talking about the same thing, even though we're talking about it differently."

Then we go into a prioritization exercise to figure out what the impact of the findings are and what they mean moving forward. At the end there's a very clear list – top three, top five – critical things that they need to start with.

Types of questions to ask in synthesis workshops

I don’t have set questions because it depends on the people I have in my workshop, but what I try to look at is what I know about the project. So for example, for the business lane or the product owner, they have certain goals that they need to achieve with the product or the feature they’re building. There’s certain KPIs or metrics. And so I try to have them focus on those metrics. So say their goal is to increase conversion rates for a specific flow, then I try to have them look at the insights that we’ve synthesized from that perspective. So which of these are going to help you to increase that conversion rate? 

So look at their goals, what they want to achieve, and then formulate those into quesitons they can answer. For the research lane, it’s, what does this mean for the user? What’s the impact on the user? What if we don’t do this? What if we ignore this finding, for example? And for the designer, you could reframe into what does it mean if we ignore this from a design or UX perspective.

Getting stakeholder buy-in for research workshops

Why stakeholders don’t engage with research

It's not that they don't want to hear what you have to say, they just don't want to hear how you say it. It's those long reports or the jargon or it's too heavy on the findings and not actionable enough.

You build buy-in by demonstrating value. Building relationships with stakeholders is crucial. When you understand their work and goals, you can involve them in the research process in ways that help them succeed. This creates a vested interest from them and you've gained an ally to further evangelize the need for UX work, because if you're successful, so are they.

To me, the best thing to do is to find the people that do listen or are open to listening and get them on your team. So not researchers, but people outside of research that will advocate for the value that you bring. If that means working on some smaller projects with people that are interested in research, then do that first.

Because that means that you build proof, you make an impact that you can then start spreading. Most researchers are uncomfortable promoting their work – they believe the findings should speak for themselves. But in today's environment, you need to actively showcase the value you're bringing to the organization

I have made workshops in smaller formats where I say that I can only take three people. So it's a bit exclusive. It's creating want – making them want to attend because they're going to get the stuff that they need to move forward.

How to make workshops collaborative

Some researchers find workshops scary to do; they’re not super comfortable doing it. They can put you on the spot, and you have to have your stuff together – you have to perform in the moment. But once they’ve experienced a few, they get it and they can do them own their own. 

But the one thing I still do is, at the beginning of a project, I ask my stakeholders: How do you want to receive your answer? A lot of the time we default to reports because that's what we know. We all know that they're not going to read them, though.

So what's the best way for you to process new information? Is that a PowerPoint? Do you want to sit down? Do you want me to walk you through it? Do you want a video? Do you want a podcast? Do you want a Q&A where we just sit and answer your questions?

That already helps put your stakeholders in the mindset of, "Okay, it's tailored to me. They're actually here to give me the answers that I need."

You MUST learn and speak their language. It's not their job to know the value of UX, so speak in terms they know and care about. Learn about their job, their responsibilities, and who or what they're accountable for. Then you can discuss how UX principles and techniques actually help them achieve their goals.

Key tips for researchers

Find your research allies

I think the biggest thing is allies. Find the people that want to work with you to make impact. A lot of companies have one researcher, and it feels like a really hard battle to fight on your own with multiple stakeholders that have very strong opinions. And there you are with your facts and your data.

It’s the strongest and loudest voices that are being heard. It’s never the researchers, for some reason. But there are always people within an orgnaization that have UX maturity or have more curiosity. And it’s those people you need to find and team up with. Because then they start to evagelize research and the value of it for you. And that starts to lower the whole temperature of our ideas verses theirs verses this department towards, we’re all working toward the same goal. You want more money, I want to provide a good user experience so that I get to keep my job. It’s all the same goal.

Connect research to business goals

The main thing to do when you start a research study is to figure out why you’re even doing the research. What are you going to do with the findings that I’m going to give to you? What are these findings going to lead to? When are you going to use these findings? It’s understanding the impact for you as a researcher when you’re working on a project, but at the same time, making them accountable for providing you with the reasons for doing the research. Because it also means that when you write your report, you have information that you can use to sell your findings.

Track your research impact

If you have project management tools that you use within your company, then use those. If you don’t, build your own impact tracker. This sounds super complicated, but it’s not. It’s literally keeping track of what you did and when. What were the results that you got? What was the metric that you were trying to influence? And then go back to the data analysis three or six months later to see what did change. And I think the key there is keeping it simple.

Odette Jansen is a UX researcher with 14+ years of experience. Her work blends research, systems, and people – always focused on making insights useful and helping teams and organizations grow with clarity and care. She is the founder of UXRStudy.com, a platform for continuous learning in UX research.