Presenting Design, an essential skill

"A designer who does not present their own work is not truly a designer." — Mike Monteiro, Design is a Job

That sentence is harsh, but it has a foundation. Presenting what you designed is part of the work, as much as designing it. It's not a task you delegate to the Lead, the PM, or the Art Director "because they speak better". When the work is yours, you should be the one talking about it.

Why the designer should present their own work

Four reasons that stack up:

• Builds relationships with clients, colleagues, and the team. Presenting is how you become visible.
• Makes you accountable for what you delivered. No intermediary can dilute the decisions you made.
• Lets people ask you directly. Whoever designed it has context no one else has.
• Trains presentation and storytelling. Skills that only develop with real practice.

If you're reading this and you're an Art Director or team Lead, make sure designers present their own work. They deserve the space and the whole team gains from it.

If you're a designer and someone else has presented your work for you (it's not that uncommon), try to explain the gains of doing it yourself. Not easy, but worth it.

Rule no. 1: focus on objectives, not features

This is the rule that has saved me the most time (and discomfort) over the years.

Every presentation should be prepared, built, and delivered around the problem you're solving and the goals of the initiative. Not around what looks pretty or the feature you figured out how to build.

The positive side effect: by keeping the focus on objectives, you avoid comments about button colour, spacing, and other secondary issues that derail meetings.

Preparation

Before we go further: being nervous is normal. It's your body signalling that it's facing responsibility. I don't know anyone who doesn't get nervous before an important presentation. It gets better with practice, but it never disappears completely.

Agenda

Presentations are meetings. They should have an agenda. It lets the people in the room anticipate what's coming, prepare materials, and save meeting time.

A good agenda includes:

• The purpose of the meeting
• Topics and details that will be covered
• Expected outcome at the end
• Time and planned activities
• Each person's responsibility

Cost of the meeting

In smaller companies you can skip this point. In an enterprise context it's worth thinking about: each person in the room has a cost (salary, time, context lost). Invite only those who contribute or are essential.

Harvard Business Review has a meeting cost calculator that helps put it in concrete terms.

Preparing the presentation

Preparation is the most important phase. Presenting design should be taken seriously, whether your work is on a napkin or in a polished Figma file. Some practices:

• Write down the idea and the goal of the presentation before opening any slide tool.
• Share the outline early with colleagues and gather structural feedback.
• Review the goals through the process. It's easy to drift.
• Iterate with the team as you go. Don't wait for the final version to share.
• Run an internal test with your team before the real thing.
• Present informally to a smaller selection of stakeholders when you're confident. Feedback at this stage is precious.
• Adjust based on prior feedback before the main presentation.
• Send the deck before the meeting, whenever possible.

Delivery

This is the part where you introduce the topic, explain what you'll present, and introduce any relevant team members.

If you're presenting with others, don't forget to support them if you see them stuck. Helping is part of the job.

Avoid exhaustive presentations where you walk through every detail of the design. Focus on how what you're presenting solves the problem, or how it meets the goals of the initiative.

Things to reinforce during delivery:

• Mind your posture
• Hold eye contact with the people you're presenting to
• Show enthusiasm for the work
• Speak slower than your instinct asks you to
• Look at people, not at the screen
• Never use sarcasm (yes, it happens, and it's always bad)

Receiving feedback

Preparing to receive criticism matters, especially if there's someone in the audience who doesn't understand the role of design. Define the format and type of feedback you're after. It can be in the agenda, and you can reinforce it at the end of the presentation.

Defining the scope of feedback makes it easier for people to share opinions, because you've created the space.

Good rules to set:

• Avoid assumptions about the decisions made
• Give feedback in question form ("what was decided about X?") rather than statements ("X should be different")
• Avoid personal opinions about aesthetics
• Focus on the design, not the designer
• Define the specific scope of feedback (e.g. "focus on tone of voice and structure; ignore imagery and colour")

Some practitioners suggest keeping feedback separate from the meeting. Others place it at the end of the presentation.

What's worked best for me: leave a short part at the end just for clarifying questions, and book a second, shorter meeting for feedback. Between the two, I ask stakeholders to send feedback by email. It forces reflection, avoids impulsive reactions, and gives me time to prepare answers.

To get started

Three steps for next time you present:

1. Define the goal of the presentation in one sentence before opening slides.
2. Run at least one internal dry run with the team.
3. Define the scope of feedback explicitly, both at the start and the end.

If something here stuck, write to me.

Related reading: on research as the foundation of design, on heuristic analysis with a template which gives concrete artefacts to present, and on how to do storymapping which helps structure narrative.