Blog

4 Mistakes I made as a UX researcher & how to avoid them

Have you ever done research without involving stakeholders? In this article, I’ll share this and other UX research mistakes I made, explain why they are problematic and give tips on how to avoid them.

Making mistakes is inevitable – it is part of growing in different roles and contexts. It can be more common at the start of your career journey since you may not know a different way yet. But even if you have experience, you may still fall into traps. Reflecting on past projects and seeing the work of other UX researchers helped me realize these mistakes and learn how to tackle them.

The 4 UX research mistakes I address in this article are:

  1. Doing research without involving stakeholders
  2. Taking on all research requests
  3. Overloading stakeholders with findings
  4. Not interpreting business implications

1. Doing research without involving stakeholders

Once, I joined a project led by a UX researcher from a different product area since the topic was relevant both for their and my team (a win-win and potential for cross-team collaboration!). I did so without consulting with my stakeholders – I thought I could just do it on the side and then show up with the findings and, as usual, my team will be receptive.

After reading the diary study entries, I’d come excited to my desk and leave the printed version there for the team. I thought this would make them curious…But no one checked the entries.

To tell the truth, I don’t think they knew what diary study was nor what we wanted to uncover. My team came to the research share-out yet did not really commit to action. It did not align with their goals, and they already had many items to work on. Nor did we establish cross-team collaboration – the team of the researcher leading this project drove action. While I loved collaborating with another researcher, it was a failure in terms of stakeholder impact.

The mistake:

It may seem more efficient to do research without involving stakeholders – no meetings, no need to explain or coordinate, stakeholders can use the time to focus on their work, and you can ensure no premature conclusions are made. While in the short term it can seem advantageous, it may have the opposite effect. Later, you could spend more time explaining or convincing stakeholders, and fail to have the desired impact.

If stakeholders are involved in the process, they are more likely to have buy-in and act on research. They are also more likely to believe and remember it. Stakeholder involvement creates shared ownership and removes obstacles for doing future research. Conducting research without involving stakeholders reflects a fallacy that we as UX researchers may fall into.

User researcher's fallacy: "My job is to learn about users". Truth: "My job is to help my team learn about users".
Tweet (by Caroline Jarrett)

How to avoid it:

  • Understand that you’re not a team of one. Overcome ‘user researcher’s fallacy’. Even if you are the only UX researcher, it helps to have the mindset that it’s everyone’s job to learn about users. This means you need to prioritize helping your team learn.
  • Set expectations about collaboration. Especially when you’re starting out at a company, doing 1:1s and stakeholder interviews, it can be a good moment to share how you work. Or, when you get your first research request. Explain to stakeholders the research process. Set expectations about when and how they can be involved across the research cycle. Assign them roles. Set up a kick-off meeting to align from the start on research goals and your research plan. This way it is unlikely they will later question your research approach or fail to commit.
The FAST User Experience Research framework (by Zoe Dimov)
  • Make participation easy. While it can be challenging to motivate stakeholders to participate in research, it helps to make it a low-effort activity. Make it easy for stakeholders to participate – whether it’s a meeting, observation or de-brief. If they cannot be there for all sessions but can join at least one – it’s a win!
  • Increase stakeholder participation one step at a time. Don’t expect all stakeholders to start participating in all activities. Focus on those interested in your work and key decision-makers. Start by having them observe research. ‘Seeing’ the data for themselves is more powerful than watching recordings or reading findings. Continue gradually involving them in more activities, like de-briefing or analysis. Ultimately, the earlier and the more you involve stakeholders, the better.

2. Taking on all research requests

As a junior UX researcher, I was assigned to support 2 product areas, each of them having multiple product teams ‘hungry’ for research. I couldn’t really engage in-depth with any of them and was in a mode of constantly ‘shipping’ research projects one by one. I accepted every request – back then, I didn’t know that not fulfilling all of them was an option.

It was overwhelming…I resorted to methods and approaches I was familiar with. And most research I did was reactive, leaving no room for more proactive initiatives.

The mistake:

