How to Keep Your Research's Momentum Going After the Readout

Every person who does research has felt the keen sting more than once—laboring over months worth of work, only to see their insights languish and nothing meaningfully changed.

Here's the good news: by coming up with a solid plan, sharing findings in an engaging way, and embedding yourself into other teams, it is possible to make a real change.

Read on to learn the tips you can implement moving forward so that your team's work shines. Or, watch the full interview here.

Eniola Abioye is the Founder of UX Outloud and a Lead UX Researcher at Meta.
Stevie Watts is Brand Marketing Manager at Dscout.

Jump to…

• Tips to set yourself up for success before the research begins
• How to craft your share out and present engaging findings
• How to ensure insights don’t get shelved
• How to plan research enough in advance for a half-year
• Conclusion

Stevie: You’ve mentioned before that the key to impact is setting yourself up for success before the research begins. How do you accomplish that?

Eniola: Setting yourself up for success makes a huge difference. To do so, I take myself through a scoping process that I've iterated on throughout the past few years.

It’s like doing an internal marketing campaign before the research even starts. That's a research superpower. Anyone who comes from a market research or marketing/advertising background has a huge research superpower because to build impact, you have to do digital marketing, talk with teams, and tell them what you're about to research and where it plugs in.

It allows people to have the back and forth of, “Oh, I'm really curious about this question,” or, “This really resonates with my work,” or, “Can you ask this question too since you're talking to them and stirring up excitement?”

In that scoping process, I take them through six points:

✔ Establish a baseline

One is establishing a baseline. So, what stage of the product development process is the product in currently? How are we doing, what is working well? What's not working well? What does our overall current state look like? What are the key metrics that we're most interested in tracking?

I find that the metrics that we're tracking are usually the ones that the organization is most dedicated to changing. That gives us an idea of the metrics we're paying attention to. This is what our objectives are going to be around or where a product is going next.

✔ Understand your timeline

The next point is a timeline because we know timing is always such a big element of when we do research and how we do research. It’s understanding what the product timeline looks like, when people are looking to launch, and what the politics are around the timing of your research.

If you can line up the time to when people are looking for value to be added and add value there, even if your research is not completely done, it makes that conversation much more relevant for all the parties that you're trying to be relevant for. The timeline is super important.

✔ Prepare relevant questions

Then, we have our research questions. I invite my cross-functional partners to share the questions that come to mind. They don't have to be neat and pretty and in a discussion guide yet, but just having the core questions that are going to influence people's work.

✔ Gather hypotheses

Then the hypotheses, too, so not just getting, what people are interested in knowing, but what are their best guesses already? Oftentimes we have a best guess or even sometimes we build based on those hypotheses, so being able to go back and think, okay, what do we know now? And how are we going to answer that question? If we couldn't do the research, what would that likely answer be?

✔ Establish the intended impact

This is my favorite one. Establishing the intended impact before starting the research project is essentially going into it with intention.

I want to know from my stakeholders, okay, we're doing this project, I'm going to answer these questions for you. What's next? What's going to happen? What are we going to do with these? Even drilling into, okay, if we get a positive response to this user flow, what's the next step? Or if we get a negative response to this, what's the next step? Or this product that we might build in the future, what's the next step to that?

If people have a hard time answering that, then that's a big sign that says that we need to take a step back and we need to have a sprint or a meeting with relevant parties to align on that first.

If you wait until the end when the research is already done and you have these insights and that intention hasn't been set, or there isn't alignment yet on what the intended impact was supposed to be, then you're going to be rumbling around trying to figure out how to apply your research and the insights might be getting old, right?

We know that as you’re leading up to research, there's a lot of excitement that can get cold because projects are happening or week by week there's been some shifts or a change in priorities.

If you don't grab that while people are most excited, while the iron is hot, it might be hard to go back and get it afterward. The point where engagement is highest is when people are looking forward to something and don't know what's coming yet, there's the most buy-in you're going to get. I would just be really careful to set that intended impact beforehand.

That intended impact might come over the course of multiple conversations with different types of partners or other researchers, but it's a really good one to have.

✔ Document everything for reference

Once you've set all those things, I find it important and helpful to document those things, because then you have something that you can turn back to when the insights and learnings come back.

