How to Present Design Work to Stakeholders (and Actually Get Buy-In)
Most design work does not fail because it is bad. It fails in the room when a strong solution is presented as a sequence of screens, questioned from angles nobody prepared for, and quietly shelved because the people with the authority to approve it never understood why it mattered.
Presenting design work is a skill distinct from doing design work. It is closer to making a case than showing a portfolio: you are asking a group of people with different priorities to commit time, budget, and attention to a direction. This guide covers how to structure that case what to say first, how to frame decisions in business terms, how to handle pushback without either caving or digging in, and how to leave the room with a decision.
It is written for designers presenting to leadership, but it applies equally to product managers and founders who need to explain design decisions to their own teams, boards, or clients.
What Stakeholders Are Actually Evaluating
When designers present, they tend to expect feedback on the design itself: the layout, the colours, the interaction details. Stakeholders are usually evaluating something else. Underneath the comments about button colours and logo size, most of them are asking four questions.
Does this solve a problem we actually have?
What will it cost in budget, engineering time, and opportunity?
What is the risk if we are wrong, and how will we know?
What do you need from me, and by when?
Aesthetic feedback is often a proxy for these questions. A stakeholder who says ‘I don’t like the green’ may really be saying ‘I can’t tell whether this is working, and colour is the only thing I feel qualified to comment on.’ If your presentation answers the four questions clearly, aesthetic comments tend to shrink on their own.
Step 1: Know Who Is in the Room
The same work needs to be framed differently for different people. Before you build the presentation, list who will attend and write one sentence for each: what does this person care about, and what are they worried about?
Executives and founders — growth, competitive position, and risk; they want the headline, the recommendation, and the ask
Finance — cost, return, and predictability; they want numbers with clear assumptions, not enthusiasm
Product — scope, sequencing, and user evidence; they want to know what ships first and why
Engineering — feasibility, complexity, and edge cases; they want to know what you are asking them to build before the meeting, not during it
Marketing and sales — brand consistency and customer-facing impact; they want to know how this changes what they say to customers
If you do not know what someone in the room cares about, ask them before the meeting. A fifteen-minute conversation beforehand is worth more than any slide.
Step 2: Start With the Problem, Not the Screens
The most common structural mistake in design presentations is opening with the solution. When the first thing the room sees is a finished interface, they react to it as they would to any interface: with personal taste. When the first thing they see is a clearly defined problem, they spend the opening minutes agreeing on what needs solving and that agreement becomes the lens through which they judge everything that follows.
A strong opening takes under two minutes: the user problem in plain language, the evidence that it is real (a research quote, an analytics drop-off, a support theme), and what it is costing the business. Only then show the design.
Step 3: Tell the Story of the Decision
Stakeholders rarely need to see every screen. They need to understand why the design looks the way it does. A simple four-part story does most of the work:
Context — what we learned about the user and the problem
Options — what we considered, and why we set the alternatives aside
Recommendation — what we chose, shown through the user’s journey rather than screen by screen
Expected outcome — what we believe will change, and how we will measure it
Showing the options you rejected is one of the most underrated moves in design presentation. It demonstrates rigour, pre-empts the suggestion ‘what if we just did X?’, and shows that the recommendation is a decision rather than a first draft.
Step 4: Translate Design Language Into Business Language
Design vocabulary hierarchy, affordance, cognitive load, consistency is meaningful to designers and mostly opaque to everyone else. Your job in the room is translation. Here is what the shift looks like in practice:
Instead of ‘We simplified the navigation’ — say ‘New users can reach the main task in fewer steps, which should reduce drop-off during onboarding.’
Instead of ‘We introduced a consistent component system’ — say ‘Designers and engineers will reuse components instead of rebuilding them, which should shorten delivery time on future features.’
Instead of ‘We improved accessibility’ — say ‘More people can use the product, and we reduce our legal and reputational exposure.’
Instead of ‘We changed the checkout layout’ — say ‘We removed the points where users hesitated in testing, so more of the people who start checkout should finish it.’
Notice the careful wording: ‘should reduce,’ ‘should shorten.’ Do not promise outcomes you cannot guarantee. Present expected impact as a hypothesis with a way to measure it. Honest uncertainty tends to build more credibility than confident promises that later go unmet. For benchmarks to support your impact claims, the Nielsen Norman Group’s summary of usability ROI research is a credible starting point.
Step 5: Bring Evidence, Not Opinion
Design opinions compete with every other opinion in the room, and the most senior opinion often wins. Evidence changes the contest. A thirty-second clip of a user struggling with the current flow does more than five minutes of explanation. A funnel chart showing where people leave is harder to argue with than a designer’s instinct. Even small evidence five usability sessions, a handful of support tickets shifts the conversation from ‘what do you think?’ to ‘what should we do about this?’
User clips and quotes — short, specific, and hard to dispute
Analytics — funnels, drop-off points, and feature usage that show where the problem sits
Usability test results — task success and the moments where participants hesitated or failed
Support and sales themes — recurring questions and objections that point to the same friction
Competitor comparisons — how the same task is handled elsewhere, shown side by side
Step 6: Handle Pushback Without Caving or Fighting
Pushback is not a sign the presentation failed. It is the point where the real decision gets made. The skill is staying curious without surrendering the purpose of the design.
Separate Preference From Problem
When someone says they dislike something, ask which goal or user it is getting in the way of. A question like ‘Is there a user or a goal this is problematic for?’ moves the conversation from taste to purpose. If a real problem emerges, you have received useful feedback. If it is purely taste, you can acknowledge it and return to the goals the work was designed to serve.
Agree to Explore Without Committing
You can respond to an unsolicited idea without either rejecting it or committing to build it. Agreeing to explore a suggestion and then testing it against the same criteria as every other option keeps the relationship intact and keeps the decision grounded. NN/g’s guidance on how to deal with bad design suggestions describes this approach in detail.
Know What Is Negotiable Before You Walk In
Decide in advance which parts of the recommendation are core (the problem it solves and the principle behind it) and which are flexible (specific visuals, sequencing, wording). Concede flexible details gracefully and early; hold the core with evidence. Knowing the difference stops you from either defending everything or giving everything away. A healthy critique culture makes all of this easier, and NN/g’s guide to running design critiques is a useful reference for building one.
Step 7: End With a Clear Ask
Many design presentations end with ‘So, any questions?’ which invites discussion but not a decision. End instead with a specific ask: approval to proceed to the next phase, a named person to unblock a dependency, budget for a defined test. Say what happens next and by when. A presentation that does not end in a decision tends to end in a follow-up meeting, and follow-up meetings rarely go better than the first one.
A Simple Structure for a 20-Minute Presentation
Minutes 0–2: the problem and the evidence that it is real
Minutes 2–4: the goal, and how success will be measured
Minutes 4–7: options considered, and why the recommendation won
Minutes 7–13: the recommended design, shown through the user’s journey
Minutes 13–15: expected impact, risks, and what you are assuming
Minutes 15–20: discussion, then the specific ask and next steps
Leave at least a quarter of the time for discussion. If you fill the whole slot with presenting, you have built a lecture, not a decision meeting.
Before the Meeting: Remove the Surprises
The best design presentations are the ones where nothing in the room is a surprise to the people who matter. Share the problem and early direction with key stakeholders individually beforehand, particularly anyone with veto power or a strong opinion. These pre-conversations surface objections while there is still time to address them, and they turn potential critics into people who feel they have contributed. Engineers in particular should see anything with significant implementation implications before the formal review.
Common Mistakes to Avoid
Opening with the solution — the room reacts with taste before it understands the problem
Presenting every screen — walk through the user’s journey, not the file structure
Using design jargon — translate into the outcomes your audience cares about
Over-promising on impact — present expected results as hypotheses with a measurement plan
Defending everything equally — know what is core and what is flexible before you walk in
Ending without an ask — a presentation without a decision creates a follow-up meeting
A design presentation is not a showing of finished work. It is the moment a recommendation becomes a decision and decisions are made by people who understand the problem, trust the reasoning, and know what happens next.
Final Thoughts: Presenting Is Part of the Design
Designers who learn to present well gain something beyond approval rates: influence. When stakeholders see that your recommendations are grounded in evidence, framed in terms they care about, and open to honest challenge, they start involving design earlier and design that is involved earlier is almost always better design.
At Afrodity Designs, presenting the reasoning behind our work is part of how we deliver it. We structure reviews around the problem, the evidence, and the decision required, so that clients leave with clarity rather than just a deck. If you are preparing for an important design review, or you need help making the case for design investment inside your organisation, we would love to help.
