I enjoy talking shop with fellow UX professionals. There’s always an interesting problem to solve and new ideas to be explored. User experience work is dang interesting. Plus, UX folks are smart. I nearly always learn something new from them.

When UX people talk, we speak in shorthand, jargon flying fast and furious. “Hey Dean, did you incorporate user-led personas into the user stories for sprint two?” “Well, my fellow information architect, it was the journeys and exploration studies that actually made the difference to the user flow.” “But Dean, what about the EPS Conduits and the Flux Capacitor?” None of this has to be explained. I’m sure you, my fellow UX enthusiast, follow it just fine.

But what about real people?

Few outside the rarified air of the UX ivory tower have much idea what we’re talking about. It’s lost on stakeholders, leaders, influencers, and clients. They don’t know Balsamiq from Axure. They are decidedly fuzzy on the difference between wireframes, prototypes, visual design files, storyboards, and sketches. Should we blame them?

Welcome to UX irony.

On one hand, user experience is a ho-hum buzzword, something every commodity web design shop claims. On the other hand, UX is still relatively new and the discipline can seem quite mysterious, especially to those in the development world.

It doesn’t help matters that UX pros employ a dizzying variety of tools, methods, and deliverables. It also doesn’t help when we sometimes use words that can mean different things. What precisely is a template? How about widget? Snippet? Component? Archetype? And what on earth is a UX requirement?

We preach the use of simple, clear, human language for users. We demand others keep things simple, basic, and understandable. Then we turn around and lay the doublespeak on thick.

What can you do?

The answer is beautifully simple. Let’s practice what we preach.

Kill the jargon.

When interacting with stakeholders, traditional team members, managers, or clients, banish techno-slang and explain things in mercifully clear, brief, plainspoken language.

Don’t assume understanding.

Do not assume any UX deliverable, tool, or process is inherently understood. Do not assume they are understood the second or third time you mention them.

Show. Don’t tell.

Show examples of deliverables. Showing fosters understanding. I have not yet met a client or stakeholder who really understood anything until they looked right at it. You are trying to convince highly literal people. They don’t know what you mean with your abstract explanations and generic sketches.

This is why you should always show real things. For example, when presenting wireframes, design, or finished code, make sure all content and copy are real. Anything less will come back to bite you later.

Be simple.

Every sub-discipline or sub-culture has its own lingo. But your command of esoteric terms will impress exactly no one. You know what people want from you? They want a great, easy-to-use digital product. Let’s stick to that and dispense with the fancy talk. It will make your life (and theirs) far easier.