10 Practical Tips for Increasing the Impact of Your Research Insights

Posted by

User experience (UX) researchers tasked with improving customer-facing products face many challenges on a daily basis—perhaps none more daunting than translating their research insights into positive change. This article presents 10 tips I have learned over the course of my career to help UX researchers increase the impact of their research insights in applied settings. These tips are intended primarily for in-house research teams, but they may apply to consultancies as well.

1. It’s a long-term relationship, not a speed date.

For research insights to impact a specific product, the researcher must establish a deep connection with the product team. What is the context that the team is operating within? What are their constraints, challenges, and deadlines? What are immediate goals, and what objectives are longer-term? How is success measured by their superiors? Given those circumstances, what can you do to help them without adding to their workload? Above all, you want your product team to perceive you as a benefit rather than a hindrance. This is not to say that you cannot critique their work, but never lose sight of the their ultimate goal: to create products in a timely fashion that will drive business metrics when launched.

For example, suppose your product team is racing to launch the product by a specific deadline, and you discover a problem with the product during testing. In such situations, you should not immediately advocate that the launch be delayed. Instead, think about the best way to raise the issue (and to whom you should raise it) and frame the issue in terms of potential courses of action. Can the team reallocate resources to keep the current launch schedule? Can the problem be corrected in the next dot release of the product? Is the problem serious enough to warrant pushing back the launch schedule? Over the course of working with your team, you will have many opportunities to demonstrate empathy for their challenges. Doing so will build trust and help you become an integral member of the team.

2. Serve ‘ready to bake’ bread.

The best way to ensure that action will be taken to address your research insights is for someone else to take ownership. Researchers often view it as their responsibility to make specific recommendations from their research, but what really matters is that the insights lead to clear potential solutions. The solution doesn’t need to come from the researcher herself.

Instead of a recommendation that does not offer any unique value—for example, “Users were confused by X. My recommendation is to fix X”—a better strategy is to offer specific recommendations when they are not obvious and when you have confidence that they will add unique value to thinking about the problem.

Better still is something else entirely: Offer “ready to bake” bread.

In other words, present the problem in a way that clearly lends itself to a specific solution and let a product team member connect the final dots so that they consider it their idea and take ownership over it. In cooking parlance, give them bread that is basically already made but needs only a few more minutes in the oven. So, instead of giving them raw dough (raw data) or fully-baked bread (a specific solution that you explicitly offered), give them ready to bake bread. People are more likely to follow-through on something when it is their idea and everyone implicitly ascribes ownership of the idea to them.

One way to do this is to frame key research insights as “How might we?” questions to spur discussion. Doing so can effectively portray the researcher as a facilitator of collaboration rather than someone who provides heavy-handed mandates for the team.

For example, suppose users in a research study exhibited difficulty navigating to specific types of offerings. Instead of recommending that the team “Implement more top navigation menu options,” you can instead ask  “How might we convey the breadth of our offerings and provide quick access to different product categories?”

3. Know the whole story before writing the first chapter.

Researchers should strive to present their research insights in a clear, compelling, and elegant way. Instead of proceeding straight from raw notes to a Powerpoint presentation, synthesize the data and create an outline summarizing the main ideas and how best to convey them. Presentations that skip the important synthesis step can seem disjointed or disorganized and can lead to audience fatigue or lack of clarity about the most important points.

These best practices are not limited only to qualitative research, such as user visits or usability studies; they apply to quantitative research, such as surveys, as well. Common practice when presenting survey-based research is to devote one slide to data relevant to each survey question and present detailed information such as charts, graphs, statistical significance across numerous comparisons, and so on. However, a better practice is to first create an outline that summarizes the top 3 or 5 or 10 key points that you wish to convey to your audience based on the survey data as a whole.

4. Don’t lose the forest for the trees.

As difficult as it may be, researchers need to resist the temptation to share every interesting finding from a study. When a researcher presents findings, he is telling a story and needs to be mindful of tangents that detract from the overall message. So if you want to convince the audience of a few key themes, ask yourself if each point you are making ties back to one of those themes. If not, then perhaps another forum would be more appropriate to share it.

I tell researchers that there is a continuum with impact on one end and exhaustiveness on the other, and different researchers operate at different points on the continuum. In my opinion, it is best to land on the side of impact.

If you have one hour to present important insights to senior stakeholders, it is more important that those stakeholders leave the room with the key points to act upon. It is less important that they understand every subtle nuance of the data or that other stakeholders can find such nuances a year from now. I call the one-hour presentation “The Golden Hour.” Once those stakeholders leave the room, you may get another opportunity to convey the key points, but you’ve lost your best opportunity to make a lasting impact.

5. Don’t crawl across the finish line.

After presenting insights, researchers typically send an email that shares the deliverable with the immediate product team as well as with the entire product organization. This may seem like a minor, perfunctory step, but it is a very important factor in determining what happens next.

