How to present design work to a client

The work being good is not the same as the presentation going well. We have all watched a strong piece of design get picked apart in a call, not because it was weak, but because it arrived with no framing and invited everyone in the room to react to it however they felt. Presenting well is mostly about controlling that: giving the work a story, and giving the client a decision to make instead of a canvas to have opinions about.

By Igor Štumberger, Design Engineer & founder of Modulat Updated 28 July 2026

The mistake almost everyone makes

The common failure is presenting the work as a picture rather than as an answer. You put the screen up, you say "so here it is", and you wait. In that silence the client has nothing to do except have reactions, so they start reacting: the blue is a bit cold, my wife would not like that font, can we see it bigger. None of it is about whether the design solves their problem, because you never framed it as a solution to anything.

Good work presented this way loses, and mediocre work presented well often wins. That is worth sitting with, because it means the presentation is not a formality wrapped around the real work. It is part of the work.

Lead with the problem, not the pixels

Before a client sees a single frame, they should hear the problem you were solving in their own words. This does two things. It reminds them what they asked for, which they have half forgotten. And it sets the terms of the conversation: we are here to judge whether this solves that, not whether we personally like it.

A presentation that lands tends to move in this order:

  1. Restate the brief. One or two sentences on what they came to you for and the constraints you were working inside. "You needed checkout to feel faster on mobile without a rebuild."
  2. Show the thinking, briefly. A sketch, a rejected direction, the reason you went one way and not another. This is where the work stops looking like a lucky guess and starts looking like a decision.
  3. Show the work in context. Not a flat image on a slide, the thing as it will actually exist. A clickable prototype, real content, on the device it will live on.
  4. Name the decision you need. End on the specific question you want answered, not an open "so, thoughts?". "Does this direction feel right to build on, yes or no" gets you further than an invitation to redecorate.

Show the work in context

A static mockup on a slide asks the client to imagine the gap between the picture and the real thing, and they will imagine it wrong. A prototype closes that gap. Let them click through the flow, on their own phone if it is a mobile design, with copy that reads like real copy rather than lorem ipsum.

Showing the progression helps too. When a client sees the rough sketch next to the finished screen, the finished screen stops looking arbitrary and starts looking earned. They are watching a problem get solved, not being handed a verdict.

The client is not buying a picture. They are buying the confidence that you understood the problem and made deliberate choices. Everything in the presentation is in service of that.

The live pitch and the leave-behind are two different jobs

Here is the part people miss. There are two presentations, and they have different rules.

The live one, where you are in the room

You are talking, so the work does not have to speak for itself. You narrate the brief, you steer past the rabbit holes, you read the room and slow down where you need to. For this, plain tools are fine. Share your screen, walk the prototype, talk. You are the framing, so the container barely matters.

The one that happens after you leave

This is the one that gets neglected, and it is usually the one that decides the outcome. The client closes the call, then two days later forwards everything to a business partner who was not there, or opens it again alone at 11pm to make up their mind. Now there is no you. The work has to carry its own framing, or the whole thing collapses back into "here is a picture, react to it".

A pile of raw links cannot do that job. Six URLs in an email, no order, no note, and the decision-maker who was not on the call opens them in whatever order they land and forms an opinion with none of the context you spent the meeting building. A folder link has the same problem: it is a pile, not a story.

This is the specific gap a client portal fills, and it is what we built Modulat for. Instead of sending the prototype, the spec, the walkthrough video and the assets as separate links, you put them on one branded page, on your own domain, grouped into sections with a line of context on each. The partner who missed the call opens one link and reads the work in the order you intended, with the framing attached. Because the link never changes even when the work behind it does, the page they open next week is the current version, not last month's. And because the view counts are aggregate, you can see the handover was opened without turning it into surveillance of exactly who clicked what.

What to actually send

The leave-behind for most client-facing design handovers is some subset of:

  • The prototype. The clickable thing, with the Figma furniture out of the way so it reads as finished rather than in progress. We cover the mechanics in sharing a Figma prototype with a client.
  • A short written frame. Two or three sentences restating the problem and what changed since last time. This is the voice you had in the room, written down.
  • A walkthrough video. A two-minute Loom of you clicking through it does more than any spec. It gives the absent decision-maker your narration back.
  • The supporting files. The spec, the assets, whatever they genuinely need, and nothing they do not.

Notice the restraint. The point is not to send everything you have. It is to send the small, deliberate set that tells the story, in order, and to leave the archive out of it.

When you do not need any of this

Worth saying plainly, because the honest answer is not always a whole production.

  • You are showing a tiny change to someone you have worked with for three years. Send the frame, say what changed, move on.
  • The presentation is live and that is the end of it. No absent stakeholder, no revisiting, decision made in the room. Then the leave-behind barely matters and a shared screen is enough.
  • The work is internal. Your team does not need to be pitched to.

The effort earns its place when the handover is a moment that carries weight: a milestone, a decision that involves people who were not in the room, or anything where looking considered is part of what you are being paid for.

Quick answers

How should I structure a design presentation to a client?

Restate the brief first, show a little of your thinking, then show the work in context as a clickable prototype, and end by naming the specific decision you need. Leading with the problem keeps the conversation on whether the design solves it, rather than on whether the client personally likes the colours.

How many design options should I present?

Usually two or three, not one and not eight. One feels like a take-it-or-leave-it, and a wall of options overwhelms the client and dilutes your message. A small set, each framed as a different answer to the same problem, invites a focused conversation instead of a paralysing one.

Should I present design work live or send it over?

Both, and treat them differently. Live, you are the framing, so plain screen-sharing is fine. But plan for the version that gets opened after you leave, by people who were not on the call. That one has to carry its own context, which is where a written frame, a walkthrough video and a single organised page earn their place.

What is the best way to send design work to a client after the meeting?

One organised page beats a handful of loose links. A pile of URLs arrives with no order and no context, so an absent decision-maker forms an opinion without the framing you built in the call. Grouping the prototype, a short note and the supporting files on a single branded page keeps the story intact.

How do I stop clients from nitpicking small details?

Frame the work as a solution to their stated problem and end on a clear decision, rather than opening the floor with "thoughts?". When people are handed a canvas and no question, they fill the silence with subjective reactions. Give them a specific thing to decide and the conversation stays where it is useful.

Igor Štumberger

Design engineer and senior product designer, ten years of handing work to clients. Built Modulat after one too many handovers that made good work look careless.

Hand over the whole thing, not six links.

Modulat gives every client one branded page that holds the prototype, the files, and the notes, on your own domain. The Figma plugin adds work to it without leaving the canvas.

Get started free