A shared vocabulary across the product trio is a coordination technology: when PM, design, and engineering agree on one canonical name per concept, they stop paying a "translation tax" on every handoff. The fix is a lightweight, living glossary plus a naming review step in your existing rituals — not a governance committee.
Quick answer: Naming problems cause rework because ambiguous terms let three people build three different things while believing they agreed. Fix it with a shared glossary (borrowed from Domain-Driven Design's "ubiquitous language"), a naming review at design and spec handoff, and one canonical name that survives from the UI to the database schema.
Why Naming Is a Coordination Problem, Not a Semantics Problem
Naming disagreements feel trivial, so teams under-invest in solving them, but the cost shows up as rework, not as a philosophical debate. When a PM writes "popup" in a spec, a designer builds a "dialog" component, and an engineer implements a "modal" class, three people can walk out of the same meeting confident they aligned — and be wrong.
Eric Evans named this class of problem in Domain-Driven Design (2003), where he introduced the concept of a ubiquitous language: a vocabulary shared by domain experts and engineers, used consistently in conversation, documentation, and code. Evans's core claim was that the language isn't a communication nicety layered on top of the "real" work — the language is the model, and inconsistency in it is a signal of inconsistency in everyone's mental model.
The trio setup makes this worse than a two-person handoff because there are three translation points instead of one:
- PM to design: requirements language ("users should confirm before deleting") becomes UI language ("a confirmation modal").
- Design to engineering: UI language becomes component and API language ("the
Dialogcomponent with adestructivevariant"). - Engineering to PM: implementation language ("we added a
ConfirmationOverlayservice") gets reported back in terms the PM has to re-translate into product language.
Each translation point is a place where meaning can drift, and drift compounds. A related, well-documented cost is what researchers call coordination neglect — the tendency for interdependent teams to under-communicate about how their work fits together, described by Michael Cohen and colleagues studying organizational coordination failures. Naming inconsistency is coordination neglect made literal: it's the artifact you can point to and say, "here is where our models diverged."
The Modal-Dialog-Popup Case: What Ambiguity Actually Costs
A concrete naming mismatch — one team's "modal" is another's "dialog" is another's "popup" — routinely causes real rework because each term implies different behavior, not just different labels. This isn't a semantic quibble; the words encode assumptions about dismissal, stacking, focus trapping, and urgency that never get stated out loud.
Here's a pattern that plays out on real teams. A PM writes a spec: "show a popup asking the user to confirm the export." The word "popup" carries no implied behavior in the PM's head — it just means "a small thing appears." But to the engineer, "popup" often maps to a non-modal, dismissible-by-click-outside pattern, because that's the browser-native connotation carried over from window.open and toast-style popups. Meanwhile, the designer, working from a component library, builds the flow using the library's Dialog component, which is modal — it blocks the page, traps focus, and requires an explicit action to dismiss.
| Term used | Implied behavior (common assumption) | Who usually assumes it |
|---|---|---|
| "Popup" | Transient, dismissible by clicking away, non-blocking | PMs, casual spec language |
| "Modal" | Blocks the page, traps keyboard focus, requires explicit dismissal | Engineers, accessibility-focused design |
| "Dialog" | A modal with a specific accessibility contract (ARIA role="dialog", focus return) | Design systems teams, WCAG-literate engineers |
| "Overlay" | Any full-screen layer — could be modal or not | Whoever wrote the CSS class name first |
When these three people build from three different mental models of the same word, the review meeting surfaces the mismatch late — often after a build. The PM asks why users can dismiss a destructive action by clicking outside it; the engineer points out that's what "popup" implies; the designer points out the component they used was never meant to be dismissible that way. The rework isn't a UI tweak — it's a re-litigation of intent that could have taken two minutes in a glossary review instead of a full sprint of rebuild.
Nielsen Norman Group's research on modal and nonmodal dialogs makes a related point directly: the interaction-design literature treats "modal" as a precise technical term with accessibility and focus-management consequences, not a style choice — which is exactly why using it loosely is expensive. Precision in naming isn't pedantry; it's a proxy for precision in the actual behavior being specified.
Building a Lightweight Glossary That People Actually Use
A working glossary is a short, living document — not an exhaustive dictionary — that captures the terms your trio disagrees on most, with one canonical name, a definition, and a link to where it's implemented. The goal is coverage of your actual friction points, not completeness.
What Belongs in the Glossary
Don't try to name everything. Start with the terms that have already caused a disagreement or a rebuild — those are your highest-value entries. A minimal glossary entry needs four things:
- Canonical term — the one word everyone agrees to use, chosen deliberately (often matching the design system's component name, since that's the artifact that's hardest to rename later).
- Definition — one or two sentences, written in plain language, not implementation detail.
- Non-examples — the near-miss terms people reach for instead ("not: popup, overlay, lightbox"), which is often more useful than the definition itself.
- Canonical source — a link to the component in the design system, the entity in the data model, or the section of the spec where it's authoritative.
| Field | Example entry |
|---|---|
| Canonical term | Dialog |
| Definition | A modal surface that interrupts the current task, traps focus, and requires explicit dismissal. |
| Non-examples | Not: popup, modal window, overlay, lightbox |
| Canonical source | Design system Dialog component; DB entity notification_dialogs |
| Owner | Design systems lead |
A glossary that lives in a wiki no one opens will decay within a quarter. It works better attached to the artifacts people already touch — a glossary section inside your design tokens documentation (see our guide to design tokens explained for PMs for how tokens and naming reinforce each other), or a TERMS.md file next to the component library, referenced from PR templates.
Naming Reviews: A Five-Minute Ritual, Not a Meeting
The highest-leverage fix isn't the glossary itself — it's a habit of checking new terms against it before they spread. A naming review adds almost no overhead if it's attached to a step that already exists, rather than scheduled separately.
Three places to attach it:
- At spec review: when a PM writes a new noun in a PRD, a reviewer's job includes asking "does this term already exist in the glossary under a different name?"
- At design critique: designers flag when a new component name is being introduced instead of reusing an existing pattern — this is where component naming discipline (see component API thinking for PMs) intersects directly with vocabulary discipline, since a component's name is a vocabulary decision.
- At PR review: engineers flag when a new database column, API field, or class name doesn't match the term used in the spec or the design file.
None of these require a new meeting. They require a habit, and habits are built by making the check a checklist item on a template you already use, not a new process people have to remember to run.
Borrowing Ubiquitous Language From Domain-Driven Design
Evans's ubiquitous language concept transfers to product trios almost without modification, because the underlying claim — that language precision and model precision are the same problem — doesn't care whether the "domain experts" are accountants or product managers. The DDD literature gives you three transferable disciplines worth adopting deliberately.
First, the language belongs in the code, not just the conversation. Evans argued that when the business calls something an "Order" and the engineers implement a PurchaseRequest class, the naming gap becomes a permanent translation cost embedded in the codebase. The trio equivalent: if the PRD says "workspace" and the database schema says tenant_id, every future engineer has to hold two names in their head to understand one concept.
Second, the language evolves through conversation, not decree. DDD explicitly rejects a top-down glossary imposed by an architect — the vocabulary is supposed to emerge from modeling sessions where domain experts and engineers argue out loud until a term sticks. For a trio, this means the naming review should surface disagreements, not just enforce a pre-existing list; the list should be updated when a real disagreement resolves.
Third, bounded contexts are allowed to have different vocabularies — as long as the boundary is explicit. This is the part teams most often skip. It's fine for "customer" to mean something narrower in the billing system than in the CRM, if everyone agrees where that boundary is and translates deliberately at the seam. The failure mode isn't different vocabularies existing — it's different vocabularies existing invisibly, with no one flagging the seam.
This last point matters for cross-functional teams especially, since the product trio's shared vocabulary often has to interface with adjacent teams' vocabularies — support, sales, and marketing frequently have their own names for the same underlying concept, echoing the customer-journey mapping work in our complete guide to customer journeys, where a single customer moment gets named differently by every function that touches it.
Where Naming Discipline Breaks Down in Practice
Naming discipline degrades in three predictable places: at scale (more people, more surface area for drift), at handoff (the seams between PM, design, and eng), and at legacy (terms that were fine at 10 users and became load-bearing lies at 10,000). Recognizing the pattern is most of the fix.
Scale: More People, More Silent Drift
A five-person team can hold a shared vocabulary in their heads without writing anything down — the naming review happens implicitly, in Slack threads and hallway conversations. That stops working somewhere between 15 and 40 people, not because anyone got careless, but because no single conversation reaches everyone anymore. This is the same scaling curve that makes design systems worth building in the first place — a glossary is, in effect, the vocabulary layer of a design system, and it should be versioned and reviewed with the same seriousness as component APIs.
Handoff: The Seams Between Trio Members
Most naming drift doesn't happen within a discipline — it happens at the boundary between disciplines, which is exactly why the product trio operating model treats shared artifacts (not shared meetings) as the primary coordination mechanism. A term that's precise inside engineering's head (a Session object with a specific TTL) can travel into a PM's spec as "login," losing the precision that made it useful, and then travel into design as a screen state that doesn't map to either.
Legacy: Terms That Outlive Their Accuracy
Every team has at least one term that made sense once and is now actively misleading — a feature called "Beta" that shipped three years ago, a table called temp_users that's now load-bearing production data. These aren't naming mistakes at the time they were made; they're naming debt that accrued as the product changed underneath a name that didn't. Treating a glossary as living means scheduling an occasional pass to retire or rename these terms, the same way you'd schedule tech debt cleanup — deliberately, not never.
Naming as a Discipline That Reaches the Database
The naming discipline that starts in a PRD and a Figma file has to survive all the way into the schema, or the translation cost just relocates downstream instead of disappearing. This is the step teams skip most often: they'll align on "Dialog" in design and spec, then let engineering independently choose modal_events, overlay_log, or popup_interactions as the table name, quietly reintroducing the exact ambiguity the glossary was built to kill.
The broader point holds independent of any specific tool: naming discipline is only as strong as its weakest link, and the database is usually the least-visible link, which makes it the one most worth checking deliberately.
Key Takeaways
- Naming is a coordination technology. A shared vocabulary reduces the translation cost paid at every handoff between PM, design, and engineering — it isn't a cosmetic concern.
- Borrow "ubiquitous language" from Domain-Driven Design. Eric Evans's core insight — that language precision and model precision are the same problem — transfers directly to product trios.
- Start the glossary with your actual friction points, not an exhaustive list: canonical term, definition, non-examples, and a canonical source for each entry.
- Attach naming review to rituals you already run — spec review, design critique, PR review — rather than scheduling a new meeting no one will protect.
- Ambiguous terms like "modal," "dialog," and "popup" imply different behavior, not just different labels, which is why loose usage causes real rework, not just confusion.
- Let the vocabulary evolve through conversation, and allow explicit bounded contexts — different vocabularies are fine as long as the seam is visible.
- Carry the canonical name all the way to the database schema — the least-visible layer is often where naming discipline quietly breaks down.
Frequently Asked Questions
What is a design system naming convention, and why does it matter beyond design?
A design system naming convention is the agreed set of canonical names for components, states, and patterns, documented once and reused everywhere. It matters beyond design because engineering and product both depend on those names to avoid re-deriving meaning independently, which is where costly mismatches like modal-versus-dialog originate.
How do you build a shared vocabulary across product, design, and engineering without adding process overhead?
Attach a naming check to a step each discipline already performs — spec review for PM, critique for design, PR review for engineering — rather than creating a new meeting. Combine this with a short glossary (four fields per term: canonical name, definition, non-examples, canonical source) kept next to artifacts people already open, like the design system docs or a TERMS.md file in the repo.
What is "ubiquitous language" and where does the term come from?
Ubiquitous language is a term coined by Eric Evans in his 2003 book Domain-Driven Design, describing a vocabulary shared consistently between domain experts and engineers in conversation, documentation, and code. Its core claim, borrowed directly for product trios, is that inconsistent naming is a symptom of inconsistent mental models, not a separate cosmetic problem.
How do you fix recurring miscommunication caused by naming when the team is already mid-project?
Audit your specs, Figma files, and codebase for the two or three terms that have already caused a rebuild or a confused review meeting, and resolve just those first rather than attempting a full glossary in one pass. Add a canonical-source link for each resolved term so future disagreements can be settled by pointing at an artifact instead of re-arguing from memory.
Does a shared vocabulary need to be identical across every team, or can different teams use different terms?
Different teams can legitimately use different vocabularies for the same underlying concept, as long as the boundary between those vocabularies is explicit and someone owns translating across it. The failure mode Domain-Driven Design warns against isn't multiple vocabularies existing — it's multiple vocabularies existing invisibly, with no one aware a translation is even happening.