Most product designers have strong general English. But they still hit one specific wall. The words for defending a design decision are different from the words for 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. The precise word for what you confirmed doesn't come to you -- you just feel that "it works." The gap isn't a design-skill problem. It's a specific, learnable set of words. Non-design stakeholders expect you to use these words precisely.
This isn't a grammar problem. It isn't about how many words you know, either. Below, the words are grouped by the situation you're actually in, not listed from A to Z.
Confirming you're solving the right problem
Outside design, people often use one pair of words as if they mean the same thing. Mixing them up changes what a stakeholder thinks you've confirmed.
To validate is to confirm you're building the right thing -- that the problem and the 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. Presenting one as the other gives a false picture of how far along the work really is.
Design theory that shapes a critique
Two pairs from core design theory give you sharper words for a critique than just "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. That's a specific, nameable problem -- not just "confusing." A heuristic is a rule of thumb for judging a design. A guideline is a stricter, more specific rule. Saying "This violates a usability heuristic" is a sharper critique than saying "this violates a guideline," because it shows you're using judgment, not just checking a box.
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 →Talking about what breaks
One subtle distinction matters here. It affects how much edge-case handling a feature actually needs.
An edge case happens when one setting hits an extreme value. A corner case happens when several settings hit extreme values at once. If you treat a corner case like a common edge case, you may over-engineer for something that's actually far rarer than it sounds.
Defending a design decision
One choice of framing changes how a stakeholder hears the exact same limitation.
A constraint is a deliberate boundary the design works within -- a business rule or technical limit, chosen on purpose. A limitation suggests a shortcoming, something the design falls short of. "This is a constraint of the platform" sounds very different from "this is a limitation of the design," even though both describe the exact same fact.
Removing extra difficulty and changing direction based on evidence are two ideas 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 words are jargon for its own sake. Each one carries a specific, clear meaning. It changes what a stakeholder understands about your process and your confidence. Saying "validate" instead of "verify" -- or the reverse -- misstates what stage the work is really at. Saying "constraint" instead of "limitation" changes how a decision lands, without changing the real fact. Most non-native product designers already know these words. The real problem is picking the right one live, in a review. They default to a vaguer word that says less than the work supports.
Deliberate practice builds exactly this kind of precision. Lyra Practice uses workplace scenarios like the ones above -- design reviews, critique sessions, defending decisions -- and gives feedback on whether the word you chose actually fits.
Frequently Asked Questions
What is business English for product designers?
It's the specific vocabulary product designers use to explain process and decisions to stakeholders. That includes confirming direction, applying design theory in a critique, scoping edge cases, and framing limitations. It's separate from the visual or interaction-design vocabulary itself. Words like validate, affordance, and constraint carry precise meanings worth learning on purpose.
What vocabulary do product designers actually need at work?
Based on real design-review situations, the most useful words fall into four areas. Confirmation language covers validate vs. verify. Critique language covers affordance vs. signifier and heuristic vs. guideline. Scoping language covers edge case vs. corner case. Framing language covers constraint vs. limitation. These come up constantly in reviews and in talks with stakeholders.
How is this different from general UX vocabulary?
General UX resources tend to teach basic terms like wireframe and prototype. Those are aimed at people new to the field. This is more advanced. It's about the specific word choices experienced designers use to communicate clearly with stakeholders, not the vocabulary of the craft itself.