UX is Not a Shared Service

Whenever I hear someone describe UX as a shared service, I cringe.

Kinda like this:

It’s more than a pet peeve, it’s a red flag. It's a sign that something is fundamentally off in how UX is positioned, described, and integrated into the work of developing products.

It’s become a running joke on my team that this label sets my teeth on edge. But my aversion isn’t just about being picky with words. It’s because language like this, subtle as it may seem, contributes to the marginalization of UX.

Let’s break it down.

UX Isn’t a Shared Service. It's a Core Product Function.

UX is not a shared service. It’s not structured that way, and it shouldn’t be treated that way.

Just like Product Management and Engineering, UX is aligned functionally. PMs report to the CPO. Engineers report to the CTO. UX professionals report to... the Head of Design. (Ahem.)

Together, these three functions make up the product trio. Each one represents a vital lens for building great products:

• PM brings the business goals

• ENG brings the technical feasibility

• UX brings the user needs

These teams work together in cross-functional product teams, not as resources to be loaned out on demand. So why is UX the only one in the trio that gets slapped with the “shared service” label?

If PM and ENG aren’t labeled this way, UX shouldn’t be either.

Why the Label Matters

You might be thinking: “Okay, but does this really matter?”

Yes. It does. Because words reflect mindset.

When someone refers to UX as a shared service, it’s often a sign that UX is treated as a support function instead of a strategic partner. It usually means the team is brought in too late, excluded from key decisions, or siloed from the broader product conversation.

And in this case, it’s not just an inaccurate label, it’s a limiting one.

When Shared Services Are Real (and Useful)

To be fair, there are teams that truly operate as shared services. I work with several today and I deeply value what they bring.

For example:

• Our Design System team supports dozens of other teams by building and maintaining reusable components, rules, and guidelines.

• Our Technical Writing, Localization, Accessibility, and Content Design teams all operate in similar models today: providing focused expertise across a wide range of product efforts.

(Do I wish more of these roles could be embedded directly into product teams instead? Yes. Yes, I do. But that’s a resourcing topic for another post.)

Engineering has shared services too:

• Security Engineering

• DevOps / SRE

• Infrastructure, and more...

  
  

These are true shared services, and they’re critical.

So it’s not that the shared service model is inherently bad. In many cases, it’s the right way to scale specialized expertise. What is a problem is using the label inaccurately.

Let’s Call It What It Is: Shared Expertise

Even for teams that do operate in a shared model, I still wince at the term “shared service.” There’s something about it that feels transactional, like we’re ordering design off a menu.

These teams aren’t just “services.” They’re hubs of deep knowledge. Strategic contributors. Partners.

In my team, I’ve started calling them Shared Expertise Teams instead. It’s a small shift in language, but it better reflects the value they bring.

What Do You Think?

Does the “shared service” label rub you the wrong way too? Have you found better language for teams that operate in this model?

I’d love to hear your take, especially if you’ve found ways to reframe and reposition UX or other functions for greater impact.