A stakeholder’s perspective on engaging in research

Here at Dovetail, we research researchers. One thing we hear all the time is that research professionals are always looking for ways to engage decision-makers in research.

While not surprising, I found this insight interesting. As a decision-maker myself (product designer), I also want to engage more with research. So why is stakeholder engagement such a challenge?

Before we have a deeper look at the problem, let’s clarify what we mean by “decision-makers.” Designers, product managers, engineers, and people in business development roles all use research as input to impact the direction and development of the product or business. It could be a shift in the company’s strategic focus or a change to a design.

The problem with reports

In my experience, the beginning of the issue often lies in the nature of reporting.

In my previous job, I would often receive a research report including findings from a broad study conducted by a researcher covering our area of the business. As just one of the designers working in this area, I found it hard to interpret actions I should take and make informed decisions on my particular part of the product.

The findings felt abstracted away from the data that led to them. I was missing context. The report was also long and covered topics across our entire department. It was hard to decipher which insights were relevant to my work and retain the information going into the design process.

My researcher was a fount of knowledge in our area of the business. I felt I could rely on her to answer all my questions throughout the design process. But she was in high demand. I was uncomfortable pestering her for details multiple times a day.

The purpose of UX research is to enable decision-makers to make informed decisions that will positively impact the product or business (or both). It’s a team effort, and we know the throw-over-the-fence reports don’t work for anybody. Since then, I have come to a few conclusions about how decision-makers and researchers can work together to achieve the best outcomes for the product and overall business.

Get involved in the research process

For many stakeholders, their level of involvement in the research process is limited to providing a brief to the researcher, then coming back at the end for the research findings. Maybe they’ll collaborate on a research plan. Or perhaps add a couple of questions to a discussion guide.

Attend all research sessions

As a designer, I find it incredibly valuable to attend research sessions to hear customer stories first-hand. Researchers are sometimes hesitant to have designers and product managers attend one or two sessions for fear they’ll only remember what they’ve heard in those sessions and make poor decisions based on a small sample of data. It’s not an unfounded fear (it usually comes in the form of an anchoring bias or an availability bias). Even if you’re aware of the bias, it’s so easy to retain and add more weight to insights you’ve heard first-hand.

This is why I prioritize attending all research sessions (or listening to a recording of the session). It helps me to build a holistic understanding of the customer and bring it into my design process. Regardless of whether you’re able to join the synthesis process or not, it’s much easier to interpret the final research insights when you have this background as context.

Give feedback to your researcher

As a stakeholder, there’s a major problem with only involving yourself during the planning phase of research and then hightailing it until the project is finished. There’s no opportunity to provide feedback to the researcher to make sure you’re learning the right things to influence the decisions you need to make.

Attending research sessions and understanding how participants answer questions can lead to new questions arising, different ways of asking questions, or finding you need to speak to entirely different audiences.

Sometimes during the research process, you can uncover questions you didn’t know to ask at the beginning of your study. Rather than waiting until all the research is done, having a gap in your understanding, and then needing to perform another study, attending sessions gives decision-makers and researchers the opportunity to be agile in their learning.

Running research yourself

It’s not always feasible for researchers to run all the research tasks in organizations. There’s usually more to learn than there are researchers available, and it makes sense for researchers to prioritize more strategic work as opposed to evaluative research.

With that in mind, there may come a time where you need to run research yourself (or at the very least, help your researcher run research). That’s not to say research isn’t a specialized craft. Researchers are experts, but they shouldn’t be gatekeepers to talking to customers.

I think of it like design and engineering. Engineers usually outnumber designers. In my previous role as a designer at Atlassian, we typically had a team of eight or so engineers to one designer. It’s not always feasible for designers to create designs for every UI change engineers implement. Designers create design systems to help engineers make small design decisions. Here at Dovetail, our engineers usually ask me to review their changes before the final design goes out. This is typically how designers scale design in organizations.

Similarly, your researcher may provide resources, training, best practices, templates, or in-person guidance to enable designers and product managers to execute on small research projects. For example, in previous roles, I was usually responsible for running usability testing of my own designs.

Quick Tip for up-skilling in research

Attending research sessions run by your researcher is a great way to learn how the pros do it.

Recently, I’ve also been participating in research studies by other companies to learn how researchers in other organizations conduct research.

Involve researchers in your process

It’s much more efficient to include researchers in your decision-making process to ensure you and your team take the right action from the research output. Treat researchers as more than input into your process, but rather as a partner—just as you are a partner in their process.

From a designer’s perspective, often after research is done, we run a design sprint to ideate solutions to problems we’ve heard or iterate on existing experiences. I like to include researchers in these processes and design rituals.

For example, I always invite researchers to design critique sessions because they can give further input on how the design meets the user needs and can help suggest ways to make the experience more impactful for customers.

I also find researchers can have incredibly valuable input into roadmap planning discussions and product strategy discussions. Researchers can bring the customers’ needs to the table and help prioritize efforts.

Researchers are more than resources

Ultimately, lots of what I’ve touched on in this article relates to enhancing cross-functionality between roles in product teams.

Many organizations understand the benefits of cross-functionality and boast about the agility of their product teams. But it’s so often the case that a researcher is siloed off, conducting research on their own and tossing reports over the fence. This means good research can often be difficult for others on the team to use and ultimately means it becomes shelf-ware. I’ve known researchers who become frustrated that the organization isn’t listening, or they find the same insights over and over again. Still, they feel the organization doesn’t do anything about it.

By opening up our processes to one another, both researchers and designers (and also product managers) stand to benefit a lot. And in the long-run, stakeholders participating and engaging with research more often and on a deeper level will undoubtedly lead to better product decisions and an overall more customer-centric culture in our organizations.