Supercharge your research impact:10 secrets to success you won’t learn in school

When I started my user experience research career 15 years ago, I really struggled with generating insights that would result in a big impact. My findings just weren’t resonating strongly enough with my stakeholders, which was frustrating. This is easily the case for early career researchers. We come from different fields and must expand our knowledge to work in technology and product design.

It can be a lot of fun to talk about new research methods and experimenting with things like that. But we less often receive practical advice for challenges like how to actually get your research into the product, strategy, and business decisions.

My aim is to give you a rundown of the most game-changing steps that I’ve learned. Most of these are from mentors, and these steps have helped make my research exponentially more impactful.

Maybe you learned these things in school — but I didn’t learn them in school. These are my ‘secrets to success’ that I expect most early career researchers haven’t learned. Some of these things may be helpful for other mid-career or senior researchers too.

Here are my top 10 steps to supercharging your research impact, roughly in order of a research projects’ typical phases.

Planning your research project

1. Use “risk” as a guide for how much research effort to commit.

First, use risk as a guide to knowing how much effort a research question should receive. We want to understand what the risk is if we get our conclusions wrong. If we make the wrong decision based on the research — or if we don’t do the research and go with our assumptions.

Using risk as a guide should help you scope and figure out how much time and effort to spend on each question. Concentrate your efforts around the highest risk questions, and narrow the focus on getting those answered first.

So what are the riskiest questions? They tend to have detrimental impacts on the product, such as decreasing user adoption or losing revenue. Thinking in terms of risk will also help you hone in on the most impactful questions you can answer with the research—it may lead to user conversion or retention, money saved, or even new revenue.

Focus your research around mitigating that risk.

2. Ask stakeholders, “What will you do with this data?”

“What are you going to do with this data?” may seem like a fairly simple question. But working with stakeholders to answer this will help you determine the right method to use.

Most importantly, it’s going to help your stakeholders align on what we are going to use the data to do. For instance, you might decide: we’re going to use it to make changes to the product, take a new direction, or go after a new set of users.

Help stakeholders align on whether we will use the data to:

• Make changes to the product

• Determine a new direction

• Target a new set of users

This is going to help you rule out things that are less important to answer, or less important projects you can do later. It will also give your stakeholders more ownership and commitment to your research.

3. Scope your project to minimize the time & effort you’ll spend.

Scoping your project to minimize the time and effort may also seem kind of obvious. It wasn’t that obvious to me. I had to refocus my planning process to really look at, “What’s the minimum amount of research that I need, to get the answers that we need right now?”

This extra planning effort will help you get the research done faster, and give it greater chances of getting into the product. You can always go back to the research data later on and pull out additional analysis, or look at new questions that you can bring to it.

4. Bring in something extra that stakeholders didn’t ask for.

Next, see if you can research something extra that your stakeholders didn’t really ask for. This is an important way to develop your own perspective, your own viewpoint on your product, your domain, your users.

This would look like maybe including a couple additional questions in your research plan, or some new questions in your interviews or your testing protocol.

This one also, for me, has been a lot of following up on findings from earlier research. The findings originally may have seemed potentially important or just interesting to me, but they were more minor or not very fleshed out. I kind of had a hunch of like, “I think this might be important. Let’s get a little bit more data on it.” Sometimes this does not lead to anything new, perhaps just more learning on my part. But many times, it leads to new valuable insights to consider.

Over time this practice will allow you to add huge value to your team, and provide them with something new.

5. Find ways to say ‘yes’ to stakeholders!

It’s a good problem to have when there’s a lot of demand for research, or you’re getting a lot of research requests. But you’re only one person, and you can only do so much.

Rather than saying “no,” which I’ve found myself doing in the past, you want to help build those stakeholder relationships by finding ways to say “yes.”

You can say, “Yes, great, I’ll do exactly what you asked for.” But you can also say, “Yes, we’ll do it later in the timeline,” or you can say “Yes, but we’ll do maybe a smaller version of what you’re asking for” — a different version or different method, smaller in scope perhaps. You can also say, “Yes, and we’re going to get someone else to do it.” Maybe there’s an intern on your team that would love to get more experience doing research, and they could take that on.

