At Capacity? Consider How Your Colleagues Can Help

At some point, every researcher has this thought cross their mind: "I wish the stakeholder could just conduct this usability test so I can focus on other things."

Being an obstruction to a project is already a sensitive subject to user researchers, so we aim to avoid these situations. It takes a long time to prove the value of user research, so being the reason a project is delayed is a nightmare.

Enough researchers have had this thought—and so, the democratization of user research was born.

With this, stakeholders' education of user research exploded. Many companies scrambled to pull together material to train stakeholders on how to do user research so that researchers would not become bottlenecks. This approach makes sense with increased demand in user research, which is typically above the team's amount of work (or researcher) that can support the organization.

But if you're just getting started, it's hard to know: how much democratization is too much, too?

Why research democratization is important

I remember being a sole researcher in an organization across about ten different teams, and getting pulled in many different directions. It can feel like everything is important, everything is a priority, and if you don't do a project, the team will fail.

Although stressful, it is a realistic scenario in this industry. Even teams struggle with the constant inundation of research requests.

But you cannot and will not be able to support all the research requests you get. You may even have to reject high-priority projects that really do need research to succeed in some instances.

And then there are all those other projects that are important but have low priority, for whatever reason. Soon, you see all the gaps and opportunities where research could valuably contribute to the organization. And there isn't much to do.

Whenever the issues of "lack of time" and "lack of capacity" come up surrounding research, projects will move forward regardless—often missing the important component of customer centricity.

Several issues seem to stem from a limited bandwidth of user research:

• The company becomes too focused on a shortlist of priorities
• Smaller but important projects get de-prioritized
• There is little area to innovate on concepts or ideas that might bring much value to the company
• The team (or person) trying to support gets burnt out
• Employees get frustrated and demotivated when features are released, and there is little usage or many negative comments

What can you do to help solve some of these struggles? You can convince the company to hire more researchers, which should always be the first step. Often that is cited as too costly or time-consuming.

You can hire an external agency to do some of the research work for you, but that can be too costly, time-consuming, and have poor consequences (depending on the agency). You can also try to do all the research yourself until you can't do it anymore.

Or, you can train employees, such as product managers, designers, developers, or others who to do basic user research. Democratizing user research saves you time and money, can stop you from being a bottleneck, and solve some of the organization's above issues.

However, as per usual with user research, there are several caveats.

Where does research democratization fail?

Now that I have (hopefully) convinced you that democratizing research is necessary and valuable, I want to caution you against some mistakes I have made and seen while empowering stakeholders to conduct research.

✘ Starting with generative research

Generative research, or discovery research, is the art of asking very high-level open-ended questions, going with the participant where they decide, and appropriately following up on the most important points. Generative research took me years to truly understand, apply, and master. In fact, I've written about how I have bombed generative research sessions.

Trying to teach such a complex topic to stakeholders who have many other goals and responsibilities does not bode well. Just because I can do some basic HTML doesn't mean I can correctly code on a deeper level. Just because a stakeholder understands the importance of asking open-ended questions doesn't mean they can have deep, unbiased conversations with customers that produce rich insights.

You can teach how to ask open-ended questions, but I would steer clear of generative research.

✘ Short training programs

A half-day workshop, or even a full day of teaching, will not make a stakeholder a user researcher.

Imagine you took a day-long course on how to be a product manager. Would you feel confident working with a mix of designers and developers? Probably not. Would you be able to effectively lead and empower this team? Definitely not. The same concept applies to user research.

Three or six hours of training will not make employers user researchers. If you decide to democratize, you will have to think very carefully about structuring proper training.

✘ Lack of recurring training

User research is not like riding a bike. You can't just pick it up randomly once every three, six, or twelve months and expect to do a great job.

In fact, I now go a few months between conducting user research due to my managerial and strategic role. Right before a research project, I get nervous since it has been so long—and I have been conducting user research regularly for about eight years.

When you train stakeholders, it can't be a one-off workshop that they take, and then don't look at research for months. It's easy to forget the basics.

