Has UX become everyone’s job but no one’s role?

UX may have won the methodological argument while losing the organizational one.

Don Norman has explained that he coined the term “user experience” while working at Apple in the early 1990s because he felt that “human interface and usability were too narrow.” UX was supposed to be bigger than the interface. It was about the entire experience a person has with a product or system.

Today, many of the ideas associated with UX are embedded in modern product practice. Modern product teams are expected to understand their users, explore problems before committing to solutions, and learn through iteration. Research and discovery are increasingly collaborative activities across Product, Design and Engineering.

So why does the UX Designer seem to be disappearing?

The dedicated UX Designer role feels less visible, while the combined title “UI/UX Designer” has become remarkably familiar. And I sometimes wonder if the order of those letters tells us more than we think. In many of the teams and organizations I encounter, people with UX in their title seem to spend much more of their time on “the UI” than “the UX.” They focus on solution delivery, while research, discovery and problem framing happen elsewhere, collaboratively across the wider product team (or sometimes not at all, but that’s another story).

I first encountered interface design around 20 years ago, and the tools of the trade were, of course, Photoshop and Dreamweaver. An entire web page could be designed as a single bitmap image in Photoshop, sliced into small parts and assembled in HTML. Anyone remember the Slice Tool? I don’t even know if it exists anymore. I still remember making a button switch between two JPG images on hover for the first time and being pretty impressed with myself. Today, that sounds comically basic.

While UI was once commonly treated as one part of the broader UX discipline, it has since developed into a serious specialist discipline of its own. Components have variants, properties and states. Design systems have tokens and variables. Interfaces need to work across screen sizes, themes and accessibility requirements. Tools like Figma increasingly reflect the logic and structure of the systems developers eventually build. That doesn’t necessarily make UI design harder than it was 20 years ago. The tools have made an enormous amount of work easier too. But UI has become a deeper and more systematized discipline.

And to me, that makes the combined UI/UX title interesting. If UI itself now represents a substantial body of specialist knowledge, what exactly happened to the other half?

UX had to find its place

UX was already an established discipline when Agile and Scrum began reshaping software development, but it never had an explicit role in the Scrum framework.

That doesn’t mean Scrum excludes UX. Of course, a UX specialist can be part of a cross-functional Scrum team, and most of us probably work in some kind of agile setup. Scrum wasn’t designed around specialist job titles in the first place. But while the Product Owner and the Development Team had defined roles in the framework, UX expertise had to find its place within the team.

I struggled with that myself earlier in my career. Trying to make UX work fit naturally into Scrum sprints didn’t always feel right, so I went looking for other perspectives and came across a 2017 article from Nielsen Norman Group.

Their diagnosis was rather direct: “UX wasn’t originally considered in the Scrum definition.” They described orthodox Scrum as a “technology-centric process” and warned that UX designers could end up receiving already-defined features and workflows, only to “make them look nice.”

That line stuck with me. Then, just a few months ago, a Product Manager I work closely with used almost that exact sentence, with no irony intended: “just make it look nice.” We have a great working relationship, so I mostly found it amusing that, nearly a decade later, I was hearing the same line.

Over time, much of the work traditionally associated with UX has found its way into modern product practice. User interviews, prototyping, opportunity discovery and assumption testing are now commonly framed as activities for the wider product team rather than the UX specialist alone.

You can see the same shift in mainstream descriptions of Product Management. Atlassian describes UX as “one of a PM’s core responsibilities,” while stating on the very same page that “a product manager owns the ‘what’ and ‘why’ of a product.”

And that is mostly progress. Understanding users shouldn’t belong to Design. Product Managers should be involved in research and discovery. Problems are better understood when business, design and technology explore them together rather than throwing requirements between silos.

As UX methods became more widely distributed across the product team, a different question emerged: what happened to the specialist expertise behind them? When UX becomes a shared responsibility across Product, Engineering and Design, it can be present throughout the product process without necessarily being anyone’s primary specialism.

That brings us back to UI: if UI has become a deeper specialism of its own, is it still realistic to treat UI and UX as two deep specialisms within the same role?

A UI/UX Designer can be highly skilled in both, but that isn’t really the point. When an organization defines UI and UX as one role, it also makes an assumption about how much depth that role can realistically maintain across two substantial disciplines. Both require their own specialist knowledge, methods and practice.

Putting UI and UX into one job title doesn’t make either discipline half as big.

Large organizations have more room to address this through specialization. When the same product responsibilities have to be covered by fewer people, combining disciplines into broader roles can be a practical necessity. Combining UI and UX while sharing research and discovery across the team can therefore make perfect organizational sense. Whether it preserves the same depth of UX expertise is another question.

Even when the expertise is there, the practical question remains: how much room is there to use it? That may help explain a frustration I keep encountering among designers: not having enough time for research, being brought in after the scope has already been defined, being asked to validate a solution rather than help discover it.

Are we really losing anything?

I work with highly specialized users whose domain knowledge I could never expect to have myself. That makes a basic premise of UX particularly obvious: I am not the user, and I can’t simply reason my way into their experience.

If anything is at risk of being lost, I don’t think it is the title itself, but the depth of expertise behind it.

That is where UX expertise comes in: not as the person who somehow knows what users need, but as the person who knows how to build that understanding. In my experience, that simply isn’t the primary focus of most people working primarily in Product, Engineering or UI. Nor would I expect it to be. Their expertise lies elsewhere, just as mine does in other areas of product development.

To me, much of that work is facilitation. UX doesn’t need to own the decisions or do the work alone. The wider product team should be involved in understanding users and making the trade-offs together.

The concern is what happens when we confuse sharing the work with sharing the expertise.

In organizations large enough to support dedicated UX specialists, that expertise may have an obvious home. But where does that leave organizations without them?

UX may not need its own dedicated role, and the exact job title may not matter. But if UX becomes a secondary responsibility across several roles, what happens to the opportunity to specialize in it, and what, if anything, might our products and processes lose as a result?

References and further reading

On the origins and scope of UX

• The Past, Present, and Future of User Experience (UX) Design, Don Norman, on why he introduced the term “user experience” and why he felt that “human interface and usability” were too narrow.

On UX and Agile

• Agile Isn’t Easy for UX, Nielsen Norman Group, on UX’s place in Scrum and the risk of designers being brought in after features and workflows have already been defined.
• The Scrum Guide, Ken Schwaber and Jeff Sutherland, on the roles, accountabilities and cross-functional structure defined by Scrum.
• The Professional Product Owner by Don McGreal and Ralph Jocham, on the Product Owner role in Scrum and the broad responsibilities around understanding customers, creating value and shaping product direction, including work that overlaps with traditional UX practice.

On product discovery and modern product practice

• Continuous Discovery Habits by Teresa Torres, on continuous discovery, product trios and involving Product, Design and Engineering in understanding customers and testing assumptions.
• Product Discovery, Marty Cagan, on product discovery as collaborative work involving customers, prototypes, testing and engineers.
• Product Management, Atlassian, on contemporary Product Management responsibilities, including its description of UX as one of a Product Manager’s core responsibilities.

On Product Management and developing product expertise

• STRONG Product People by Petra Wille, on developing Product Managers and the capabilities, responsibilities and organizational context of modern Product Management.

Has UX become everyone’s job but no one’s role? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.