The short answer
Most design presentations are built around the work — showing the research, explaining the thinking, walking through the design, concluding with a recommendation. This structure is logical and it is the structure least likely to produce a decision. By the time the recommendation arrives, the audience has formed their own view of what they’ve seen, and changing that view requires overcoming a position they’ve already taken. Presentations that get acted on start with the decision that needs to be made, not the work that informs it. They name the recommendation before the rationale, frame evidence around the risk of not following it, and make the ask explicit and easy to agree to.
Why the standard structure doesn’t produce decisions
The standard design presentation structure has a logical appeal. You did the research, then you formed a view, then you designed something. Presenting in that order feels honest because it shows the audience the journey you took to reach the recommendation.
The problem is that the audience is not retracing your journey. They are forming their own view of the work as you present it — and they are doing so without the context you have, under time pressure, against competing priorities. By the time your recommendation arrives, they have already decided what they think about the design. That view may or may not align with your recommendation. If it doesn’t, you are now in the position of trying to change a view that someone has already formed in the room, in front of colleagues, under conditions that make reconsideration feel like retreat.
Changing a view that has already formed is much harder than shaping a view before it forms. The structure of your presentation determines which of those situations you are in.
The structure that produces decisions
Start with the decision, not the work
Open with the decision the room needs to leave with. Not ‘I’m going to show you the design’, but ‘I need us to decide today whether to proceed with this approach or the alternative.’ This tells the audience what they are evaluating before they see anything, which changes how they process the information you then give them. They are now assessing evidence for a decision, not forming an open-ended view of work.
Name the recommendation before the rationale
State your recommendation before you explain it. ‘My recommendation is X, and here’s why’ is more effective than building to a conclusion the audience hasn’t anticipated. When the recommendation comes first, the evidence that follows is interpreted in its support or refutation. When the evidence comes first, the conclusion is interpreted as one possible reading of it — and the audience’s alternative reading, which they have been forming throughout the presentation, competes with yours on equal terms.
Frame evidence as risk, not quality
Frame your supporting evidence around the risk of not following the recommendation rather than around the quality of the recommendation itself. ‘Here is what this addresses’ is a quality argument. ‘Here is what we are likely to encounter if we don’t address it’ is a risk argument. Risk arguments are more compelling to people under delivery pressure because they connect to something the audience is already trying to manage — the fear of a problem they haven’t yet solved.
Make the ask explicit, specific, and easy to agree to
End with a specific, bounded ask. Not ‘I would welcome your thoughts’, but ‘I need a decision on whether to proceed with this approach before sprint planning on Thursday.’ Specific asks are easier to respond to than open invitations. They also signal that you have thought about what the meeting needs to produce, which increases the likelihood that the room treats it as a decision meeting rather than a feedback session.
What this feels like to practitioners
This structure feels counterintuitive to UX practitioners who believe the work should speak for itself. Starting with the recommendation before the evidence can feel like you are pre-empting a conversation rather than enabling one. It can feel like advocacy rather than presentation.
The reframe is this: in most delivery organisations, under time pressure, the audience is not evaluating your work in the way a design peer would. They are assessing a recommendation against competing priorities with imperfect information. A presentation that acknowledges that context and works with it is more respectful of the audience’s actual situation than one that asks them to engage with the work as if context doesn’t exist.
Instead of asking how to present your design work more convincingly, ask what decision you need the room to leave with, and then structure everything else around making that decision easy to reach.
Frequently asked questions
Why do design presentations fail to produce decisions?
Design presentations fail to produce decisions when they are structured to present the work rather than to reach a conclusion. By the time the recommendation arrives at the end of a standard presentation, the audience has formed their own view of the work without the context needed to evaluate it properly. Changing that view in the room is harder than shaping it before it forms. Presentations that produce decisions name the recommendation first, so the audience evaluates evidence for a specific conclusion rather than forming an open-ended view.
How should you structure a design presentation for stakeholders?
Start with the decision the room needs to reach. Name the recommendation before the rationale. Frame evidence around the risk of not following the recommendation rather than the quality of the recommendation itself. End with a specific, bounded ask — a decision that can be made before a named deadline. This structure gives the audience what they need to evaluate your recommendation against competing priorities, in the time available, rather than asking them to process evidence as if context doesn’t exist.
How do you get stakeholders to act on a design recommendation?
Getting stakeholders to act requires making the recommendation specific and the ask to be bound — not ‘I would welcome your thoughts’ but ‘I need a decision on this before Thursday.’ It also requires framing the recommendation in terms of what happens if it’s not followed, rather than what’s good about it if it is. Risk-framed arguments produce action because they connect to something stakeholders are already trying to manage. Quality-framed arguments produce agreement in principle, which rarely translates to action under delivery pressure.
What is the difference between a design review and a decision meeting?
A design review is a feedback session and its purpose is to gather responses to work in progress. A decision meeting is a commitment session and its purpose is to produce a specific outcome that changes what happens next. Most practitioners present design work in review mode when they need the meeting to function in decision mode. The shift requires changing the structure and the framing before the meeting starts, not during it.