UX researchers—we have a problem.

We have an incredibly challenging role, especially when working for a company that’s new to our way of thinking. Our job comes with a big ask: We’re requesting that our non-research colleagues to question their expertise and reconsider the way they work.

This is a problem because the success of our work is 100 percent tied to how well non-research colleagues embrace it.

This may be a cultural problem within our discipline. A divide between research (or the academic variety, anyway) and “the real world” has existed for centuries. My first career was in academia, where since the 1800s, the term “ivory tower” has been used to describe academic research practices as disconnected and irrelevant to everyday life.

Certainly, UX research is not academic research. Our presence in a company is proof of research’s perceived relevance. Our existence represents the hope that there’s a solution to an organization’s biggest problem—not understanding their users.

Yet we have a disconnect. A disconnect that, in my view, is a major reason for the trend to democratize research, to throw open the curtain and allow the audience backstage to tinker with the lighting, the set, and the sound.

The problem isn’t the research we do. We are experts at research design. The problem is how we communicate the entirety of our process to our stakeholders. By “entirety,” I’m not only referring to our craft. I’m also thinking about who we decide to hire and how we make these decisions. I’m thinking about how we communicate our sometimes slow research rhythm to our stakeholders, who often work at a quicker, agile pace. Perhaps most importantly, it’s how we share our insights, make sure they land, and whether we clearly assist our stakeholders in making decisions.

I don’t want to talk about democratization of research, at least in terms of training non-researchers to do research work. Rather, I’d like to focus on three areas where we can make an impact by empathizing and educating others about how we perform research. Our potential impact, in other words, begins by honoring the non-research perspective.

Hiring is all about bringing new researchers to our teams. To help ease our workloads. Build out our research function to support more of the company. That’s it, right?

Wrong! That’s not it. Interviewing potential new UX researchers is a great moment to open a dialogue with relevant stakeholders about how we work and what our work involves.

The people your future researcher will work with most closely should be present at their interview. This is stage zero of stakeholder buy-in: Ensuring that the stakeholders feel they have a say in who will join the team.

However, being “present” in the interview isn’t the goal. Participating in the interview process allows non-research colleagues to express their understanding of what the researcher is coming on board to do. For example, if they expect a researcher will only conduct evaluative research and you planned for a focus on long-term generative research, now is the time to communicate this. It’s also a moment to share your definition and vision for UX research.

Or, maybe more specifically, our working rhythms. I hinted about this in my last point.

Let’s talk agile. Research is not always agile, but we often work with agile enthusiasts. Here’s a scenario I’ve seen again and again: Researchers join a company. There is no candid discussion about what these researchers will actually do, so everyone assigns their own definition to the researcher’s work, including their working rhythms.

There is initial pushback on research because the work they want to do is not aligned with an agile workflow. Since researchers usually sit in product, your agile enthusiast stakeholders could recover from their initial enthusiasm, shrug their shoulders, and give up. They say: researchers have convinced us they need time. But, if research doesn’t work agile, how can we work with them?

Researchers, this is our problem to solve.

As researchers, we sit comfortably in the problem space. We are trained to finesse our stakeholder’s questions into answerable research questions. We are a master at research craft. We spend time analyzing our data and crafting insights that we hope are understandable and actionable.

Here’s a scenario I’ve seen many times: A researcher completes a project, presents insights, leaves five minutes at the end to answer questions, and then moves on.

In UX research, it doesn’t matter how brilliantly you crafted your project. If these insights don’t connect with your stakeholders, it doesn’t matter if you are addressing a relevant question or you’re enthusiastic about your insights. 

What are you doing to ensure that your insights land?

Let’s return to that empathy-then-education model. Start by aligning with your stakeholders about the answerability of their question and what they can expect from the insights (I cover this extensively in my article, The Baton Handover: making insights actionable).

For better or for worse, the responsibility ultimately lies with us to make this insights thing work. It’s a huge responsibility on top of our project work, our setting up of research operations, and the time we need to spend first empathizing and then educating others on our craft.

I’ll end by stating what I said earlier: Our potential impact begins by honoring the non-research perspective. Perhaps this is the most valuable “democratization” we can participate in.