SUBSCRIBE TO OUR NEWSLETTER
March 3, 2020
How to get stakeholders on board, decide what research to do when, and make it all count for your business
One of the best ways to minimize the power of that little voice, for stakeholders, researchers, and anyone in between, is to set up a fundamental UX research strategy.
Acknowledge your vulnerability and establish checks. Don’t validate; instead investigate.
A UX research strategy establishes checkpoints, reinforces the importance of research, and creates a culture of constant learning.
To build a successful UX research strategy, you need to understand who your research stakeholders are. Research stakeholders could be anyone from the CEO, who has in-depth knowledge of the business strategy overall, to the junior developer, who will end up actually building that really cool feature research helped uncover. These are the people research will impact. Stakeholders can vary from research project to project, depending on the focus and scope.
We talked to Holly Hester-Reilly, who helps companies of all shapes and sizes embrace research, about how UXR teams can work with stakeholders.
Keep in mind that in a typical org the people higher up will have a lot more access and information on the company's strategy, the resources that are available, what is the company's competitive advantage. And there may be cases where you hear something in research that seems like a great opportunity but just doesn't actually fit with those elements.
There are three different kinds of stakeholders you’ll need to consider when building your UX research strategy.
These are people at your organization who lead teams and/or projects that will be affected by research. They’re also likely to be your audience for any research recommendations you may give. Think the VP of Design who wants to know the viability of a new UX flow, the Head of Marketing who wants to investigate an acquisition strategy, or a Senior Engineer who wants to test a new prototype.
These are the people who will actually be building the stuff you learn about through research. Think the Junior Engineer who is responsible for building improvements on a feature, or the Product Designer who will create the new designs you investigate through research. Often, Implementers are also involved in executing the research, meaning they may sit in on sessions or even set up projects themselves.
These are the C-Level, or similar, people at your organization. They likely have a lot of information on where your company is going, why, and how much money the company is willing to spend to get there. They’re likely not active participants in the nitty-gritty of research, but they probably have the power to stop research if they feel it is unprofitable or a waste of time.
All of these stakeholders are important to the success of your UX research, and thereby, your UX research strategy. Each stakeholder will have different things they want and expect to get out of research, so it’s important to understand their perceptions to build a research strategy that’s impactful for everyone. You can learn more about what each stakeholder wants and needs from research by conducting stakeholder interviews.
What do you and your stakeholders hope to learn from research? How you answer this question will change what kind of research you need to do. Micheal Margolis, UX Research Partner at Google Ventures, identified the most common reasons startups need to conduct research. They are—to improve a process or workflow, better understand customer shopping habits, evaluate concepts, test usability, and refine a value proposition.
Each of these reasons for research requires using different research methods and asks different research questions. For example, testing usability probably involves doing a usability test, and the request for testing usability likely comes from your product department. Research to better understand customer shopping habits could involve doing a shopalong or a field study. The request for this research could come from your marketing or product department.
The most successful research has stakeholder buy-in, which means stakeholders are consistently consuming and using research findings, budgeting for research, and trust researchers. You’ll learn more about what kinds of research are important to your stakeholders through your stakeholder interviews. Take what you learn from your stakeholder interviews and combine it with the current state of research at your company. This will help you form your ideas about what to research next.
Making time for all this research is a strategy in itself. But it’s likely you already have a timeline you can follow, your product development cycle. Your product development cycle most likely affects all of your stakeholders (implementers, leaders, and c-levels). It’s an existing schedule, or method of shipping, and your research needs to work with it, not fight against it. We’ve mapped three key types of research to steps in the product development cycle, but this isn’t a set-in-stone, do it this way every time kind of deal. Research can be flexible and you can tailor this framework to what works best for your team.
A good rule of thumb is to always do research early and often. This way, you’re not wasting time building things no one needs or wants. Dr. Susan Weinschenk, with Human Factors International, ran research that showed that the cost of fixing a problem post-development was 100x that of fixing it beforehand, and developers spent 50% of their time on rework that could have been avoided.
But always doing research early and often may not be in the cards for you and your team, and discovery research isn’t the only research out there. So here’s how research can line up with your product development cycle, from pre-prototype to post-launch.
Discovery research usually happens before you have a prototype or product at all. In this stage, you’re learning more about the market for the thing you’re building, its potential users, and keeping an open mind about how you can best build the product your users actually need.
In this stage there are a few different methods you can use to learn more about your users and the products or features they need.
Generative interviews can be especially effective early on in your product development cycle. They involve sitting down one on one with participants, usually five is enough, and asking them questions, testing your problem and solution hypothesis.
Diary studies are great for understanding users long-term. They’re also a cheaper and easier alternative to a field study or ethnography. Diary studies involve participants keeping logs of actions and thoughts, helping you understand habits, changes over time, motivations, and long-term customer journeys.
Ethnography is all about observing people in the context of their actual lives. It’s great for understanding how people interact with your product outside of a lab environment. It can help you consider use cases, problems, and solutions you might not have otherwise. Ethnography is a type of field study in which the researchers totally immerse themselves in the participant’s environment. The drawback to ethnography is that it is typically costly and time consuming.
Field studies more broadly encompass any kind of research that was conducted outside of the lab. This may include going to a participant’s home for a session to see how your product is used in that context.
Focus groups aren’t exactly the belle of the ball in UX research circles, but they’re still useful in market research environments. They can be helpful for getting a broad view of the audience you seek to serve, offer you an insight to a group of people in a short amount of time, and can be cost-effective.
When you’re in the validation and testing stage, you typically have a prototype to test with and a good sense of your users needs and pains. The goal in this phase is to understand if these designs help users solve their problems, how they interact with them, and where they get hung up.
There are a few key methods you can use in the validation and testing phase, each with different benefits and applications.
This is the process of testing how “usable” your product is. Qualitative usability testing involves having participants test the usability of your prototype, while thinking aloud. Like generative interviews, you really only need 5 users to get a good idea of what users are thinking.
Tree testing involves testing the architecture of your website. This is useful when reorganizing your site, or when building a new one. Tree testing helps you see how users navigate through your site.
First click testing is exactly what it sounds like, it measures where users first click on your site. Why does this matter? When users fail to click the right thing the first time, their chance of getting the whole task right goes down to about 50/50. This can be useful when testing a new task, or trying to determine why users are failing an existing one.
Task analysis involves analyzing how users do certain tasks. This can be helpful when testing a new product or feature to get a better idea of the users JTBD.
A/B testing involves testing one option against another. It’s often useful to do A/B testing when trying to choose nitty gritty details, like colors or styles.
Long an afterthought in product design, accessibility is getting more and more attention in UX circles, and rightfully so. As with so many systems and institutions, a lot of unconscious bias is built into many designs, and accessibility testing is a great defense against these pervasive issues in our society.
The research doesn’t stop once you’ve launched your product though, it’s important to keep research going even after the launch of your project. At this stage, qualitative data ties in closely with quantitative data, which is likely closely tied to your business metrics. You’ll want to make sure whatever solution you put out into the world is actually accomplishing the goal you hoped it would.
User intercepts, sourced participants, short surveys—like NPS—longer surveys targeted at a particular aspect of the user experience; there are a variety of survey types and tools to help you meet your ongoing listening goals.
Analytics can be a treasure trove of great quantitative data if you know how to analyze it and connect insight to action. Keeping a close track on key user flows and business metrics will help you see changes over time. Analytics may help you define your metrics for your research initiatives.
Bugs come up and need to be fixed, users have questions about how to use your products. These are just things that happen. Hopefully, your team already has a process in place for dealing with FAQs and bugs when they come up. But keeping track of these things is incredibly valuable for informing future research and keeping an eye on whether or not the changes you made in your last round of research actually made a difference.
Deciding what projects in your product development cycle need research, and how much research you’ll need to do, and what kind, and so on, can be difficult. Still need some help deciding what's best for your team? The team at Buffer has a great framework for deciding when they need to do research, and how much research needs to be done.
1. Higher impact + not much knowledge (e.g. pricing changes) - This is the obvious one. If we’re deciding something that could significantly affect customers, we need to do some deep research.
2. Higher impact + lots of knowledge (e.g. building a new feature, significant UI changes) - This is the most problematic area because it’s easy to confuse what we know with what we think we know. Even if we do know a lot about a subject, it’s always wise to conduct some research when it’s a high impact decision.
3. Lower impact + not much knowledge (e.g. button color change) - Despite the smaller effects of these types of decisions, it’s always wiser to do a little research (e.g. get advice from teammates, running a very short survey) instead of relying on personal assumptions.
4. Lower impact + lots of knowledge (e.g. creating a landing page) - For these decisions, getting team advice is likely sufficient. In-depth research might be a waste of time and resources
This is a good framework for deciding which research will have the highest impact on your business, and why. Linking this framework with your product development cycle will help you choose when to do research, and how much research you’ll need to do.
Your research strategy will work best when it’s aligned with your business strategy. This means having an open and honest conversation about where your business is going and how research can help your team get there. Your stakeholder interviews with Leaders and C-Level stakeholders hopefully helped you learn about the business strategy and where research can fit into that.
Like any other part of your business, research should be valuable in a clear and measurable way. The best way to establish research metrics is to make sure the data you’re collecting is clear, align with the rest of your company on metrics, and store your findings meticulously.
In order for your research to truly be effective for your business, you’ll need to make sure you’re collecting clear data from research. This means getting on the same page about metrics, research goals, and questions you’ll ask in moderated research.
You can make this easy for you and your team by setting up templates that make it easy for anyone to understand what you’re trying to learn through your research. Lucky for you, we’ve already made some templates you can use for the low low price of free. Here’s our interview guide, note-taking template, and UX research plan template. You can also create your own templates for your team through Google Docs, or by using a form-filler like FormPublisher to create fillable forms you can send to your teammates when they start a project.
This templatized method can extend to stakeholders as well. Ursula Shekufendeh and her team at Copper used a templatized feedback collection form, so that the information the sales, customer support, and research teams were collecting was easily translatable to actual insights. The form the sales and support teams use at Copper includes what elements and features customers/prospects asked for. The list is problem-focused, rather than solution-focused, so it’s easy to track problems and tie MRR to research efforts.
After you’ve collected your data in a way that’s clear for everyone, you’ll need to tie that data to actual metrics. Your stakeholder interviews should have helped you establish what metrics are important to stakeholders and to the business as a whole. Whether it’s MRR, conversion rates, or NPS scores, it’s important to align your research to the metrics that are most important to your stakeholders. This will help you show the value of UX research and continue to grow your practice.
When you start your research projects, take the time to gather data about where your baseline metrics are pre-research. This helps you focus on what you really want to get out of this effort, and gives you metrics to compare post-research.
You’re probably not creating a research strategy to do one research study and then forget about research altogether. A great research practice that supports your business builds on itself as time goes on, resulting in a library of insights to draw on for future efforts. Create well-documented projects with clear and easy to track data, that are focused on moving the needle for specific metrics. Then, store your findings just as meticulously. There are many ways to establish a research repository, and you can choose whichever works best for your team. You can check out our list of research ops & insights tools here, and see practical examples of research repositories here.
So there you have it, the four steps to creating a UX research strategy that will make stakeholders happy, keep your UX research manageable and accountable for real, business metrics, and help build a community around UX research. Now go do some fantastic UX research!
Senior Content Creator
Carrie Boyd is a Content Creator at User Interviews. She loves writing, traveling, and learning new things. You can typically find her hunched over her computer with a cup of coffee the size of her face.