Why we push back on "can you make the logo bigger"

"Can you make the logo bigger" is, without much competition, the single most common piece of feedback we get on any new design, from founders and marketing leads alike, across every kind of business we've worked with. We push back on it almost every time, not reflexively, but because it's very rarely the actual problem being described, even though it's the fix being requested.

When we dig into why someone's asking for a bigger logo, the real concern underneath is almost always something else: the page doesn't feel like it clearly represents the brand, or the design feels generic and could belong to any company, or there's a nagging sense that the layout doesn't feel important or substantial enough. A bigger logo rarely fixes any of these underlying feelings.

Enlarging a logo, especially in a header, eats into space that could otherwise carry a clear value proposition, a strong navigation structure, or a compelling call to action, exactly the elements that actually convince a visitor to stay and take action. A bigger logo increases brand visibility marginally while decreasing the effectiveness of almost everything else competing for that same limited space.

We've measured this directly on more than one project: a header redesigned with a modestly sized logo and a stronger, clearer value proposition consistently outperformed a version with an oversized logo dominating the same space, on both engagement and conversion metrics we tracked afterward.

We've learned to ask a direct follow-up whenever this feedback comes up: "what specifically feels off right now, beyond the logo size." The answer is almost never really about size. It's about a design that doesn't yet feel confident, or distinct, or aligned with how the client sees their own business, and the logo is simply the most visible, easiest thing to point at and ask to change.

Once we get past the surface request to the real underlying concern, we can usually solve it with a change that actually addresses it: stronger typography, better use of brand color, a more confident layout, rather than an oversized logo that treats a feeling problem as if it were a measurement problem.

We never just say no and leave it there, because the underlying feeling driving the request is real and deserves a real answer, even if the specific fix requested isn't the right one. We ask what feels off, we show alternative changes that address that underlying feeling directly, and we let the client compare the results side by side rather than arguing about it purely in the abstract.

This approach almost always resolves the request without ever enlarging the logo, because once a client sees a version that actually addresses what was bothering them, the original specific request tends to stop mattering to them entirely.

Occasionally the logo really is disproportionately small relative to genuine best practice, buried in a corner at a size that's hard to notice on a small screen, and in those specific cases we agree readily and make the change without any resistance at all. The point was never to reflexively resist every request, it's to make sure the fix actually matches the real underlying problem.

We distinguish this genuine case from the more common one by checking actual visibility and legibility data, not gut feeling alone, and by asking directly whether the concern is really about size or about something else entirely that a differently sized logo wouldn't actually resolve.

The same dynamic plays out with plenty of other common feedback: "add more color," "make the button stand out more," "can this feel more premium." Each of these is often a proxy for a deeper, harder-to-articulate feeling about the overall design, and treating the literal request as the actual brief tends to produce a series of small, unsatisfying tweaks that never quite resolve what's genuinely bothering the client.

We've started asking this same follow-up question across almost any piece of surface-level feedback now: what's the feeling behind this request, specifically. It's slowed down some early conversations and dramatically sped up how quickly we land on a design that actually satisfies the client, rather than iterating endlessly on the wrong specific fix.

We explain this dynamic openly in early project conversations now, because clients who understand it tend to give us more useful feedback afterward, phrased in terms of how something feels rather than a literal specific instruction for exactly what to change. That shift alone has measurably improved the quality of feedback we get across every stage of a project.

It also builds trust, because a client can see we're genuinely listening for the underlying concern rather than mechanically executing literal instructions without engaging with what's actually motivating them in the first place.

Adjacent to the bigger-logo request is a broader instinct to add something, more text, more images, more sections, whenever a design feels underwhelming. Almost as often, the actual fix is subtraction: removing competing elements so the strongest ones can breathe and actually be noticed, rather than adding yet another element into an already crowded layout.

We test this directly when the instinct shows up, showing a version with something removed alongside a version with something added, and the removal version wins often enough that we now suggest it as the first option to try, before agreeing to add anything new to a layout that already feels crowded.

"Make the logo bigger" is rarely about the logo. It's a proxy for a design that doesn't yet feel right, and the actual fix usually lives somewhere else in the layout entirely.

We'd rather have the slightly more uncomfortable conversation about what's really bothering a client than make the literal change requested and watch the underlying dissatisfaction resurface again in the very next round of feedback.

This has become one of the more reliable signals in how we run design reviews now: any feedback framed as a specific instruction gets one follow-up question before we touch anything first, because that question usually saves everyone a round of unnecessary revisions later on.