Presentations & Demos

Arguing a decision on paper and delivering it out loud, in a room, with everybody looking at you are different jobs. Presenting is two skills carrying one name: the artifact you build, and the way you deliver it live.

Rehearse your next demo the smart way: listen on your commute, present like it's your tenth time.

Listen to the full Presentations & Demos course on DesignPath
Share
A laptop showing a grid of faces on a video call, beside a green mug
Share

Both have to work. A well-built deck delivered at 190 words a minute loses the room in the first ninety seconds. A calm delivery of a muddled deck leaves eight people politely confused about what you wanted.

Presenting is also where the stakes concentrate. It's the moment the decision gets made, the budget is approved or held, the investor leans in or reaches for their phone. Designers are usually good at making things and rarely trained at presenting them, which means getting even moderately good at this puts you ahead of most of the room.

Building the Deck

You can translate every word correctly and still lose the room, because the structure was wrong before you opened your mouth.

The classic designer version is opening with the screens. You're proud of them, so you lead with the visuals. Stakeholders who can't read a layout the way you can then spend the meeting wondering what problem this solves and what it costs. By the time you get to the reasoning, they've already decided.

A business-legible presentation inverts that. It opens with the goal, builds the case, and shows the design as evidence for the reasoning rather than as the headline.

The Order That Works

Eight sections cover a stakeholder presentation, and the sequence matters more than any individual slide.

  1. Goals: the business targets this work connects to. Everything after it now has a reason to exist.
  2. Translation: the initiative in plain language, without jargon. What you did and why.
  3. Evidence: the research and the user pain, quantified where you can.
  4. Ideas: the options you considered, plotted by impact against effort. Showing what you rejected builds trust in what you chose.
  5. Design work: the flows and screens, arriving as the answer to a problem the room already accepted.
  6. Metrics: how success gets measured. Naming a metric before anybody asks signals accountability.
  7. Risks: what could go wrong, and your plan for it.
  8. Next steps: the recommended path and the longer arc behind it.

Notice the shape. Business framing brackets the design work at both ends, so goals and metrics anchor it and the screens sit in the protected middle.

Why Context Has to Come Before Craft

Lead with screens and you're asking stakeholders to reverse-engineer the value from a picture. Most of them can't, and the ones who can are doing work you should have done.

Lead with goals and evidence and you've built the need before the solution appears. By the time the design shows up, the room is looking for how it solves a problem they already care about rather than deciding whether to care at all. Same content, same slides, completely different reception.

You won't always present all eight in depth. A fifteen-minute review might spend one line on risks and four minutes on evidence, and that's fine. The sequence holds regardless: context before craft, every time.

What a Slide Is For

Structure gets the order right and slide craft keeps the room listening. Three rules carry most of it.

  • One idea per slide. A slide making two points should be two slides. A crowded slide gets read instead of heard, and now nobody is listening to you.
  • Show rather than write. A slide is a visual aid, not your script. One big image or one number, few words, with the detail in your mouth.
  • State the takeaway as the title. "Checkout drop-off doubled after the redesign" beats "Checkout analysis", because somebody who only skims still leaves with the point.

There's research behind the second rule. Richard Mayer's work on multimedia learning, published in 2001, includes what he called the redundancy principle. People understand less from narration paired with identical on-screen text than from the narration alone. Reading and listening to the same words at once costs comprehension rather than reinforcing it, which is why a slide you read aloud is worse than one you talk around.

That title rule is the cheapest upgrade available to most decks. Writing each title as a claim rather than a label forces you to know what each slide is arguing. Any slide you can't title that way is a slide with nothing to say.

Drafting the Structure with AI

Turning a pile of design notes into that sequence is a job a model does well, because the sequence is fixed and the sorting is mechanical.

Prompt: "Organize my notes into a stakeholder presentation using these sections in order: goals, translation, evidence, ideas, design work, metrics, risks, next steps. Put each note under one section only, and list separately every section where I'm missing information I need to gather: [paste notes]."

The gap list is the useful half. Fill the evidence and metrics sections yourself, since both have to be real rather than plausible-sounding, and a model asked for a metric will invent one that reads perfectly.

Pro tip: Build the deck in reverse, starting with the next-steps slide. Knowing exactly what you're asking for makes it obvious which evidence earns a slide and which is just interesting.

Found this useful? Pass it on.
Share