An effective announcement conveys the key takeaways in a clear and concise manner and serves as a catalyst to action. Frame the email in the context of the team and the project (e.g., If their overall goal is to increase engagement, frame it in that light.)

Or, if the product lead reframed your research in a specific (helpful) way, build on that. Once, in my experience, a project manager concluded from a research project about improving the map view of search results that the research instead underscored the need to improve the list view of search results. I built off of that in the announcement, both because it was provocative but also because everyone else in the room heard the comment as well—and I agreed with it.

And don’t lose sight of the basics. Have a clear and compelling title for your email that draws the reader in. You want to get other people interested in your research who may not have attended the presentation. Ask yourself which email you’d be more likely to open: One with a subject line of “Posted: Redemption Research” vs. “The Life of a Groupon: Eliminating Barriers to Redemption and Increasing Engagement”?

6. The end is only the beginning.

The research presentation is really the beginning of the journey rather than the end. You want to make it easy for your team to track your insights and take action to address them.

I’ve always been amazed at how dependent product managers and engineers are on tracking tools. I recall a time when I said “The one thing you need to remember is to do X” … to which they replied, “Ok, well then submit a ticket for that.”

I thought to myself, “It’s only one issue,” but now I realize that PMs and engineers are constantly flooded with problems to fix and it can be difficult for them to separate small issues from big ones. They’re all bugs—just with different levels of priority and required effort.

I’ve found that a shared Google spreadsheet is an effective way to track such issues. Each issue or insight is given a row in the sheet and is assigned an owner who is responsible for the status of the issue and next steps. That said, work with whatever tools your team uses. The last thing most product managers and engineers want to do is learn how to use another tool.

Another important consideration is to ensure that you have a clear path forward right from the outset for ensuring your research has impact. Establish a plan with the product team before you conduct research that makes explicit how and when product improvements will be made based on the insights. You may find that product teams are enthusiastic about research, only to discover after completing the research that they had not thought about how they would act on the findings. Prior to kicking off the research, establish a timeframe for when you’ll present your findings, when changes will be made, and who will be responsible for making them.

7. Know your allies…and how to find new ones.

Your immediate product team is obviously your best bet for addressing the issues surfaced in your research. That said, product organizations typically have many interdependencies, so there are probably other product teams who have some stake in what happens to your product.

Reach out to those product teams to share your research and determine if your research can be reframed to be more directly relevant to them. For example, one team may be focused on new user acquisition whereas another team may be focused on increasing engagement. Some of your findings may apply to both goals, so reframing a few key points can open up new audiences (and doors) for your insights.

To make this possible, know the product leaders in your organization, who they are, what they do, and what their goals are. You may find that they value your research and might even be willing to evangelize it across the organization.

8. Don’t give them what they want.

Teams often don’t know what they need, so they may say they want you to conduct a specific research methodology or present the data in a specific way.

Rather than reactively giving them what they want, think about what they need. Echo back your interpretation of what they’re asking for or what they’re trying to accomplish. For example, “So what I’m hearing you say is that you want to investigate whether users understand how to filter search results and whether we’re offering the right set of filters. Is that correct?” This will enable you to focus on the right methodologies to get the answers they need.

While your initial resistance to carrying out their demands may create friction in the short-term, it will establish your credibility and influence with the team in the long-term.

9. It’s not about the VP.

A researcher working at another company once contacted me looking for advice. She had recently completed a research project but she was having difficulty getting the product team to take action. She asked me for any tips about how she could get the research in front of the vice president leading the product area. As she put it, “If we can just get it in front of the VP, things will happen.”

In most corporate environments, executives don’t want to hear about problems; they want choices. It is up to the researcher to convince the PM and cross-functional team of the issues at hand and lead the charge to create potential solutions. If there are alternative solutions that the team cannot agree on, then the VP can make that decision.

If the cross-functional team is not interested in working with you to create solutions, then you need to re-evaluate if the problem you are trying to solve warrants team resources relative to other team priorities and/or if you have clearly and convincingly presented the problem.

Does the team even agree that it is a problem? Have you leveraged other data sources to make a more convincing argument?

10. Be your brand.

Your work is your brand. You want audiences to know that when you conduct research it will be high quality, and that when you present, your presentations will be engaging. As one PM told me recently, “You put a lot of love into that presentation.” He wasn’t talking about fancy graphics or illustrations but rather that I had clearly given a lot of thought as to the important insights and how I should best present them so that they were clear, concise, and well-substantiated.

Of course, there are situations where you cannot make a masterpiece of a presentation, and you shouldn’t always try. But remember that your brand stays with you, even when you leave your current company.

Beyond the quality of your work, you want to be thought of as someone who helps product teams progress toward their goals. You are someone who is there to help the team succeed, not slow them down, and you’re mindful of the teams’ constraints, deadlines, and challenges. You’re not just there to point out problems but to create and drive solutions.


Turning research insights into positive action is a combination of what you do but also what you are able to empower others to do. Knowing your audience and bringing the right mindset to the table can go a long way to making an impact in your organization.