As you're building insights out, you always want to turn back to those objectives to the baseline to those metrics to frame your insights in the context of all those things that you aligned on already. Then, because you're already speaking the language that people are familiar with, you're already answering the questions and hitting upon the things that are most relevant to the business.

That's your document to help you write your research readout as well, because you're turning back to all of those things and calling out the things that were talked about in the beginning—the important things that you went into this project trying to get to.

Now that you've wrapped up your research project, how are you crafting your share out, highlighting metrics, and presenting findings to be the most engaging?

✔ Name your constraints

Before you're doing the readout and conducting the research study, when you’re looking at the different methods you’re choosing or how creative you’re getting around who you're speaking to, it's important to also name the constraints that you're navigating. That's also imperative to share in your readout.

For example, if you’re under a time crunch and, for that reason, you choose an unmoderated research, a survey, or something for speed, it's important to name that in your readout if you want to gather buy-in from stakeholders.

✔ Build empathy with stakeholders

If you want to share video clips or sizzle reels to build empathy with stakeholders who aren't necessarily used to user research yet, that’s super important to share in your readout.

You should always be leveraging your existing data, whether it's implicit data or market data, into those questions as you go into your research. That way the questions are even data-informed by the time you make it to your readout.

It’s important to treat stakeholders like they're our users because our entire function is built around human-centered design. Take a beat to think about how to build empathy with our users and what they say, and what they think, and how they feel, and what they do.

We need to take that same look at the stakeholders who we work with:

• What do their journeys look like when it comes to our PMs?
• What do their goals look like?
• What metrics are they held accountable for?
• How do they structure their product roadmaps?
• How do they move products forward and hit their goals?

Understanding that on a level so deep that now we can engage in some service design around how we engage with them. Where were their pain points, and where were their knowledge gaps along their journey? And what are the jobs to be done? Then we can apply the points of value at the points they're looking for, or right before they're about to apply insights or continuously throughout this portion of their journey.

We’re good at that. That's what we do. Extending that same kind of care and intention around our stakeholders is going to get us a long way. In that same vein, get to know your stakeholders. Where do they engage? Where do they seem most excited?

✔ Diversify how you share information

You can do some iteration and trial and error. I've found throughout my career that some people are not into the shareouts. For them, it's nice to have, but really, they're more engaged when we have one-on-one or two-on-one conversations.

As I'm doing the readout, I'll typically do a big presentation and record it and post it. Then I'll go into a workshop approach and jump into a team's team meeting and see if I can grab 20 or 30 minutes to present the insights that are most pertinent to that team. I invite people to follow up with me and put time on the calendar for a one-on-one.

I'll make sure to send out a pre-read so people can read it on their own, and come to the share out with questions and engaging conversation topics to allow people to comment and speak up if they'd like to.

I've noticed from working with, interviewing, and studying so many different types of people that not everyone engages well in a big readout during a recorded session where the time is now to ask questions and this is the only time. Some people need a couple of days or hours to digest what was shared and interact with it in different ways.

✔ Work on building relationships

[Stakeholders] can reach out to me, or maybe I'll reach out to a PM or an engineer who seems to be engaged. That's what I mean when I say building relationships. It’s one-on-one talking to folks. If you have the chance to do immersive research, invite people that you're close with to come on those trips to build empathy in and immerse themselves into it, because you always get that “aha” moment that uncovers the struggle or cultural context that we're working within.

Building relationships is one of the big things I do. I don't just invite my product team or the teams that I run research for. I invite anyone and everyone who might be interested in this research, because products intersect so much in research questions and repeat themselves so much.

✔ Invite a wide array of people

Everyone can be on the calendar invite. If people don't have time to come, that's fine, but I invite all of my teams as well as adjacent teams. You never know who's going to be…

• Interested
• Thinking about something that might be related to what you just researched
• Working on something in the future
• Someone who doesn't have a UX researcher on their team, but they're super excited about user research

I cast a really wide net when I send out my invitations. That's the kind of thing that when impact comes—even if it's not in your specific team—but it's in another team that found what you did relevant is amazing for impact. Because now it's cross-team or cross-org, and it prevents you from pigeonholing yourself into just sharing with your team.

✔ Do a roadshow

