If you’re an advocate for user research in an organization that doesn’t value it, you might feel like you’re shouting into the wind sometimes.
Too often, stakeholders (and we’re talking about executive leadership and even designer/developers) consider research an obstacle to rapidly launching a product or update. Recruiting users to interview, analyzing results and reporting on findings takes time, and in a quick-turn release cycle it may be too late by the time you get the answers you need.
What’s more, insiders think they know the product well, think they know what users want, and think it’s quicker to work with what they already think they know. Or they may have a vision for the product and fear that research will disprove that vision.
But as the product owner, you know that research can help you justify decisions and solutions you know are right for the product. You represent the prototypical user in the negotiation between stakeholders and the internal group that actually gets the work done. So you need to overcome the emotional and logistical objections to research that your team may hold.
Using Research to Balance Stakeholder Wants with User Needs
Stakeholders are experts on their product. But it’s difficult for them to remember that they are not their users, despite all the knowledge they have. They often allow their own biases, or what we call “the curse of knowledge,” to dictate solutions.
Influencers within your organization may have preconceived notions about users that impact how they envision the product’s UX. So we work to validate assumptions to create the best experience for users and help you make the smartest decisions about your product and strategic roadmap. We don’t set out to change that roadmap, but unanticipated insights have a way of revealing themselves when you’re properly listening to your users. When that happens, we help stakeholders adjust priorities and make necessary adjustments to the overall direction.
Just as stakeholders aren’t users, users aren’t insiders. They don’t have the same kind of intimate knowledge of the product that your internal team has. Our role is to use research to become experts on your users and help you deliver exactly the features and functions they need — especially when user needs and stakeholder wants don’t align.
Stakeholders are experts on their product. But it’s difficult for them to remember that they are not their users, despite all the knowledge they have.
Making Stakeholders Part of the Research Process
In our practice, research with internal influencers is just as important as research with product users during a project kickoff. Stakeholder interviews are valuable because they offer a higher-level perspective and insight into what will give the product the best chance of success in the future. Stakeholders have a solid understanding of the business and can share important background information from their previous experiences. These interviews are crucial for level-setting everyone’s views of the project by aligning on goals and expectations, scope, constraints, and expectations of users.
We interview stakeholders one-on-one to be sure everyone can be heard. We ask them important questions about the product, what they think the vision of the product should be, what the opportunity is, what else they’re working on that we should be aware of, how they define success, and what they care about.
We also involve key internal people in research planning to understand their assumptions so we can validate them in user testing. And we invite them to user research sessions — for example, we include developers so they can understand why they’re being asked to make something a certain way, and representatives from key areas of the business so they can understand why a new feature may be needed or not.
Stakeholder interviews are valuable because they offer a higher-level perspective and insight into what will give the product the best chance of success in the future.
Take an Iterative Approach to Research and Design
Research doesn’t always have to be an expensive, time-consuming process that gets in the way of rapid product development.
We advise starting with just five users. In qualitative research, 5 to 10 users is the standard rule-of-thumb, but you can make safe assumptions about the general user population by looking for patterns in the behavior of just five users. If you don’t see obvious patterns, add five more users. Interviewing more than 10 users yields diminishing returns.
By taking an agile approach, you can seamlessly integrate user research into your standard product design and development process so that it doesn’t add time. We use the RITE (Rapid Iterative Testing and Evaluation) model to quickly gain the answers we need. It starts with designing a prototype for basic testing; the research plan dictates whether that prototype needs to include just a few screens or a full working model. Then we’ll show the prototype to 5 to 10 people in each user group (say, students and instructors). Working with designers throughout the research period — for example, if we see that first two users really stumbled — we can iterate before the rest of the subjects see it. Immediately after each user session we meet with the design team to initiate changes, so they can start working right away with the shared knowledge.
Opinions are subjective. But this test/refine/test/refine model of user research can help your product team make smarter decisions that are backed in data and rooted in user needs.
And if the objections you meet to implementing research revolve around budget, remind your stakeholders that user research creates a high return on investment. Consider the 1:10:100 Rule — spend $1 on research, $10 to change the design, or $100 to change something in development.
At the end of the day, everyone cares about creating a valuable product — and the people who determine whether it’s valuable are the users. If your product includes features they don’t want or need, or it doesn’t work the way they expect it to, they’ll get frustrated and they’ll seek an alternative. And that’s bad for business.
Need to build a case for user research in your organization? Let us help.
