In Office Space there’s a brilliant scene where two consultants come in to a organisation to help downsize the company. The 2 Bobs, one of which is a very intense John C. McGinley (Doctor Cox from Scrubs) ask the protagonist of the film what he actually does. It’s cutting and brilliant in its bluntness.
However when I talk to people outside my sphere I sometimes struggle to talk about what I do as a user researcher. I don’t think I have a Chandler Bing job (nobody understands what he does), nor do I think user research falls into the tranch of bullshit jobs, but ‘user researcher’ doesn’t really say what the job is.
The term feels… serviceable.
Clear enough to get you in the room. Vague enough that half the room still doesn’t really know what you do. And to some you’re there just because someone higher up says ‘you need a researcher.’
I think the title worked in the past, but after discussions with my peers I think it might need revisiting, because the work has evolved and the term ‘user researcher’ doesn’t really say what we do anymore.
There was a time when user research sat neatly in a lane. You ran studies. You gathered insight. You handed it over. Superfriends high-5 with the rest of the design team. Then on to the next.
But that’s not how it plays out anymore.
Now we’re in the room earlier - or at least we SHOULD be. When we’re working at our best we’re helping define the problem before it’s even agreed that there is a problem. We’re shaping direction, not just informing it. We’re still there at delivery, watching what actually happens when things hit the real world.
There isn’t a clean handover in responsibility, we’re like annoying helicopter parents with consistently open questions.
There is no “done done” anymore, even though that’s what our tickets say.
The role has stopped being just about research.
So what would you say we do here now…?
What we actually do day-to-day (or at least me, and despite my inflated ego I doubt I’m unique), it doesn’t fit neatly into a single box anymore.
Some days, it looks like design. Not in the artefact sense, but in the shaping of intent. Figuring out what this thing should be, before anyone gets near a wireframe. Defining constraints. Deciding we’re building with digital LEGO over digital clay or digital meccano. We’re understanding trade-offs. Creating clarity where there wasn’t any. That doesn’t fit under ‘user researcher’.
That’s architecture, in a very real sense. Just not the kind with planning permission and drawings on fancy blue paper.
Other days, it looks like storytelling.
Not the fluffy kind. The kind that carries weight. The talking through of bad journeys which can stop users getting the help they need. The stories that bring up why the work is so important. I myself have interviewed gambling addicts, victims of modern slavery and the recently bereaved - making their voices heard is an incredibly important part of the job.
Don’t get me wrong - there’s also brilliant stories of saving up to buy the perfect pair of shoes or seeing the joy in a data architect’s face when an API just works…
But those voices need to be represented and threaded into a clear and actionable narrative. Because insight doesn’t do anything on its own. It just sits there, technically correct, strategically ignored to die on Confluence.
We build narratives. We create tension. We show consequences. We make it land in rooms full of competing priorities and louder voices.
We’re not just saying “this is what users said”. Although I definitely include verbatim quotes.
We’re shaping how a team understands reality. And a lot of the time, whether we say it out loud or not, we’re shaping decisions.
That’s the throughline. Not outputs. Not decks. Not perfectly crafted artefacts that get politely nodded at or get a ghostly thumbs up at on a Teams call and quietly forgotten.
User researchers should be at the core at driving decisions.
What do we do next?
What do we not do?
Where do we place our bets?
Who do we need to speak to?
If the work isn’t influencing that, then it might be interesting but it’s not impactful.
So… back to the name.
“User researcher” still works, in the same way an old map still works. You’ll probably get where you’re going, but you’ll miss a lot along the way. The industry likes a clean label. Something you can put in a job description. Something you can hire for. Something that fits neatly into a capability model.
But the role itself is stretching:
Up into strategy.
Sideways into design and product.
Across into delivery and iteration.
Trying to compress that into two words at best feels… optimistic.
Maybe the more useful shift isn’t the title, but the stance we take.
Less: “I do research”
More: “I help teams make better decisions about people”
It’s a subtle shift, but it changes everything.
You’re not handing over insight anymore. You ride or die with the consequences.
Of course, we can’t resist naming things.
So if we were to try and capture it:
User need architect.
Decision intelligence partner.
Experience strategist.
Human insight lead.
Narrative operator.
Product sensemaker.
Vibe architect.
None of them quite land. All of them are reaching for something the current title just doesn’t get.
The real question isn’t what we call ourselves. It’s whether we’re willing to step into what the role is becoming. Well, that and do recruiters know what I do so they can find me?
More influence means more responsibility which we take on by working with teams.
More proximity to decisions means more challenge which we’re ready to take on with stories and data.
Less room to sit comfortably behind “I just drink unhealthy amounts of Monster and ask questions.”
That shift isn’t about semantics. It’s about posture. The title will catch up. It always does. And you can guarantee some weirdo on LinkedIn will claim they coined it in 2002.
But right now, there’s a gap between what the role is called and what the role actually is.