After the research readout concludes, I do a roadshow. We've talked a lot about research in this current landscape and how we get people more excited about research and getting them to engage. They're not engaging, but as researchers, we know better than anyone that it's really hard to change behavior. We need to take our own advice on the same things that we say to our companies about users. Instead of concentrating on…“we need these people to do different things,” we need to focus on how to take the research to them.

On a roadshow, try hopping into meetings, or even one-on-ones, ask questions, and share insights in smaller settings. Some people are more engaged in those spaces or engage differently with new information. Even having bite-sized conversations makes a difference. It doesn't always have to be a formal 45-minute or 60-minute insight, because some people digest better in small pieces.

Take the top five insights and recommendations on a roadshow and start there. Then you can send people the full readout.

✔ Regroup and debrief with other researchers

After that readout, being at an organization that has quite a bit of researchers, we rely a lot on each other. I go to my research team meetings, and think about what I'm going to share, and if I'm missing anything. Should I connect the dots anywhere else? I get advice and a chance to talk through it out loud with other researchers. I also seed it with them to hear anything that's relevant to this research.

Now, you're all helping to support and spread the word and build impact for each other's work. This includes solo researchers. You can still have a research community that you can bounce ideas off of and think aloud with.

Getting a chance to bounce ideas off someone or talk out loud, even if the other person doesn't say anything, is so helpful for me. If you are a solo researcher, or if you do feel siloed in your roles, there are so many communities. For example, UX Outloud is a research community. People Nerds is a research community. Hop in that Slack group and connect with other folks who know exactly what you're talking about and can help you bounce ideas.

✔ Pull the most relevant points

The last thing I'll say is when you're presenting research, have as many examples as possible so people can see, touch, and feel the insights. Pull in examples that are most relevant to the teams that you're talking to. Go back to that baseline of what's working well and who our users are, and put together scenarios or even bring in case studies.

I'll share examples of the people that I talk to, what they sell, and what their behavior looks like to give people who didn't watch the interviews a sense of the types of conversations I had, to put things into perspective.

After you've done this share out and (ideally) everyone's engaged and on board, how do you ensure your insights don't get shelved?

This is a big one because the goal is not just the readout, right?

Oftentimes the impact comes after and will resurface, so keeping your insights fresh and relevant is super important. The way that I approach this is instead of thinking about my projects one by one. I look at my half or my year, and in the same way that we plan that product teams kind of plan for our year going forward and roadmap, I do the same thing with my research.

✔ Pull out themes for a roadmap

Here are the top three or four questions that I'm answering in the half. As I am doing my projects, how do each of those projects ladder up to those questions that I'm doing in the half? That helps me organize the body of work that I'm building or the different bodies of work or buckets of work that I'm building.

As I present those, I go into the summary of what we did in the half. I have those themes to connect the dots between different research projects. Instead of, “Here are the individual insights that pertain to this specific question in this specific product,” it's, “Here are the themes that we found out that we can share widely across the organization, so people can plug and play and apply different insights to different things.”

If we tee that up for them and share that in that way, it makes a huge difference and makes it easy to keep them relevant. Because they're not just [finding] out when that specific question has been answered. It's continuously coming up, and you're keeping them fresh and relevant.

✔ Share insights in multiple places

The other thing is where we're sharing these insights and making sure we’re sharing them in multiple places. It can feel, especially for senior researchers, like these are my insights and they're my responsibility. This is my baby for my team. We know that research is a team sport.

One of the ways to embody that is to share the insights with your research team and make sure that they're also aware of what's happening. Plug it in spaces that you're not in yet. That includes your manager and your mentors who are in the space. Make sure they're up to date on the work that you're doing and the things that came out of it that were interesting.

Speak about these insights in places where product stakeholders are. So those team standups and the syncs that seem to be engineer rundowns of the different tasks that need to happen.

At the beginning of my career, I was like, why am I here? We're not talking about design. We're not talking about research. It's taken me a long time to understand what we are talking about. So why am I here? I'm not adding anything to the conversation, and I've learned over time that it's especially important for me to be in spaces like that and hear about what we're prioritizing, the objectives, what's happening, and the nuance of what we choose to build and when we choose to build it.

