Let’s imagine two scenarios for how an Experience Research project can play out. In both scenarios, a product team has questions about who their users are and how they will react to a new feature, so they turn to an Experience Researcher to learn more. In the first, the researcher goes away and comes back to the team a while later with some answers. How did the researcher uncover those answers? What makes them so sure? Should the product team just trust them?

In the second scenario, the researcher partners with the product team to get the answers to their questions together. The product manager, designers, and engineers hear user’s feedback first hand, and start to see patterns on their own. The researcher works with them to understand why those patterns stood out to them the most, and offers her expertise to add more nuance and detail to those insights. 

Which of these scenarios will result in more confident decision-making for the product team? 

More than ever, companies are turning to the expertise of Experience Researchers to understand their user’s needs and make informed product decisions. While the field of Experience Research is growing, the greatest tool we have for making sure users are represented in design decisions is democratizing access to the research process for our stakeholders (designers, product managers, engineers, and more). When the people who have a hand in implementing research insights are also involved in creating them, the lessons from research have a greater impact. As someone working in client services, this means looking at our interactions with stakeholders in a more collaborative way, that invites them into the research process and results in stronger, more actionable insights. 

In my view, the researcher is an excellent facilitator, to help a team make decisions that will move their product forward. Over my time in client services, I have worked to shift my own process so that stakeholders are more included at every stage. There are three parts of the project I focus on most to increase stakeholder investment and understanding and implementing research insights: building a stronger relationship with my stakeholders from the very beginning, inviting them to participate in the research sessions, and iterating on insights in partnership with them towards the end.

Create a Relationship to Build On

An important part of the process is to create a strong relationship with stakeholders from the start of the project. I make it clear right from the project kickoff that I’m here to help them get answers so they can make informed decisions. Research can be seen as a gatekeeper, holding back progress until some boxes are checked, but I hope to show from the start that the real strength of research is in helping teams make decisions that are good for their users. 

The other important piece to kicking off a project is that our stakeholders have much more context on the project, their priorities, and past research than we do. Our stakeholders are the experts on their own needs, and I want them to feel that way. By building good rapport with the team early on, it’s easier to invite them into the research process.

Invite Direct Involvement in Research

The real power of research is in hearing what your users have to say, directly from them. For Stakeholders, there is nothing like sitting in on an interview session with a user and hearing the raw feedback on a product or experience. As a researcher, I could play a video clip or read a quote in the final presentation, but that’s just not the same as hearing and seeing it live. Being a part of user interviews as an observer or note-taker helps stakeholders hear first hand how users feel about an experience or workflow, and that makes it stick that much better. 

On top of the first hand experience, when stakeholders hear direct feedback, it allows them to connect it to their knowledge about the company, product, or system when it comes to creating insights. Especially in the case of agency work, where researchers might not be as familiar with industry jargon, stakeholders can bring so much color and context to observation and insight creation that would otherwise be missed. 

I always make sure that my stakeholders are able to sit in on at least a couple of sessions when I’m conducting research. If they are locally based, inviting a designer or Product Manager to take notes with me is a great way for them to get involved. If stakeholders are remote, I always invite them to every session and make sure the full recorded sessions are available immediately so that they can watch in their own time. 

When stakeholders are attending the sessions in person, I make sure they have an opportunity to ask the participant questions. When they are not able to attend the sessions in person, I still like to have a short recap meeting at the end of the first day of sessions so that I can share what I’ve seen so far, and can hear from them what they noticed from the sessions. It is helpful to me as a researcher to have these debrief sessions because I often gain so much context and can make adjustments to my interview script to make sure we are getting to the meat of the experience we are researching.

Iterate on Insights

When I started working as an Experience Researcher, it was common to just share insights in the final presentation to stakeholders. A former frequent stakeholder of mine used to call it “the big reveal.” But, just like the Waterfall method is an ineffective way to build any experience because it favors perfecting the design details over iteratively perfecting the solution, waiting to present perfect insights at the end of a project isn’t an effective way to communicate research findings. For this reason, I’ve moved towards an iterative process for creating insights, where I check in with stakeholders at multiple points to be sure they are involved all along the way.

As we established at the start of the project, stakeholders are the ones who will be using the research insights to make important decisions. Since stakeholders like designers, PMs, engineers, and copywriters are the ones who will implement these insights, they should be involved in their creation. At a minimum, I will check in with stakeholders part way through the synthesis process, when I have early themes I can discuss. This can take several different forms, depending on what the project needs to move forward:

• Video Clip Synthesis: In a project where I gathered feedback on the game-play experience for a video game designed for adults with depression, I started seeing patterns in the feedback that could be interpreted as negative or harsh by the product team. Since my stakeholders were not able to make it to any of the sessions themselves, I wanted to be sure they heard the feedback from participants directly before we discussed the themes. I created short clips from three different participants who all had divergent feedback on the game, and played them for my stakeholders. This allowed them to see the themes for themselves, and we were able to have a discussion about framing insights so the rest of the product team will listen.

• Sharing Drafted Themes: While doing usability studies for complex architectural software, the stakeholders were able to attend about half of the sessions. Since they had the context of what multiple participants had said, I was able to debrief with them via Slack after every session. About a week after the sessions were over, I walked my stakeholders through a rough affinity diagram with raw observations organized under early themes. This allowed me to not only share my progress, but also get their input on what surprised them, what was expected, and how the insights connect to product priorities. This meant I knew what to put more weight on during the final share out meeting, and where I needed additional evidence to back up the insights.

These are just two examples of how I have done this in recent projects. In every case, the team has the opportunity to react to early research insights before anything is wrapped up in the neat bow of a final presentation. In my synthesis check-ins I am looking for what is surprising, what is expected, and what other questions my stakeholders still have. Just like wireframes allow a UX Designer to get feedback in the early phases of iterative design, these midpoint check-ins are crucial for getting key feedback from stakeholders, gathering helpful context on the organization and how they make decisions. As a researcher, it is my job to balance this stakeholder feedback with the important themes I heard from users, using it all to shape impactful insights.

In the end, research is only as effective as the decisions our stakeholders make with the insights. It excites me that Experience Researchers are increasingly moving into a role as the facilitator of learning for the rest of the product team. By using a more iterative process and involving the whole team in creating insights, researchers can facilitate informed decision-making, and help improve any experience for users.