On asking the existential questions about a UXR’s purpose, being a thought partner, and bringing questions, not just answers
This is the second post in a bi-weekly UXR Q+A series. Submit your questions in the comments, or in this Google form, and it they may be answered in future posts. Follow “Ask a UXR” by subscribing here for email updates.
“What is the best strategy for the first/sole UX researcher on the team to establish UXR practices in the organization, and collaboration with colleagues who do not know about UXR?”
This is one of my favorite topics, both because I’ve been in this situation a number of times, and because establishing a UXR practice on a team comes with so much exciting possibility (and hard work).
First, I find that “colleagues who do not know about UXR” usually come in two flavors — those who are blank slates and may not understand how to start engaging you, and those who have preconceived notions about what research should be (or may bring up faster horses). So as Step 0, talk to your team members and understand their expectations, goals, and past experiences. This can help tease out where they stand, influence the approach you take, and help them eventually become great partners and advocates for research.
There’s an incredible amount of wisdom out there on how to be the first researcher on a team — how to communicate the value of research, include research early in the product development cycle, and identify the type of work to take on and who to hire. Being a solo UXR also comes with learning how to navigate career development and having your voice heard as a team of one. And there’s so much more — entire books have been written on this topic!
With this overwhelming list of todos, it’s natural for a solo researcher to have a strong bias to action — to be laser-focused on setting up processes, demonstrating value, and prioritizing the five million burning questions that are waiting for us on day one.
But in the rush to prove our existence is worthy, we often gloss over a critical question — what is the purpose of a researcher’s existence in the first place? And I don’t mean this in a roles-and-responsibilities way, but rather in a deeper, philosophical way.
In my experience, this sort of question comes out eventually — the only difference is how it emerges. When I get into the weeds too quickly, I find myself on a hamster wheel that’s suddenly spinning way too fast for me to dismount and un-teach the suboptimal precedents that I’ve set. Awash with the dread of this realization — only to be helplessly accelerating — I end up asking: why am I even here and what is the point?
So I’ve learned that it’s far better to have the existential conversations before diving in. It doesn’t have to be process-heavy — over time I’ve found a few high-level themes that have resonated with my teams.
Thought partners, not ticket-takers
I’ve always believed that user research is a way of thinking and a lens on the world, and that our methods are merely tools to help us do so. Most UXRs would probably agree that the real value is in thinking like a researcher. But too often, and especially on teams new to UX, the premium gets placed on the doing — writing that survey, conducting those interviews — the parts our colleagues assume they don’t have the skillset to execute. As a result, researchers run the risk of becoming ticket-takers, with an ever-lengthening backlog of stakeholder requests.
One of my first steps with people who are unfamiliar with research is to dispel the myth that UXR must be approached with an “ask.” From the outset, try telling your colleagues that they don’t need to come to you with a research question. Or a vague idea for a study. Or even any clue of how research might be helpful at all.
Instead of bringing a problem for you to solve, ask them to bring a problem they are trying to solve. Learn how they’re thinking about product strategy decisions, or advancing a design system, or tackling an engineering hurdle. Together, discover where a better user understanding could unblock, accelerate, streamline, or even challenge their decision-making. Contribute your perspective based on what you already know, and identify where there are gaps in organizational knowledge. Then, discuss how research might be able to help.
Modeling this with your colleagues sets UXR up to be a thought partner rather than an executor. Regardless of whether the eventual study ends up being a big foundational project or a usability session, you’re helping drive strategy in a more deeply embedded way. I’ve found that this approach has helped me go after the right problems, uncover the “questions behind the questions” and deliver the greatest impact.
I’ve also found that almost every stakeholder I’ve said this to has been relieved to hear it and found it unburdening. Most non-UXRs probably don’t want to come up with research questions, just like you don’t want to come up with ideas for PRDs or technical design docs. You may be surprised at what happens when you let them let go.
Raising questions, not just providing answers
Years ago, one of my managers told me he was impressed by my ability to recall research findings on different topics and offer them up, on the fly, in meetings. At the time, I was flattered, and it was welcome validation for the hours spent reading hundreds of decks from across the company.
Being the person with the answers is emboldening, a secret superpower you carry. But the more answers you have, the more questions you’re asked, and the more expertise you’re ascribed. And with greater assumed expertise comes even greater pressure to always have all the answers. It’s a slippery slope, fraught with the risks of misplaced expectations and overgeneralizing about your users, as this great article from Airbnb eloquently explains.
I’m no longer as flattered by that manager’s observation. In fact, the more research I do, the more I realize that my best work yields more questions than answers. Instead of bringing back the gold nuggets that my team is expecting, I’m often pointing out that there’s probably a better place to dig, or telling people to stop digging over there, or suggesting that these rubies I found might be more valuable than the gold we thought we wanted.
However, this can be unsatisfying for stakeholders, especially if they’re waiting with bated breath for a datapoint to cement a critical decision. In the worst cases, such insights may be misinterpreted, pushed aside, or considered a failed effort, eroding trust in UXR.
Of course, all this stems from a fundamental misunderstanding about the value of user research. As part of establishing a research function, I think it’s important to calibrate expectations about “answer-finding.”
When we resist the urge to put a neat bow on everything, allow for uncertainty, and use research to pry open the Pandora’s box, we unlock the potential for substantial change. As researchers, many of us have witnessed these kinds of deeper mindset and paradigm shifts — the kind that no amount of confirmatory studies or persona-building can enable.
Communicate to your stakeholders that identifying new questions, highlighting uncertainty or fuzziness, and being directional instead of decisive doesn’t take way from the validity and rigor of your work. Align with them on when it’s time for a crisp answer, when it’s not, and how you’ll know the difference. Doing this up front will mitigate any undue disappointment down the road.
Most importantly, show your team that successful research encompasses everything from ambiguous questions to solid answers. In adopting this, I’ve found that more of my colleagues now ask for perspective than for singular answers, something that feels more empowering than knowing it all ever did.
Engage UXR, even if it’s not the time for research
I’m a firm believer that it’s not always the right time for a study. Research isn’t always the best next step, and even if it is, a particular study might not be needed.
It can be hard to say “do we really need this?” or “we don’t have the bandwidth for this” to an eager team member who wants to engage UXR; it’s even harder when you’re building relationships with new stakeholders, to whom this may feel like disinterest or outright rejection. I’ve seen cases where turning down research has led to stakeholders ghosting UXRs for the duration of a project, or excluding research from pivotal meetings, assuming that we can’t be useful if we’re not working on a relevant study.
My advice here is brief. When setting up a research practice, emphasize the non-study ways that research can add value — being a voice in the room for important discussions, introducing user-centered ways of thinking, building empathy, organizing workshops or other activities. Take time to understand the rhythms and workflows of your cross-functional teammates, and express interest in being part of them. Truly belonging in each other’s systems can build connection, add value, and give research a seat at the table — often in low-lift ways. Whenever I turn down a study, I make sure to brainstorm other ways that I can support, or offer up office hours where my teammates can just come chat.
It’s a simple reminder that I’ve found makes a difference: I am here.
Have a question? Drop it in the comments, or in this Google form, and it might be answered next time. Follow “Ask a UXR” by subscribing here to get email updates.
While you’re here, check out Ask a UXR #1
Ask a UXR #2: introducing user research to an organization was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.