The Art of the Brand Presentation

Presentation is Design

I've seen genuinely excellent design work fail in a client presentation because it was poorly contextualized. The client couldn't see past the rough-looking mockup or the absence of supporting rationale. The work was right; the presentation didn't let it be seen.

This isn't just a client relations problem. It's a design problem. Presentation is part of the work.

The Narrative Structure

Every client presentation has a narrative: where we started (the brief, the strategy, the insights from research), how we got here (the conceptual thinking, the design decisions), and what we're proposing (the concepts themselves).

This narrative does the essential work of framing the design before the client sees it. When a client sees a concept without context, they immediately start reacting — "I like it" or "I don't like it" — before they've had a chance to think about whether it solves the problem. The narrative delays that instinctive reaction long enough for considered evaluation to happen.

Showing Work in Context

Concepts shown in isolation — a mark on a white background — are hard to evaluate. Concepts shown in application — on business cards, stationery, a website header, signage — can be evaluated for how they perform in the world.

I always show concepts in realistic application contexts. Not just because it looks impressive (though it does), but because application context reveals things about how the mark works that an isolated presentation hides.

How Many Concepts

Two to three concepts, presented as fully developed directions, is the right number. One concept comes across as take-it-or-leave-it. Four or more overwhelms and makes the designer seem uncertain about what the right answer is.

The concepts should be genuinely distinct from each other — different conceptual approaches, not variations on the same theme. If I can't articulate meaningfully different rationales for each direction, I haven't done the exploration work properly.

Handling Feedback

The presentation is also where feedback happens. My job during feedback is to listen, to ask clarifying questions, and to distinguish between feedback that represents genuine design requirements and feedback that represents personal preference.

Both types of feedback matter, but they call for different responses. Design requirement feedback should drive revision. Preference feedback should be noted and weighed against the design rationale.

The Follow-Up Document

After the presentation, I send a follow-up that summarizes what was discussed and agreed, what the next steps are, and what the timeline is. This eliminates ambiguity about what was decided and creates a clear path forward.

Good process produces good outcomes. The presentation is part of the process.