Rather than always say no, there are many different ways to say ‘yes’…

Yes, we’ll do exactly what you asked for.

Yes, we’ll do it at a different time.

Yes, but we’ll do a smaller/different version.

Yes, we can get someone else to do it.

Yes, we can guide/support you to do it yourself.

Another one is “Yes, but we’ll guide you or support you to do it yourself.” I’ve done this a lot with product managers who came to me asking for help with a survey, and they would do the bulk of the work and I would agree to help them revise the questions and and guide them in the process.

Conducting research

6. Always get signoff or ‘approval’ on a research plan from key stakeholders before proceeding with the project.

Always ensure you have buy-in from your stakeholders before proceeding with a research project. This is another one that’s been hugely impactful for me to include in my practice.

The idea is to avoid misunderstandings with the stakeholders early on, which might allow them to write off or ignore the research findings later. This is really about getting them all aligned on the project goals before you execute the research, to really make sure that everyone’s on board and is going to use the research.

7. Use the same repeatable research process.

Using the same repeatable process might be obvious to people coming from a more scientific research background. It wasn’t to me — I came from a design background. So I found myself kind of reinventing the process with each new project that I was doing. It’s just not necessary.

You want to follow the same process with both a long project or a short project. So each one will have some element of planning the research, recruiting your participants, and probably at the same time, creating the stimulus that they’re going to respond to (such as the interview script, testing materials, etc.). Then running (or fielding) the research sessions, synthesizing the research, reporting the research.

Follow the same process, whether a project is long or short:

• Plan questions & study

• Recruit

• Create stimulus

• Run the study (Field it with participants)

• Analyze & synthesize data

• Report

This will let you save your creativity and your energy for innovating around things like trying new methods, and not having to reinvent the research process.

8. Focus on disproving your hypothesis.

Next, look at your hypothesis, and try to disprove it! I often hear a lot of research talk about “validating a design,” or “validating a solution,” things like that.

This is really about shifting your mindset from “validating” a hypothesis (or proving it right), to “disproving” the hypothesis, or the design, whatever you’re researching. We want to get as close as possible to learning, where is our understanding — or our solution — not aligning with reality? Our job is to help our team get as close as we can to finding out the objective truth.

We want to find out early on if our hopes, our plans, our assumptions, if any of those are wrong, so that we can pivot sooner rather than later.

Shift your mindset from ‘validating’ a hypothesis or design, to disproving it.

Sharing research results

9. In results presentations, include the limitations of your study.

When presenting research results, include the limitations of your study. This is just about including “These are the limits of the method we used.” Or limits around the participants included or the timeline, things like that.

The idea is to anticipate any questions, potential concerns, or objections that stakeholders may have. Just go ahead and address them directly, and allow yourself more time during the presentation to focus on the research findings.

10. Key stakeholders should never be surprised during a playback.

A hugely impactful tip for me! Key stakeholders—such as the main folks sponsoring or driving the research need, or anyone else who may have strong objections and block the team from taking action on the research insights—should never be surprised when seeing a final results presentation. For me, this usually means reviewing the preliminary results with a handful of my key stakeholders — usually it has meant meeting with them individually.

The idea is to give them a safe place to voice any objections, or any new questions. Pick their brain about anything around their reactions to the research.

Then give yourself a chance to revise that presentation to clarify any misunderstandings or concerns that were brought up. Maybe even bring in some new findings or new questions from the data.

This will also give stakeholders a lot more ownership of the research. Rather than them becoming neutral or passive observers, or even adversaries of the research, it’s going to help convert them into advocates, where they are pushing for getting the research into the product.

Conclusion

I hope these practices will lead to greater alignment and support from your stakeholders for your research, and give you a huge amount of research impact. Please, let me know if you try them and how they work for you!

Special thanks to several of my mentors for this advice over the years:
Ellen Kolstø
Christina Larson
Eric Mahlstedt
JD Speer

Adapted from a talk given for the IBM Spark Design Festival 2023.

Rebecca Knowe is a Senior User Experience Researcher at IBM based in Research Triangle Park, North Carolina. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.

Photo by Marc-Olivier Jodoin on Unsplash