This is part one of a series of blog posts where Amrit Bhachu, Sr. Solutions Consultant for UserTesting, tackles the challenge of research bottlenecks and how it affects growing organisations.
Having worked within UX for the last 15 years, I have consistently felt the frustration of trying to get qualitative research into projects. It pains me to watch companies make choices blindly, based on subjective opinions, rather than gathering the insights needed to steer their decisions in the right direction.
The high price tag associated with in-person studies and the time it takes to recruit participants, run tests, and analyse the results often make qualitative research a nice-to-have. Despite organisational buy-in on the importance of customer experience and a desire for insights, traditional research methods create bottlenecks to getting these insights.
What is a research bottleneck? A bottleneck is a point of friction in a business process. Bottlenecks cause inefficiencies and delays when turning an input into output. The research process often becomes a bottleneck for several reasons, such as:
These bottlenecks hurt both the researcher and the organisation. According to survey results, only 44% of UX researchers say they can keep up with their workload. Researchers often feel defeated or stretched too thin. They may question whether their research even has an impact.
Alternatively, the organisation starts to deprioritize research or skip it when project deadlines move too fast to incorporate insights. This is what leads to subjective decision-making and relying on incomplete data.
The good news is that it’s possible to alleviate research bottlenecks. Let me explain.
As researchers, our education tells us to deliver comprehensive results every time. We’re skilled and trained to research problems extensively. Typically, a thorough, traditional end-to-end process can take four weeks, if not more. We identify the ideal solution to test, recruit the user type, outline a test plan, find the ideal environment, and analyse every second of the video with a fine-toothed comb.
But this traditional approach is slow and cumbersome compared to the speed of business today. It doesn’t fit into agile sprints, nor can it deliver lean insights. There simply isn’t enough time, resources, or planning that can account for conducting deep research every time a problem is discovered. This leads project teams to say, “we don’t have time to test.”
In reality, teams like product and marketing will continue to march forward to meet quicker delivery timelines. But instead of getting help from researchers, they’ll rely on subjective, biased decision-making. They’ll argue internally over the best path forward. In the end, the most senior stakeholder will have the final say, which leads to problems like:
Fortunately, high-quality research doesn’t have to slow teams down. Instead, as researchers, we can simplify our processes and prioritise in a way that supports objective decision-making.
Frequently, researchers are engaged long after a project has been decided on, designs drafted, and prototypes built. But it can be too late to incorporate user feedback at this stage. As a result, the finished product is compromised, and the ultimate value is missed.
This is why organisations need to adopt a ‘test early, test often’ mindset. When insights are delivered when needed, we reduce compromises and get to better decisions sooner.
To support objective decision-making, we have to train ourselves and the teams we work with to test to design instead of design to test. Doing so involves both a shift in mindset and simplifying the research process. It means employing lean insights when they’re a better fit and conducting research in an agile manner.
Here’s an example of what I mean—we recently ran a simple, rapid test for a fintech organisation. While the test took less than one day to set up, run, and analyse the results, the fast feedback at that stage of the project enabled the team to make better, more informed decisions. But, more importantly, the company saved five planned design and development effort sprints by running this one simple test. For them, this equated to £150K—all through getting the right insights at the right time.
Research doesn’t always need to be expansive or cover all eventualities, and the analysis doesn’t need to be exhaustive or of academic quality every time. However, when the requirement is to provide information that helps teams make less subjective decisions at the right time, lean insights and fast feedback represent “perfect research.” Unfortunately, less than 50% of all marketers, designers, and product teams report they’re getting feedback regularly on the experiences they create. Giving these teams access to lean insights will always be better than giving them no insights.
And to be clear, I doubt we’ll remove all subjective decisions; that’s impossible, but reducing them is a must. These are steps that researchers—and everyone creating experiences for customers—need to take to help organisations deliver value early and often and ultimately open the door to efficient innovation.
However, many will argue that the researcher doesn’t have time to run within an agile process in this manner and that they have to be more selective with their time. This is where scaling insights to other teams come in, which I’ll dig into more in the next post in this series.
Guide