Unlock Misunderstandings at Work

I was in a meeting at a large financial company when I casually mentioned "testing the design with users." Before I could finish my sentence, the lead architect snapped: "No one cares about what it looks like."

The room went silent. Some of my teammates jumped to my defense with a quick "not cool, man", but I stayed curious instead of defensive. I kept the conversation going because I was genuinely confused about why this suggestion had triggered such hostility.

It took weeks of working together to figure out what had actually happened in that meeting. The word "testing" meant something completely different to him than it did to me. To engineers, testing means automated tests: pass or fail checkpoints that code must clear before moving forward. To designers, testing means putting prototypes in front of actual humans to see what makes sense and what doesn't. Same word, entirely different universes of meaning.

We weren't disagreeing about process. We were speaking different languages while using identical vocabulary.

This kind of terminology confusion doesn't just create awkward meetings. It kills entire projects. My team once spent a month in meetings with another team arguing about design system components. They kept insisting they needed a style for "alerts" while we kept insisting we already had one, except we called them "notifications." Same exact functionality, different terminology, weeks of frustration that could have been avoided with thirty minutes of shared vocabulary mapping.

Think about how much time your team has wasted in similar arguments. How many meetings have devolved into definitional debates about whether something is a "dashboard" or a "control panel," whether users have "accounts" or "profiles," whether actions are "saved" or "submitted"? These aren't philosophical disputes, they're communication failures that masquerade as disagreements about substance.

The problem compounds when you're working across disciplines. Product managers talk about "features." Engineers talk about "components." Designers talk about "patterns." Marketing talks about "experiences." Everyone thinks they're describing the same system, but they're actually mapping completely different territories using overlapping terminology.

I learned to solve this through something called noun foraging, which is exactly what it sounds like. When I start a new project, I comb through whatever documentation exists and hunt for the nouns that appear repeatedly. Website copy, case study transcripts, onboarding materials, anything with text. I'm not looking for adjectives or action verbs (yet), just the core objects that make up the system everyone's trying to build.

Then I bring that list of nouns I found to a workshop where we map them visually using colored sticky notes. Blue for concrete objects like "user" or "transaction." Yellow for proper nouns like "PayPal" or "Google." Green for actions like "save" or "submit." Pink for qualities like "urgent" or "archived."

The color-coding forces everyone to be explicit before any work begins. When someone says "users can save their preferences," we highlight "users" in blue, "save" in green, and "preferences" in blue. Immediately, questions surface: Who qualifies as a user? What exactly counts as preferences? Who can see them? This simple exercise prevents the expensive miscommunications that typically emerge weeks into development when fixing them costs actual money and burns through everyone's patience.

Most importantly, it removes ego from the equation. Nobody feels stupid for not understanding what a colleague meant, because everyone acknowledges that defining shared language is just good practice. It's systematic rather than personal. The problem isn't that someone used the wrong term, it's that we never agreed on terms in the first place.

This matters because most workplace conflicts aren't actually about fundamental disagreements. They're about people using different words for identical concepts, then defending their terminology choices like they're defending their professional competence. When you realize the engineer who said "no one cares about what it looks like" actually meant "we need to test functionality before we test design," the hostility evaporates.

The real tragedy is how much time we waste not just in meetings, but in rework. Designers create screens based on their understanding of what "customer" means, only to discover three weeks later that engineering built a database structure for "account holders" which is technically different. Product managers write requirements for a "notification system" while the design team builds a "messaging framework" and everyone's surprised when they don't align.

One hour of noun mapping at the beginning of a project prevents months of nonsense and misunderstandings. But most teams skip this step because it feels too basic, too obvious, or maybe they think they have better things to do. Everyone assumes they already share a common understanding. They're wrong, but they won't discover they're wrong until they've already wasted considerable time and goodwill.

So here's what I've learned: the next time you're in a meeting and someone's pushback seems unreasonable, pause and check if you're actually speaking the same language. Ask them what they mean by the specific terms they're using. Share what those terms mean to you. Get visual about it if you need to: write the words down, color-code them, make sure everyone's pointing at the same thing.

Most conflicts aren't conflicts at all. They're just expensive misunderstandings that could have been prevented by one intentional conversation about what words actually mean.

​

​

---