Getting buy-in
It is well understood that involving stakeholders in user research is hugely valuable, and critical for creating a user-centric organization that builds great products.
Yet the most common objection we hear is "Ain't nobody got time for that". People are busy shipping features, putting out fires, and dealing with their daily jobs. To some extent, this is normal. Every organization has conflicting priorities and there are always short-term problems to solve, but if the product team doesn't understand users, it leads to a deadly spiral of more short-term problems and failed products.
It's an ever-present challenge for user researchers to make sure that participating in research gets the priority it deserves. We have gathered some best practices to help.
Make it easy
Treat your research as your product and your stakeholders like your customers. If a product is difficult to buy, people don't buy it. The easier you make it to participate in your research, the less resistance you will see from the product team, or even other stakeholders, like leadership.
Setting up an Internal Research Calendar and proactively notifying stakeholders about opportunities to join research is a good way to start.
Make it engaging
Ever heard the phrase, "Research reports are where insights go to die?" The sad reality is that static presentations of research results are boring and don't engage stakeholders. In our UX consulting projects we have seen many companies put tremendous effort into creating well-structured presentations, insight repositories, and short video supercuts of user interviews. While these assets have their place in user research, despite the gargantuan editorial work that goes into creating them, they fail to make an impact as barely anyone reads them. They are not enough on their own.
Humans are excited by interactions with other humans and deep insights are developed through active engagement and not passive consumption. User research should be fun for everyone and not the bitter prescribed medicine.
We recommend giving participants 5-15 minutes of airtime in each user session to ask their questions and validate their own assumptions. This also improves the research results, as everybody can bring their own expertise and viewpoints to the table and uncover additional insights.
Additionally, make sure that you brief participants and allocate tasks to them before the interview, such as noting down their 5 most important learnings, to make sure they are actively engaged.
But all that bias!
It is a valid concern, that if somebody participates in one or two sessions, they can walk away with biased, skewed, and statistically insignificant conclusions of user needs. The good news is that once somebody engaged with users, they will have developed a genuine curiosity for the big picture. Make sure to organize a recap or synthesis session at the end of a research project where all stakeholders can participate and hone their insights.
Make time
Organizations often allocate time and effort to important tasks that otherwise may get overlooked by setting very simple goals.
- "Every engineering team should spend 30% of their story points on technical debt tickets to ensure long-term code quality and maintainability"
- "The last week of every quarter, product teams should work on whatever feature they are passionate about to foster innovation (aka. hack week)"
These types of goals are simple, easy to understand, and easy to commit to. They build culture, and leadership loves them. We recommend having a similar goal for research participation.
2 hours every six weeks is a good number, but you might want to start smaller to ease adoption. Setting the goal is the important part. It also makes sense to think about different types of stakeholders and target a different number for each type. Designers arguably benefit more from spending time in research than executives or devops engineers.
Make the benefits visible
It is common wisdom that customer-centric companies investing in user research build better products and become more successful. But user research struggles with the problem that the rewards of this investment are realized with a great delay, and therefore its value often gets overlooked. Between uncovering a golden customer insight and designing, developing, and deploying a feature based on it, months, or in some cases, years can pass. This makes it basically impossible to accurately model and attribute the resulting increase in customer satisfaction and monetary benefits to user research.
This is why it's important for researchers to implement leading indicators to measure the value of research. So important, that we have dedicated an entire section to doing this with Impact Surveys.
Such indicators provide an easy-to-understand KPI for research participation. We recommend proactively publishing them at recurring KPI meetings or town halls.
Pitch, sell, evangelize
"Out of sight, out of mind" - goes the proverbial wisdom of sales. In a world of competing priorities, you have to proactively work on getting the share of the spotlight for user research that it deserves. This is especially true in the beginning when the goal is to get an initial foothold and establish the culture of research participation in an organization. Here are a few things you can do:
- Create a task list and allocate dedicated time in your schedule to evangelize research participation.
- Talk to people and find your champions in the organization.
- Set up a guild and work together. You will be surprised how many people will get behind your cause from all parts of the organization.
- Get time on the agenda in town halls, internal presentations, and other large meetings. The bigger the better.
- Always proactively publish opportunities to join research.
Start small: a template for a pilot
Trying to implement big changes all at once hardly ever succeeds. We recommend starting small with research participation, in the form of a pilot project.
- Select your next research project where you will talk to customers.
- Identify the product team (or teams) that the project is relevant to.
- Ideally, you should start with a team working on more customer-facing features, as they have a naturally higher interest in engaging with customers
- Brief the leads and the teams about what to expect and get their buy-in. The goal should be to get everyone to participate in 2 sessions.
- Run an initial survey before the project start to gauge their current level of understanding the user needs and other key metrics (more on this under Understanding research ROI)
- Set up an internal research calendar and share it with the team
- As you organize your sessions, keep the team posted about interview timeslots they can sign up to.
- Brief stakeholders before the interviews
- Make sure they prepare with questions
- Make sure they note down key insights during the interview
- Run the user sessions with the stakeholders participating
- Synthesize and analyze project findings as you would normally
- Organize a final session with all stakeholders present to share and discuss insights
- Run an Impact Survey after the project is concluded and measure the improvement on key KPIs.
- Share the results with leadership and the rest of the organization to make a case for research participation.