Do not narrate the screen. State your recommendation, the reason or evidence behind it, the trade-off it creates, and the decision or input you need from the team.
If your design review starts with “So, on this screen we have…”, you may accidentally give everyone a guided museum tour before telling them what decision is on the table. A stronger meeting spine is: recommendation, evidence or reason, trade-off, ask.
The UX Decision Spine
- Recommendation: what are you proposing?
- Evidence or reason: why does it serve the goal?
- Trade-off: what does this option cost, weaken, or leave unresolved?
- Ask: what decision or input do you need now?
This changes the meeting from a Figma weather report into a decision conversation.
Lead with the recommendation
Instead of “Here we have the checkout page, and then over here…” try:
- “I recommend keeping the primary action at the bottom of the form.”
- “We’re proposing option B for the first release.”
- “My recommendation is to keep search visible rather than placing it behind the menu.”
Then explain why. Your teammates can inspect your reasoning much faster when they know the decision first.
Separate what you observed from what you recommend
UX English becomes risky when evidence and opinion are blended into one confident sentence. Keep three levels separate:
| Level | Example |
|---|---|
| Observation | “Several participants paused before finding the secondary action.” |
| Interpretation | “That suggests the hierarchy may not be clear enough.” |
| Recommendation | “So I recommend increasing the visual separation between the two actions.” |
Watch the overclaim
| Original | Classification | What a listener hears | More natural option |
|---|---|---|---|
| “Users prefer this.” | Context-dependent; potentially unsupported. | An empirical preference claim. | “In our sessions, several participants found X easier, so I recommend this option.” Use this only if that observation really exists. |
| “This is the best design.” | Grammatically valid but often overconfident. | Alternatives are objectively inferior. | “Given the current constraints, I recommend this option because…” |
| “I don’t like the other option.” | Valid but taste-centered and weakly diagnostic. | Personal preference is driving the decision. | “I’m less confident in the other option because it creates…” |
| “Development said we cannot.” | Context-dependent; may overstate a constraint. | The feasibility question is closed. | “Engineering flagged X as a constraint. Can we confirm whether that still applies?” |
Make the trade-off visible
A design recommendation sounds more credible when you can name what it does not optimize.
- “This makes the main action easier to find, but it uses more vertical space.”
- “Option B is simpler for the first release, although it gives us less flexibility later.”
- “This reduces visual density, but some secondary information becomes one tap deeper.”
You are not weakening your recommendation. You are showing that you can see the decision from more than one angle.
Handle pushback without defending every pixel
“Can we just make the button bigger?”
“We can. Before we change the size, can we check what problem we’re trying to solve—visibility, hierarchy, or tap target? The answer may lead to a different adjustment.”
“This will be expensive to build.”
“That changes the trade-off. If the implementation cost is high, I’d compare the simpler option against the user benefit we expect. Can we get a rough engineering estimate before we lock it?”
“I just don’t like this version.”
Do not defend blue’s honor. Move from taste to criterion: “What feels off to you—the hierarchy, the tone, the amount of information, or something else? That will help me understand what we should revisit.”
When the evidence is weak, keep the recommendation—but shrink the claim
You can recommend an option without pretending the evidence is stronger than it is.
- “This is our current hypothesis rather than a validated result.”
- “We saw this pattern in a small set of sessions, so I’d treat it as directional.”
- “We don’t have evidence on that point yet. My recommendation is based on the current product constraint.”
- “I’m comfortable recommending this for the test, but not calling it the final solution.”
Good meeting English makes uncertainty visible without making the recommendation disappear.
End with the decision you actually need
A beautifully explained rationale can still produce a useless meeting if nobody knows what happens next.
- “What I need today is agreement on which direction we prototype.”
- “Are we comfortable moving forward with option B for the test?”
- “Before I revise this, I need to know whether engineering considers X a hard constraint.”
- “I’m not asking for final approval yet. I need feedback on the hierarchy.”
Build your own Decision Spine
Choose one real design decision and say these four lines aloud:
- “I recommend…”
- “The main reason / evidence is…”
- “The trade-off is…”
- “What I need from the team today is…”
If line two contains “users think,” “users want,” or “research proves,” check whether your evidence truly supports that wording.
Five UX meeting role-plays
Answer before opening the model.
1. PM: “Why are you recommending option B?”
“I recommend B because it keeps the primary task visible without adding another decision step. The trade-off is less flexibility for secondary actions. For today, I’d like agreement on which option we prototype.”
2. Engineer: “This interaction may be expensive.”
“That could change the recommendation. The interaction solves X, but if the build cost is high, the simpler option may be the better trade-off. Could we get a rough estimate before we decide?”
3. Stakeholder: “Can you make everything bigger?”
“We can adjust the scale. Could I check what feels too small or hard to find? If the problem is hierarchy rather than size, I’d solve it differently.”
4. Research is suggestive, not conclusive. How do you present the recommendation?
“We saw a directional pattern rather than a conclusive result. Based on that and the current constraint, I recommend testing option A next rather than treating it as the final answer.”
5. Two options solve different risks. How do you avoid pretending one is simply ‘best’?
“Option A reduces complexity; option B preserves more flexibility. Given that our immediate risk is onboarding friction, I recommend A for this release. If extensibility becomes the priority, I’d revisit B.”
Practise your design decision out loud
If the Decision Spine makes sense on paper but disappears in meetings, rehearse it aloud. You can choose a speaking-practice path in FunFluen for general English speaking practice. This exact UX scenario is not promised to be preloaded.
Facilitate the decision; do not give a screen tour
Your job in the meeting is not to prove that every pixel is correct. Make the logic inspectable: recommendation, evidence or reason, trade-off, ask. Then let the team challenge the part that actually needs discussion.
For your next review, practise one real decision in 30 seconds. If you reach “and on this screen we also have…” before stating the ask, the museum tour has started again.
For more ways to turn real speech and media into language practice, explore media-based language learning.