Most product designers who are strong in general English still hit a specific wall: the vocabulary of defending a design decision is different from the vocabulary of making one.
You can run a usability test. You can iterate on a flow and ship a polished interface. Then you're in a design review, and the precise word for what you actually confirmed -- not just a general sense of "it works" -- doesn't arrive. The gap isn't design skill. It's a specific, learnable set of words. Non-design stakeholders expect you to use them precisely.
This is not a grammar problem, and it's not a vocabulary-size problem. Below, the words are organized by the situation you're actually in, not alphabetically.
Confirming you're solving the right problem
One pair gets used almost interchangeably outside design, and the confusion genuinely changes what a stakeholder thinks you've actually confirmed.
To validate is to confirm you're building the right thing -- that the problem and solution direction are correct. To verify is to confirm you're building the thing right -- that it works as specified. "We validated the concept" and "we verified the implementation" are different claims, at different stages, and presenting one as the other misrepresents how far along the work actually is.
Design theory that shapes a critique
Two pairs from core design theory give you a more precise vocabulary for a critique than "this isn't clear."
An affordance is what an object can actually do. A signifier is the visual cue that tells the user how to do it. A button that looks clickable but isn't has a signifier without the affordance -- a specific, nameable problem, not just "confusing." A heuristic is a rule of thumb used to evaluate a design. A guideline is a more prescriptive rule. "This violates a usability heuristic" is a more precise critique than "this violates a guideline," because it signals you're applying judgment, not just checking a box.
Talking about what breaks
A subtle distinction matters when scoping how much edge-case handling a feature actually needs.
Understanding is only the first step.
Lyra Practice helps you retrieve and use high-value workplace expressions in realistic situations until they feel natural.
Start a practice session →An edge case involves one parameter at an extreme value. A corner case involves multiple parameters at extreme values simultaneously. Treating a corner case as if it were a more common edge case can lead to over-engineering for a scenario that's actually far rarer than it sounds.
Defending a design decision
One framing distinction changes how a stakeholder receives the same underlying limitation.
A constraint is a deliberate boundary the design works within -- a business rule, a technical limit, chosen on purpose. A limitation implies a shortcoming, something the design falls short of. "This is a constraint of the platform" reads very differently from "this is a limitation of the design" -- even when describing the exact same fact.
Removing unnecessary difficulty and changing direction based on evidence are both concepts Lyra already teaches precisely: What Does "Friction" Mean at Work? and What Does "Pivot" Mean at Work?.
Why this vocabulary is worth learning deliberately
None of these are jargon in the empty sense. Each one carries a specific, checkable meaning. It changes what a stakeholder understands about your process and confidence. Saying "validate" instead of "verify" -- or the reverse -- misrepresents what stage the work is actually at. Saying "constraint" instead of "limitation" changes how a decision is received, without changing the underlying fact. Most non-native product designers already know these words exist. The real problem is choosing the precise one live, in a review -- so they default to a vaguer word that says less than the work actually supports.
That precision is exactly what deliberate practice builds. Lyra Practice is built around workplace scenarios like the ones above -- design reviews, critique sessions, and defending decisions -- with feedback on whether the word you chose actually fits.
Frequently Asked Questions
What is business English for product designers?
It's the specific vocabulary used when product designers communicate process and decisions to stakeholders -- confirming direction, applying design theory in a critique, scoping edge cases, and framing limitations -- as distinct from the visual or interaction-design vocabulary itself. Words like validate, affordance, and constraint carry precise meanings worth learning deliberately.
What vocabulary do product designers actually need at work?
Based on real design-review situations, the highest-leverage set covers four areas: confirmation language (validate vs. verify), critique language (affordance vs. signifier, heuristic vs. guideline), scoping language (edge case vs. corner case), and framing language (constraint vs. limitation). These come up constantly in reviews and stakeholder conversations.
How is this different from general UX vocabulary?
General UX resources tend to teach basic terminology -- wireframe, prototype -- aimed at people new to the field. This is more advanced: the specific word choices experienced designers use to communicate precisely with stakeholders, not the vocabulary of the craft itself.