Honoring the non-research perspective
*This article was originally published on Dovetail Outlier
image by Lisa Nguyen
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.
How we hire
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.
Tips:
If you are the hiring manager: Schedule a brief meeting with each stakeholder attending the interview. Find out what their assumptions are about the future scope of this researcher.
Use this meeting to align your vision to the scope. Companies are often short-staffed when it comes to researchers, so it may be that this team has a different expectation of the focus.
Sometimes, despite your best efforts, a misalignment will rear its ugly head during the interview. Don’t shy away from working through this. (Bonus benefit: This is your potential future hire’s front-row seat to how you handle conflict.)
Post-hire, this alignment is important to repeat regularly, especially for the researcher who’s joined the team.
How we work
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.
Some tips:
Back to the hiring process: When you interview for a new role, even if you are the twentieth researcher hired at the company, make sure you and your stakeholders are aligned on what you will actually do as a researcher
Together with your manager and stakeholders, determine the rhythm of your work. Some low-key evaluative projects can indeed fit into a sprint. Others will take longer and therefore need to be planned accordingly. Not just the research but also the insights sharing and the solution brainstorm
Even after you join the company, there will be moments of misalignment. Coming back to a shared understanding of what your job entails or how it could evolve is always a good starting point for working through these issues
How we share
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).
A few tips:
Take time to confront your potential fear of moving stakeholders into the solution space. Maybe you’re not sure how the research will be actionable. Or how far you’ll be expected to go into the solution space. Spend time writing down what scares you about this process. Then, connect with your stakeholders and share your concerns openly. This is a great way to build a trusting relationship that will facilitate this process.
Start every research project scoping meeting with a look back at past projects you completed with this stakeholder. Don’t conduct a full retro—that should have already happened. Ask them to reflect on past projects’ relevance and how these insights still play into their current work and questions. This situates research as more of a body of work than a disconnected project.
Open the lines of communication to see how you can best accommodate the solution space. What do your stakeholders expect from the current project? What will they do with the insights? How can you help to ensure this process is successful?
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.
