Democratization is a controversial topic. Here’s how it’s worked for me.
User Researchers debate the idea of democratization almost as often as we say the words stakeholder and impact. The question of whether, and to what extent, our colleagues who are not researchers should be doing research is something that we confront constantly and inevitably in the large majority of research roles. Do a quick search and you’ll see a variety of opinions ranging from research belongs to researchers all the way to democratizing research is the only true way to scale.
The problem with the ongoing debate and the idea that there is a one-size-fits-all policy within our company or organization is that it ignores a lot of the nuances that define daily life as a researcher.
At Lightricks, I work with a variety of stakeholders, each with different attitudes toward involvement in user research. Recently, a specific designer asked me to help them execute their own research project because they saw the ability to do so as not only interesting, but as professional skill development relevant to their field.
On the other hand, on the same team, there is a product manager who would always much prefer us to do it all and ping him when we have insights and recommendations relevant to his work.
No matter what I do, if I develop a strong policy about democratization at Lightricks, someone loses. Either professional development opportunities or a strong desire to interact with users in a meaningful way are lost, or we drag stakeholders into processes that they don’t feel compelled to partake in.
So, my answer is this: we approach democratization on an individual basis. Most researchers are comfortable with the stakeholders who say “do it and call me when you’re done” because it allows us to work in peace, utilize our skills, and do what we love. We may lament the opportunity to engage them further or the lost opportunity for increased impact, but we can usually accept it.
On the other hand, if a stakeholder comes to us and says, “Yeah, I want to, um, interview some users about this thing I’m working on. Can you connect me with a few people?”—hell hath no fury like a researcher whose colleague implies that anyone can do it.
Why is it hard for researchers to let stakeholders do user research?
I’ll humanize myself by saying this: I still cringe when a stakeholder approaches me about doing their own research. If they say something like “a few users” or “something quick and dirty”—it’s often more than a cringe. Rationally, though, I understand that this is primarily an unhelpful emotional reaction driven by nothing more than my own ego.
That reaction makes sense on some level. It’s absolutely true researchers have a set of tangible, hard-earned skills, and it’s also true that stakeholders don’t always realize this. Planning a research project with the proper methodology, interviewing a user, writing a survey question, analyzing a boatload of qualitative data, mitigating biases—none of these things are intuitive tasks that anyone can do without actually learning how. Yet, we’ve all had stakeholders say things to us like, “Well, I can write the interview questions or you can, whatever you want.”
But if we’re honest with ourselves, the primary reason we roll our eyes when a stakeholder approaches us (or, worse, doesn’t approach us) about doing research on their own is because, well, it’s insulting. Here’s the thing: we do our research practices a huge favor by taking a deep breath and letting it roll off of our shoulders.
Adopt the mindset of a research multiplier
A multiplier, in this case, is what I define as a researcher who exponentially increases the quantity of research and the impact of user perspectives at their organization by getting over themselves. It means that if we meet stakeholders where they are and choose to teach research skills over passive aggressively asserting that we have skills in the first place, everyone wins.
If a designer or a product manager approaches you about “talking to users” or “writing a quick survey” with a degree of enthusiasm to do it themselves or to be heavily involved, your response as a research multiplier should be encouraging. Offer to do a few sessions about conducting proper interviews and attend their first few to offer feedback and help them improve. Direct them to resources about survey best practices and offer to review their questions and host an analysis session when the results roll in.
Though a stakeholder’s skill level is unlikely to match yours after a few experiences like this, they can make a ton of progress over time if you’re committed to teaching over eye-rolling. Three important things happen when this is your policy:
You increase your research resources if you have stakeholders that you can trust to do all or part of research processes, even if that takes time
You create advocates out of stakeholders: no one evangelizes research more effectively than a stakeholder who starts to dip their toes into the wonderful world of user insights
You establish yourself and your team as a group of people with skills to teach. Stakeholders who learn from you tell your colleagues things like, “Interviewing is much more of a science than I’d thought. I’m learning with so-and-so on the user research team and it’s been really valuable.” Chances are, you’ll have more stakeholders knocking on your door.
As advocates for our users, multiplying our evangelists and bottom line resources within our organizations is a huge investment in being able to do more research and have more impact.
Embrace the mess
At a previous company that I worked for, I was told by the CEO that a bunch of senior managers were going to participate in the next face-to-face user research project I was planning. I wasn’t particularly excited but I rolled up my sleeves because in that case, I really didn’t have a choice.
I dutifully conducted training sessions, went over our plans a million times, and answered any and all questions leading up to the actual project where we would spend two intensive days conducting both participatory design sessions and individual interviews.
When the day arrived, I had a group of enthusiastic participants with varying success. I winced when I heard questions being asked improperly or any other trespass on best practices but overall, I managed to lean into the experience.
What ended up happening is that while yes, some data had to be thrown out because of poor collection practices—not all of it did. I offered real-time feedback and things got better by the hour.
Would it have been easier to execute that day with trained user researchers at my side? Definitely. But what I gained were senior managers who were newly passionate about the value of user insights in strategic decision-making. That did more for our practice in the long run than just doing a good job on my own would have done.
If you involve stakeholders without much research experience, there will be hiccups. It will almost always still be worth your while in the long term.
Don’t let your ego block long-term gains
If stakeholders aren’t interested in being involved in the nuts and bolts of research, don’t force them. Without their genuine interest, it’s almost certain that you and your team will do a better job. But when a colleague approaches you about doing research on their own, however cluelessly—you and your whole organization benefit from meeting them where they are.
If they don’t know that what they want to do requires knowledge and skill, show them. If they are unaware of the science behind planning a research project that delivers reliable results, explain it and let them practice. If they think they already know how, let them try and offer feedback.
As researchers who are relentlessly pursuing the integration of user voice across our organizations, surely we can bite our tongues when we feel that our skill sets are misunderstood or unacknowledged for the sake of multiplying research advocates and resources in the long term.