Understanding the Design Rationale: Why We Made Those Choices

What Design Rationale Actually Is

Every element of a brand concept has a reason: the shape of the mark, the typeface, the colour choice, the composition. None of these decisions exist because a designer thought they looked nice. Each one connects back to the brand strategy agreed during the discovery and strategy phase.
Those connections are what the rationale makes explicit.

We might choose a typeface because it signals precision and credibility without feeling cold, reflecting a positioning of “expert who is approachable.” A colour in the green-teal range might be chosen because it creates distinction in a market dominated by navy and grey, while still reading as professional. We might choose a geometric mark because the strategy called for structure and clarity over warmth and organicism.

That rationale is the bridge between the strategy you approved and the design in front of you. When you understand it, the design stops being a matter of taste and becomes something you can evaluate against an agreed standard.

How to Read a Design Presentation

The order in which you take in a presentation matters more than most clients realise.
Read the rationale first. Before you form an opinion on the visual, understand the intent behind it. Then look at the design. Then move to the context mockups: the business card, the website header, the social media profile image, the letterhead.

Context changes everything. A mark that looks simple in isolation can carry real weight in application. A colour that looks quiet in a swatch can feel confident and distinctive on a website header. Judging a brand concept on a white slide, stripped of any real-world context, is one of the least reliable ways to evaluate it.

We build context into every design presentation for exactly this reason. The mockups are not decoration. They are part of the argument.

What the Rationale Does Not Cover

The rationale explains strategic and functional decisions. It does not tell you whether you personally like the typeface, or whether a particular shade of blue resonates with you aesthetically. That is not its job, and it was never designed to be.

The question to hold when reviewing a concept is not “do I like this?” It is: “does this do what we said the brand needs to do?”

Those are different questions. They often produce different answers. A typeface you find personally cold might be exactly right for a brand that needs to signal clinical precision to sceptical, high-value clients. A colour you find bold might be the one thing that makes the brand visible in a crowded market.

Aesthetic preference is real, and it is worth noting. But it occupies a different tier of importance from strategic fit. Knowing which tier your reaction belongs to is one of the most useful things you can do at this stage of the project.

How to Challenge a Design Decision Well

When something in the concept does not feel right and you want to push back, challenge it at the rationale level. That is where the conversation becomes productive.

• Useful: “The rationale says this colour signals professionalism, but I think it may read as cold to our clients specifically. They choose us because of the relationship, not just the expertise. I am not sure this reflects that.”
• Not useful: “I just don’t like it.”

The first gives us something to work with. It tests the design decision against the strategy. Maybe we agree and adjust. Maybe we can show you why the concern does not apply in this specific context. Either way, the conversation moves forward.

The second leaves us with nothing to pull on. There is no brief to test it against, no strategic principle to weigh. Feedback that has no anchor in the agreed direction is very hard to act on without introducing new risk to the project. (See: How to Give Feedback That Actually Moves the Project Forward)

You Do Not Need to Think Like a Designer

Evaluating design well does not require design knowledge. It requires familiarity with the brief: the strategic direction you and we agreed on together at the start of the project.

That brief is yours as much as it is ours. The strategy document, the positioning, the agreed audience, the competitive context we mapped: all of it lives in writing and all of it belongs to the project. When something in the design surprises you, the brief is where to go first. Does the design reflect what we agreed? If yes, the question is whether the execution does it justice. If no, that is a specific, addressable problem.

Design that challenges your expectations is not automatically wrong. Sometimes it is the most honest response to a strategy that asked for something genuinely different.