Too many requests, but only one you…You may face at some point, whether you are a UX research team of one or in a company with more established research practice. You may be torn between many product teams or stakeholders all needing research support. This is not surprising because the typical ratio in organizations is 1 researcher to 5 designers to 100 developers (or lately, 50). While it is encouraging that this ratio is increasing, UX research as a discipline continues to be understaffed.

Typical ratio of researchers to designers to developers (1:50:100) based on research by MeasuringU.
Typical ratio of researchers to designers to developers – 1:50:100 (by MeasuringU)

It may be hard to say no, especially when you are early in your career – you want to be helpful to stakeholders. You may end up taking on too much and get burned out (a common issue for UX practitioners). As a result, your research could also suffer. You may not have time to ‘process’ your projects and have meaningful collaboration with neither of your stakeholders. This also means not having enough space for proactive research (which tends to be foundational) besides, often, tactical requests from product teams.

How to avoid it:

  • Accept you cannot do everything. There are never enough resources to do all the research that you or your stakeholders want to do. While accepting on its own doesn’t solve the problem, it creates a mindset that can help you address it and take care of your mental health.
  • Implement research project prioritization. Work with stakeholders and, ideally, other UX researchers to determine relevant criteria for assessing and prioritizing research requests (e.g., business importance, risk, timeline, research effort). Define the support product teams can get depending on the outcome of prioritization. Your goal is not only to say no to projects – if you cannot do the project, you may support stakeholders otherwise (e.g., advise/coach them). It helps to establish a shared prioritization framework* with other researchers or insights providers (e.g., analytics). It is easier to communicate the need for prioritization as a discipline vs on your own.
A prioritization matrix mapping value to the user and effort by an organization.
A prioritization matrix mapping user value and organizational effort (by NNGroup)
  • Set expectations with stakeholders. Be transparent. Inform them that you get multiple research requests, and you need to evaluate them before committing to a project. Don’t feel the urge to immediately say yes.
  • Be smart about your research approach. See if you can do one study that caters to multiple research requests. Consider pointing stakeholders to existing data – your past research, research from other researchers/departments and analytics. Sometimes, this may be enough to help your teams progress.

*Research Projects Prioritization frameworks for inspiration:

3. Overloading stakeholders with findings

I still remember one of my first usability test reports. I created something like a Wiki page where I listed ALL the issues and observations from the study. There was no order or priority of the findings…though I did organize them in themes that corresponded to different product pages and teams responsible for them. It took time to put this together as I wanted to capture everything and be helpful not only to my team but also others in the business.

My desire to ‘capture it all’ meant that I shared the findings too late to influence my team’s next steps. And all the additional findings that delayed the share-out were not relevant for my team.

While this research did inspire action, since my stakeholders observed the study, their learnings were bound to premature conclusions and memory biases.

The mistake:

You do a research study and there are so many interesting findings! It’s tempting to share them all…You may have spent days making sense of data and you want to maximize what your stakeholders and others in the organization get out of it.

Cartoon showing UX researcher excited about about raw data, analysis and results.
UX cartoon (by Satu Kyröläinen)

However, sharing too much at once can backfire. You may lose stakeholders’ attention since they can feel overwhelmed or tune out if it seems irrelevant to their work. Focusing too much on details can result in big issues being overlooked and teams investing only in minor changes. Thus, your research may not result in desired UX improvements.

How to avoid it:

  • Choose what & how (much) to share based on context. Consider your audience and what they need. What level of detail do they want to know? How soon do they need it? Which findings are relevant to them? If your research is relevant to multiple audiences, prioritize your direct stakeholders’ needs first, then others in the business. Consider tailoring your deliverable to make it more relevant for each audience.
  • Prioritize your findings. Help stakeholders get a sense of priority and impact on user experience. Do prioritization activities together by ranking both business and user impact. Use prioritization frameworks for your findings. Partner with data scientists/analysts to evaluate the potential magnitude. Give priority to the findings that answer your research questions, have solid evidence, provide clarity on the ‘why’ and reveal a new perspective.
