UX research isn’t QA. And it isn’t an ombudsman.
It’s important for your team to understand where research brings value and where it doesn’t.
Earlier this week, I wrote about my frustration with UX researchers who don’t want to do any usability research. It’s a critical part of the UXR role and researchers must embrace it (and get good at conducting that type of research).
But there are situations where organizations expect UX researchers to conduct research too often and to answer questions that UX research isn’t suited to answer. In my experience, these expectations from teams usually signal larger organizational issues.
When research brings the most value
I believe that UX research brings a ton of value to organizations, especially when it:
- Helps organizations build products that are easy and delightful to use while meeting people’s needs for those products. This is at the heart of our role as UXRs — to conduct foundational, concept, and usability research to help teams understand people’s unmet needs and then ensure that we’re building products that solve those unmet needs (and are easy and fun to use).
- Is conducted in time to drive product direction or have an impact on how a product is designed and built. We have to ensure that we’re conducting research at the right time in the product lifecycle and that we can produce research findings at the right time for a team to act upon those findings.
- Uncovers new trends in consumer behavior. Anticipating changes in human behavior and looking out for emerging patterns is where research can bring the most strategic value.
- Provides an understanding of an organization’s consumers and how they’re using an organization’s products. Once you’ve launched a product, research can shed light on how and why people are using your product.
- Builds empathy for consumers. Whether it’s an immersion research trip or good storytelling when presenting research findings, good researchers can take data and help stakeholders see it in a way that connects with them and helps them identify with the needs and constraints of their consumers.
When research brings the least value
UX research can’t answer every question or resolve every conflict. And you can do too much research. In my experience, here are the situations when UX research is least valuable:
- When it’s used as a quality assurance function. There are teams that think that every small change needs to be “tested” with users. While I strongly believe in the value of getting user feedback, there are only so many hours in a day, so many researchers on a team, and so much budget for research. There’s a point in the product lifecycle where conducting more usability research (instead of using the research team’s time for other projects) yields diminishing returns. Now, QA is absolutely a necessary part of the product development lifecycle. But it shouldn’t be carried out by the research team or research participants. That’s simply a far too expensive and inefficient way to do QA.
- When it’s used to settle disputes. Can’t decide which direction to go with a product? Let’s bring research in and have “the data” tell us what to do. That seems like a reasonable plan, right? NO! The problem with this approach is that it only delays the decision being made while research is conducted and the data is analyzed. The conflict (and whatever organizational disfunction that’s lurking below the surface) still exists. Data is always open to interpretation. When I’ve been put in these situations, I’ve found that regardless of what data I bring back and regardless of how we defined success metrics as a team prior to the research, someone will always find a way to use the data to argue for their perspective.
- When it’s used to circumvent UX expertise. I strongly believe that competent and experienced UXers have honed their intuition about design and user experience. The best designers I know are the ones who use research to fuel their imagination and vision. Less talented designers are the ones who either totally ignore research or expect research to tell them exactly what to design and how to design it. Designers shouldn’t expect research participants to tell them how to do their jobs. And UX expertise and perspective should be valued by the cross-functional team and shouldn’t constantly be questioned. Attempting to use UX research to circumvent design expertise is usually a sign of a mismanaged organization (and one that doesn’t value UX and design).
- When we don’t have a clear research question or attempt to answer too many research questions. There are times when researchers plan bad research. Research that doesn’t have a clear research question won’t yield much new insight for the team. And no one study can answer every research question the team might have. I’ve written a bit more about both of these issues with research plans here.
- When the research is too late to impact the current release and won’t inform the next release. If a tree falls in a forest and no one is around to hear it, does it make a sound? We could ask the same question with ill-timed research. If research is conducted too late in the cycle or a researcher takes too long to produce results, a researcher might have missed their opportunity to have their research make an impact on the product and the team.
Changing a team’s culture
In some organizations, UX research is still a fairly new discipline. Cross-functional stakeholders may not know how you as a UX researcher can bring value and what your role on the team should be. If you’re in that situation, a big part of your job will be to evangelize research to your team and explain what research can answer and what it can’t answer. You can put together processes, documentation, and presentations explaining your role and how the team will engage with you. This level of evangelism is important to set a foundation and establish yourself as a leader on the team.
But you should know that this process will take time. Because you’re not simply explaining to people how you’ll do research and when you’ll do research. You’re actually trying to change a team’s culture … and that is not an easy task. In my experience, this culture change happens after I’ve consistently delivered research that helped the team ship a good product, shifted product strategy, or provided the team with a different perspective.
It’s important for you and your team to recognize that your time as a researcher isn’t limitless. And it’s important for you as a researcher to set boundaries. You won’t be able to answer every question and you can’t predict the future. And some research questions are better left to other disciplines to answer.