UX review presentations
How do you create compelling presentations that wow your colleagues and impress your managers? Here is how to get started.
Olivia Rhye
20 Jan 2027
A good review does two things at once: it shows the work, and it shows the thinking behind the work. Most decks only manage the first. Here is the structure we use to do both without doubling the length.
Introduction
Every review starts from the same place: the people in the room did not watch the work happen. They arrive with their own context, their own deadlines, and about four minutes of patience. The job of the first slide is to give them a reason to spend the next twenty.
So we open with the decision rather than the process. What are we asking for, what changes if we get it, and what happens if we do nothing. Everything after that slide exists to support the answer.
Sequence matters more than polish. When a reviewer can predict what comes next they stop bracing for surprises and start giving you real feedback, which is the only thing the meeting was ever for.
The best review we ever ran lasted eleven minutes. We had answered every objection on the slide before anyone had to raise it.
Olivia Rhye
Product DesignerWrite the objections down first. Ask the two people most likely to disagree what they would push back on, put those answers in the deck, and credit them by name when you present. Disagreement handled in advance reads as rigour; disagreement handled live reads as a gap.
Keep one idea per slide and one sentence per idea. If a slide needs a paragraph it is really two slides, and the second one is usually the interesting half.
Software and tools
We build decks in whatever the team already has open. Tooling arguments cost more hours than they save, and no reviewer has ever approved a budget because the typography was set in the right application.
What does matter is a shared source for the numbers. Every figure links back to the dashboard that produced it, so when someone asks where sixty-two per cent came from the answer takes four seconds instead of a follow-up email.
Other resources
If you are putting a review together for the first time, three habits carry most of the weight:
- Write the recommendation before you write anything else.
- Show one artefact per claim — a clip, a chart or a quote — and never more than one.
- End with the decision you need and the date you need it by.
None of this is unique to design reviews. The same shape works for engineering proposals, pricing changes and hiring plans, because the constraint is identical: attention is short and trust is earned in the first minute.
Start with the ask, defend it with the smallest possible amount of evidence, and leave the room with a decision. Everything else is decoration.
Conclusion
A review is not a performance. It is a request for a decision, made in public, with the reasoning attached.
Teams that treat it that way spend less time presenting and more time building, because the decisions actually survive the week after the meeting.
Write the ask first. Cut anything that does not support it. Then hand the room the smallest set of facts that makes the answer obvious.