Process: The Power of Naming Things

I was fixing a PHP script the other day, not exactly a designer's tool of choice, but sometimes you use what gets the job done. Frustrated, I took a break, and a podcast popped up: Milen Donev at Radiotochka 2 Podcast, ( Watch Here (Bulgarian Audio) ) talking about design and communication. He mentioned something that hit home: how mixed-up terms derail conversations.

And suddenly, I was back a few years ago, remembering a project where naming things: actually naming them - saved us from endless, circular meetings.

If you're part of any project that involves communication (so, all of them), try this. It requires a bit of "playing dumb" and some persistence. But it brings clarity, structure, and, best of all - it speeds things up.

Important note: This works best for internal communication: devs, designers, stakeholders. For end-user-facing terms, you still need to prioritize what feels natural to users, even if it's inconsistent with your internal naming.

The Stage

A few years ago, I was designing a web app for customer support centers. As the team grew, so did the meetings. Discussions stretched longer, progress slowed, and I found myself in a silent contest with the lead developer to see who could make meetings shorter. (Spoiler: He won. He's terrifyingly efficient.)

The Problem

I started noticing how different people used the same words to mean different things.

1. A "component" in Figma wasn't the same as a React "component."
2. A "section" in stakeholder talks had a different name in Figma and yet another in the dev docs.

Every time, we'd either waste minutes clarifying or worse - leave with different understandings, only to circle back later.

The worst part? These weren't even hard problems. They were just miscommunications disguised as complexity.

The Solution

I decided: If no one else was going to own the names, I would.

So I started naming things. And not just in my head; I made it a rule.

Example:

1. Someone says, "The cog menu..."
2. I'd interrupt: "Wait, the cog menu? You mean the Settings Menu?"
3. "Yeah, the one with the settings..."
4. "Got it. Let's call it the Settings Menu from now on. It'll save us time."

But here's the catch: This only applies to internal terms. For anything user-facing, you still need to use the language they understand, even if it's inconsistent with your internal naming. This is especially true for localizations, where terms might need to adapt to cultural contexts, language nuances, or regional expectations. For example, "Settings Menu" might work in English, but in other languages, the natural term could be completely different, and your internal naming should never override these user-facing adaptations.

At first, it felt awkward. I had to "play dumb" a lot "What do you mean by 'feature A'?" but it worked. Over a few weeks, the team and stakeholders got used to it. Meetings got shorter. Questions shifted from "What do you mean?" to "How should we handle the Settings Menu?"

I still had to correct people occasionally, but it became rare. And the best part? No one ever complained. In fact, everyone who's tried this approach has found it useful. It frees up mental space to focus on the actual problem, not the words we're using to describe it.

How to Do It

1. Name everything. Menus, features, sections - pick a term and stick to it. (But only for internal communication!)
2. Own the names. If someone uses a different term, gently correct them. "Oh, you mean the User Profile Card?"
3. Be flexible. If the team prefers a different name, use that. The goal is consistency, not control.
4. Play dumb. If something's unclear, ask. "Wait, what do you mean by 'the left panel'?" It's not about being difficult, it's about clarity.
5. Call a Naming Meeting for ambiguous terms. Get everyone aligned and document the decisions.
6. Map your terms. Keep a simple table in your design system or wiki showing internal vs. user-facing names. This ensures everyone knows which term to use and when.

Why It Works

1. Less confusion: No more "Wait, which menu?" moments.
2. Shorter meetings: Fewer clarifications, more progress.
3. Better documentation: When everyone uses the same terms, docs stay consistent.
4. Mental bandwidth: You spend less time translating and more time solving.

But remember: This doesn't apply to user-facing terms. Users don't care what you call things internally: they care about what makes sense to them. So keep your internal naming consistent, but always prioritize user-friendly language in the actual product, especially when localizing for different markets.

Handling Edge Cases

Sometimes, you'll encounter terms that are too ambiguous or too important to resolve casually. For example, a single word might refer to completely different things depending on the context: admin tools, user views, analytics, or system monitoring.

When this happens, call a Naming Meeting with the whole team or just leads, depending on team size.

How to do it:

1. Explain the problem: "We're using [term] to mean multiple things. This is causing confusion."
2. List the contexts: Identify all the different ways the term is being used.
3. Agree on specific names: Assign a unique, clear name to each context.
4. Document it: Add the agreed terms to your shared glossary or design system.

When to call a Naming Meeting:

1. The term is used in 2+ different ways across teams.
2. Confusion about the term has blocked progress (e.g., a bug or delayed decision).
3. You have identified 3+ meetings, where time was spent on clarifying the term.

This approach ensures everyone is on the same page and prevents future misunderstandings.

A Reminder

This isn't about being pedantic. It's about removing friction so the real work can happen. This isn’t about replacing efficiency. It’s about adding clarity where ambiguity slows things down. Use both: name things and keep meetings ruthlessly short.

And if you're wondering... yes, it did speed up my meetings. But no, I didn't win the "shortest meeting" contest. The dev lead is still the reigning champion. (Some battles aren't meant to be won.)

Final Thought

Use this as I describe it, tweak it, or ignore it. But know this: There's a simple way to fix jumbled communication. Just name things. Own the names. And when things get ambiguous, call a Naming Meeting.

Now, back to designing. (And yes, the PHP script is finally behind me.)