As I get more comfortable in the space, like interjecting, here's a learning that is relevant to what it is that we're building, or a question that comes up and I can answer it because we already know so much about our users’ behaviors. It's not every question that comes up that doesn't require a project.

✔ Continue to build connections

Building connections with those people and being in those spaces that might be a little bit uncomfortable, that's where UX research needs to be. That's where our voices need to be to build UX research into the practice of our product team. We're not just asking them to relate when we've just recently done a project. We're asking them to integrate it into how they think and how they work.

It takes being part of those weekly standups and interjecting UX research, design thinking, human-centered design fundamentals, and heuristic fundamentals at every point.

✔ Tell a holistic story

I'll also tell a holistic story. When I'm working embedded on a product team or even a consultative, I'm close to my DS because I think telling a holistic story of qualitative data, we got quant or knowing what it would be helpful to validate with qual or with quant and presenting the story of, “Here's data that we found, here are insights that we've derived from these multiple points, and here's the evidence that we have to present recommendations.”

It's holistic and it’s helpful to meet people where they're at, because it's no secret that some stakeholders aren't super familiar with UX research. It's not about whether they're bought in or not, because if it's a priority at the company, it should be a priority for them.

It’s about how familiar they are and how comfortable they are with qualitative insights. Maybe they feel better with statistical significance. That's fine. Let's give them a holistic overview of why we’re making the recommendation that we're making, and pull on different points of evidence.

✔ Facilitate a dialogue

The last thing I want to say is, product strategy in general is meant to be a conversation. The goal of a readout or doing research is not to say, “Hey this is what I recommend,” and everybody writes it down and says, “Okay great this is awesome.” That's not the most impactful way to share insights.

It's meant to start a conversation about how we can apply this. Pushback is super healthy because you want that back and forth. You want to be able to poke holes in any framework you're building and see if it stands or not.

You're meant to iterate even in this agile environment. We don't always get the recommendation or application right. That comfort of having the back and forth and talking through how we apply insights, the validity of insights, or asking if we tested the right users or segments is super important and part of the process.

How do you help your product teams plan out research needs and questions far enough in advance that you can plan your half-year?

When it comes to reactive research, there's no getting away from it. Even with very mature research practices, there are going to be questions, because the nature of being in technology or being in an agile environment is that things are supposed to move quickly.

✔ Meet people where they’re at

I advise folks to meet their stakeholders where they are. If a reactive question comes up and instead of doing the work or supporting the team, we're like, “This is all wrong. Shut it down. Let's start over from the top.” That's not going to get us very far.

That's also going to stifle the work the team can do. Meet folks where they're at, do the research as it comes up, and then as you're helping them build that muscle, think back to the answers to that reactive question. How could we apply them to the questions that we had before those questions came up and build the muscle of, “Here's how we can be more proactive by asking these questions ahead of time.” Or taking the themes that we learned and applying them to the other things that we're doing.

✔ Learn from product stakeholders

Over time, it makes more sense for them to be able to predict and plan ahead. I'll also say as we plan out our halves, product teams also take on that same practice. Learning from our product stakeholders, road mapping, setting objectives, prioritizing the questions that we're going to answer half by half, and then executing with some flexibility for shifts as they always will come.

Starting a month before or six weeks before the next half, doing that process all over again, and then doing that process all over again. As you continue to do that, your team gets used to it. You get used to it, and you're able to plan out the core knowledge gaps that you're looking to fill with room for other things that come up.

Wrapping it up

While it’s never possible to guarantee that all your insights will be activated, there are many proactive steps you can take to increase the likelihood of making a mark. Plan your research thoroughly in advance by understanding what your stakeholders need and establish your intended impact.

Build long-term relationships with stakeholders and invite a wide array of people to the table. Once you’ve gathered insights, customize how you share those to different audiences—not everything has to be an hour-long presentation. Consider small meetings, sizzle reels, or one-on-one debriefs.

Create a roadmap in collaboration with stakeholders and facilitate a dialogue to ensure you’re working together for the best outcomes. At the end of the day, meeting people where they’re at will get you further than trying to prescribe changes.

You may also like…

• The Art (and Importance) of Building Rapport, with Eniola Abioye
• Have Research Insights Collecting Dust? Here's How to Activate Them
• Insights Activation Roundup: How to Make an Impact with Your Findings