✘ Research becomes too in-demand

Once you get stakeholders excited about doing research, they may go off and start their own studies without checking with you first. They may also send you an interview guide that needs to be looked over and, once you look at it, you regret trying to train anyone.

Democratizing research is a lot of work, just thinking about the training materials and sessions. But there is work outside of that through supporting stakeholders through their projects. You can become a service of looking over guides, ensuring recruitment is happening correctly, and scrambling to review reports stakeholders wrote.

✘ Insights get twisted

Even if your stakeholders could properly execute on the research side and asked unbiased questions, that doesn't mean they recruited the right people, analyzed the information properly, and came to sound and valid insights.

I have seen data get completely twisted from what the participants said—suddenly, a lukewarm reaction to a prototype becomes something "users liked." This practice can really lower the quality of user research and lead to the company abandoning the practice altogether when it leads them astray.

✘ Undervaluing the complex nature of user research

The biggest point is that it makes user research seem like an easily learned skill, not a well-honed craft. By empowering our stakeholders through training, we can make our discipline seem cheap and shallow.

There is a reason I'm not asked to code or run scrum ceremonies as a user researcher, and that's because that knowledge is specialized for the roles of developers and product managers. I am not expected to code on the side when developers are busy. Instead, we wait until they have the capacity or do a better job with prioritizing projects.

User research is not just about talking to people. We have to write proper research questions, consider hypotheses and biases, identify the right recruitment criteria, create frameworks, and analyze qualitative data in an easy-to-understand way.

So, should you never democratize research at an organization? Not necessarily.

How to democratize (to a point)

I have been both in agreement with and in opposition to democratizing user research. Like most things, balance is key. Knowing how far and which parts of user research to democratize will get you to that sweet spot.

Here are some best practices I keep in mind:

✔ Identify the right types of research to teach

Again, stick with the absolute basics, such as usability testing with no metrics and straightforward prototype flows. This can also extend to writing proper survey questions or setting up simple unmoderated user testing.

✔ Start small and grow

This idea applies to both training and the studies stakeholders will run. When you begin training, only choose a few people who have, ideally, had research experience in the past. Also, start them off with surveys or testing prototypes internally before letting them off into the wild with real participants.

✔ Find interested people (with capacity!)

There may be people at your organization who are really interested in user research. That's great, but also make sure they have the capacity. I've spoken with stakeholders who love user research but have no time to learn and conduct research properly. Instead, teach people who can actually dedicate the time to learning and practicing.

✔ Create playbooks and templates

In addition to the live training, you can create step-by-step guides and templates to help stakeholders with the basics. For example, I have a recruitment email template and a guide to the most common recruitment criteria. I also provide a recording of how to note take that people can watch and practice alongside me any time.

✔ Conduct an in-depth training

As mentioned above, you should not measure your training in hours, but in days. The most effective training is live with two moderators and spans over the course of a few days. Think of it as a college course. You don't need to meet every day for six hours, but you can meet three hours for three days a week, over the course of two weeks.

I also hold open office hours for stakeholders to pop in with questions or practice with me. Whatever schedule works best, make sure that people are getting enough time to learn.

✔ Encourage shadowing and practicing

In addition to the live, in-depth training, I always incorporate shadowing and practicing. The stakeholder must shadow a minimum amount of my (or another researcher's) sessions. They then practice internally with prototypes while I shadow them and then give feedback. Ideally, they are running a real or practice session at least once a week.

Democratization has to be done and considered very carefully. It takes a lot of work to put together an internal training program for user research properly. When done well, can be very worth it.

Keep in mind that this may not work at some organizations, and it may flourish at others. Give it a try by starting small, seeing what is realistic, and then iterating to make it as valuable as possible.

Interested in learning more about research democratization? Check out...

• An interview with Julie Norvaisas on the promise (and potential) of democratization and building a resilient and adaptable team in the wake of the current work reality.
• Julie's article on getting smarter about democratization.
• Nikki Anderson-Stanier's article on how to ward off democratization scaries with four helpful steps.