Here’s a conversation I was party to earlier today, between the VP of Product and an in-house UX lead:

UX: “So what we really need to do is institute DesignOps. We need to put together a DesignOps strategy.”

VP: “A what strategy?”

UX: “DesignOps.”

VP: “What the hell is ‘DesignOps?’”

UX: “It means we need to work more efficiently, to cut down the time between design and deployment, work to remove the friction along the way that keeps us from doing that now. Setting up tools, process and infrastructure to help us ensure that the launched product actually meets user and business needs. Gets us the outcomes we want.”

VP: “Then why the hell didn’t you just say THAT?”

For an industry supposedly dedicated to clarity, simplicity, usefulness and communication, we spend an awful lot of time trying to complicate what we do. Mainly by coming up with complex, official-sounding names for every possible activity or process or artifact.

That’s insecurity, a weapon created and drawn for what we perceive to be a fight for legitimacy.
If we give it a fancy name, it’s now a “thing” that can’t be ignored, right?

Every month or so, I see another term, another name, another attempt to reframe the core principles or processes behind building a useful, usable, valuable product as something new and innovative.

Another collection of syllables that essentially means what we already know: that people in different disciplines need to communicate and collaborate more effectively. And that this becomes more important (and more difficult) as an organization and its product team grows.

And I think: same sh*t, different name.

These things are positioned as ways to clear the air, to standardize, to somehow magically get everyone rowing in the same direction. To increase understanding and, by doing so, gain acceptance of our value as UXers or Designers, to the team and the organization.

By naming these concepts, the thinking goes, we somehow make them more accessible, more shareable and understandable to people across the organization and in related disciplines. To close the distance between “us” and “them.”

Except that’s not what happens.

This terminology obsession of ours actually widens the distance between us and everyone else — from execs to managers to development to IT — because they don’t know what the f*ck we’re talking about.

Have I been guilty of this myself in the past? Absolutely. But I’m at a point in my life and career where my experiences with my clients and their product teams have forced me to recognize — with crystal clarity — that this needs to stop. Now.

Because more often than not, all we’re doing is creating yet another term that people have to add to their “need to find out what the f*ck this means” list of terms. What I see inside organizations almost daily is the equivalent of having to study for an ever-expanding vocabulary test.

No one admits this in public, mind you. When these terms pop up in meetings or conversation, most people pretend to know what they mean. But everyone is afraid to say so.  I know that because these are the conversations I have during breaks, where a line of people are waiting to pull me off to a corner and share their frustrations and fears.

Look, I’ll make this simple:

If you have to expend 70% of your brainpower simply staying on top of all this UX terminology, you don’t have a whole lot left for actually thinking through hard problems — or actually doing the work at hand.

So enough with the names already.

I’m looking at you, DesignOps, DevOps, Design Language Systems, Service Design, Service Design Thinking, Design Systems Thinking, Semantic Design, Experience Architecture, Confidence Intervals, Hierarchical Task Analysis, Prominence-Interpretation Theory, Prioritization Matrices, Empathy Gap Analysis, Polyhierarchies, IoT Experiences, Digital Governance, Disruptive Interface Design, Extended Reality Design, Humane Product Design, User Assistance Design, Machine Ethnography…I could do this all day, folks.

Just stop this. Stop creating UX terminology and stop using it.

It’s not helping anything.

Instead, speak plainly. Clearly. Simply.

Spend a lot less time trying to legitimize what you do, less effort trying to convince other people of its importance — and more time actually doing the work.