In the section Collaboration = Influence, I wrote about building demand for research within a product org. But what do you do once the demand for research outpaces supply?
Scaling UXR is the next phase of organizational research maturity, and it's a tricky phase to get right! Failure to scale can hamper adoption of UXR on a more strategic level and/or cause product teams to feel abandoned. Here's a set of approaches I've found to help navigate this tricky phase.
Initially, research often functions as a service model: a product manager or design team needs user insights, so the researcher does the work and shares the findings. But if the researcher is successful, there will soon be far more research requests than they alone can address. At the same time, there will be a burgeoning appetite for more strategic research. That’s when research needs to scale.
Unlike some researchers, I love PMs and designers doing research because it empowers teams, allowing them to hear participants first-hand. It also lets the researcher support more projects at once. Here are some best practices I’ve found that can help make stakeholder-led research a success:
The right level of involvement at the right time
In my experience, teams need the most help upfront in planning research and then are able to run research with only minimal help. Then it is often useful to have a researcher involved again at the end for synthesize and next steps.
Be a guide
I love going on long rafting trips, and I think that this kind of research project is kind of like being a rafting guide: you set the itinerary and make sure that your team is prepared, but the team has to go on the trip on their own (aka, conduct the interviews, or whatever the method may be). Then you help them make sense of what they’ve experienced.
Like a good guide, you help them plan, put guardrails on the experience, and use your expertise to make sure that their journey is a meaningful one.
Identify the needs
In most organizations, there are a few kinds of research that get requested often, and it is this kind of research that it's most useful to systematize. At the same time, it’s going to work better to have teams do, say, prototype testing on their own than to do a big foundational study. Once you’ve looked at what your teams need and what they’re likely to be successful doing on their own, then you can identify which types of research to create “plug and play” programs for.
Some that I’ve seen work well are:
- prototype testing
- new feature launches
- regular product feedback
For these frequently-used types of research, I create program guides that teams can follow to run that method.
Make "plug and play" guides
These guides should outline all the steps a project will need to go through, from kickoff to conclusion, and ideally included resources to help teams through each step. Some key things to keep in mind for designing these programs are:
Project management and collaboration models. Teams often struggle with these research-adjacent pieces as much as the research itself.
Help with roadblocks. After doing a few research projects in an organization, you’ll know what the common roadblocks are. As an example, creating advisory group programs can help with recruitment, and creating ride-along programs can help with teaching basic research skills.
For me, scaling research began from a place of necessity: we didn’t have enough researchers to get the work done. But over time, I saw that there it was also beneficial for our research practice, allowing us to stay close to our products while freeing up time for strategic work. This gave us exposure to more studies and more types of studies, which in turn helped us spot patterns we might otherwise miss. More about that in strategic research!