Decision tree asking a series of questions to help determine the severity of usability problems.
Usability severity decision tree (by David Travis)
  • Find focus in your storytelling. Define your main messages. What do you want your stakeholders’ takeaways to be? What do you want them to act on? If somebody misses the share-out, how would you summarize it for them? Before you get lost in details, define your ‘storyline’ – it can give structure and focus to your deliverable. It is more impactful to share fewer, but solid, points that can be acted upon than too many that are ignored.
  • Co-create research artifacts. Do mapping activities with stakeholders to create artifacts, such as journeys, empathy maps or workflow diagrams. When you have a lot of findings, these tools can help structure and organize them concisely. They can make your storytelling more persuasive and convey information in a more memorable way. Also, you won’t need to share as many findings if stakeholders are involved in co-creating artifacts.

4. Not conveying business implications

My research team was once tasked to make sense of customer service data and provide insights about customer service issues. While analyzing the data, we discovered some problems with the way customer service data was tracked which had serious business implications (such as impact on important KPIs).

We decided to bring stakeholders’ attention to this, yet without much success. They were not convinced…and were reluctant to change data tracking as this required investment of resources.

While we understood the implications, we didn’t make them explicit to our stakeholders. We talked about the problem, and not about what it means and what can be done about it.

The mistake:

You’ve done research – now what? It’s a UX researcher’s nightmare to do research that does not lead to action. While you cannot fully control if your research gets used, how you work with stakeholders and share findings plays a role. ‘Giving’ stakeholders the data is often not enough to inspire action.

If stakeholders don’t know what your research findings mean, they’ll ignore them. While stakeholders may care about improving user experience, they are often more motivated by achieving specific business goals. Without speaking their language, you may fail to achieve the desired impact.

Cartoon showing UX researcher trying to convince stakeholder. Stakeholder gets on board when the researcher mentions improvements to the business bottom line.
UX cartoon (by Satu Kyröläinen)

How to avoid it:

  • Understand your role as a UX researcher. It’s hard to be effective as a researcher if you only consider the end users without caring for business needs. Be mindful that trade-offs will sometimes be made. Apply your UX research skills not only to learn about end users, but also the ‘users’ of your research…What are our stakeholders trying to achieve? What are they motivated by? How do they make decisions? Knowing this can help us be more effective as UX researchers.
  • Connect your research to business goals. Hopefully, if you involve stakeholders (#1) and have research prioritization (#2), your research supports relevant business KPIs. When sharing findings, interpret what they mean for the metrics that your stakeholders care about. To be persuasive in your storytelling, you need to appeal to the needs of your audience. Do your stakeholders want to improve conversion rate? Tell a story of how user friction points can affect it. Is loyalty important? Show how you may lose customers or keep them from churning. Join forces with data science/analytics to quantify potential impact.
  • Provide recommendations & enable next steps. Make your findings actionable by framing them as ‘how to change the product/service’ rather than ‘what we learned about people’. Translate them into recommendations – you don’t need to prescribe solutions (stakeholders are best at this!), rather open the conversation and give an idea of where to go next. Consider using How Might We statements, or re-framing user pains into ideal user goal statements that teams can aspire to reach. Set up workshops or follow-up meetings with stakeholders to help them interpret the findings, brainstorm & prioritize ideas.

Closing thoughts

As I wrote this, I realized that all these mistakes are about how we as UX researchers engage with stakeholders. Learning how to do research, or different research methods, can be after all easier to master than all these additional ‘human skills‘ we need to be effective in an organization. Which other mistakes have you made?

Photo by Sarah Kilian on Unsplash

Anna Efimenko

Anna Efimenko (she/her)

With a decade of experience in the research field, Anna is passionate about designing experiences informed by data and driven by empathy. For a big part of her career, she supported multi-disciplinary teams at Booking.com using qualitative and quantitative data to inform product design, strategy, KPIs and organisational structure. She is excited about mixed-methods research and collaborations with other insights disciplines (e.g., analytics, data science, customer service). Anna loves to contribute to UX research community through mentorship and knowledge exchange.

https://www.linkedin.com/in/annaefimenko/

10 min. read
7.6K reads

Stay ahead in UX research

Stay on top of upcoming UX research conferences, events & trainings. Get latest articles and templates from UXinsight in our monthly updates.

  • This field is for validation purposes and should be left unchanged.