Why Better UX Doesn’t Always Increase Conversions

A redesign can look measurably better and still convert exactly the same, because “looks better” and “removes the blocker” are two different questions, and only one of them moves the number. A page can score well in a stakeholder review, win the internal vote against the old version, and still convert at the same rate a month later, because the thing that was actually stopping visitors from continuing was never touched.

Key takeaways

• A redesign that scores well in a stakeholder review can still leave conversion flat, because looking better and removing a blocker are two different outcomes.
• Conversion moves when a real progression blocker gets removed, not when a page gets a visual upgrade.
• Before approving any redesign brief, confirm it names the specific blocker it’s supposed to remove, not just a general feeling (“modern,” “clean,” “on brand”).
• A brief with no named blocker isn’t a smaller redesign, it’s an ungrounded one, and it should get rejected before it reaches design.
• This isn’t an argument against design. When the blocker genuinely is visual, hierarchy, or clarity, the redesign IS the fix, and the rule still holds: name it first.

Why can a visually better page convert the same as before?

Because conversion is a response to whatever was blocking progress at that step, and a redesign only affects conversion if it happens to touch that specific thing. A visitor doesn’t abandon a page because it looks dated. They abandon because they don’t trust it enough to enter a card number, because the next step isn’t obvious, or because the page promised one thing and delivered another. None of those are aesthetic problems, and a page can fix its aesthetics completely while leaving all three exactly as they were.

This is the gap most teams don’t see until it’s cost them a cycle: a redesign gets judged by whether it looks more polished than the old version, in a conference room, by people who already understand the product. A first-time visitor runs a different test, half-attentive, unconvinced, looking for a reason to leave. The stakeholder review answers “does this look better.” The conversion number answers “did we remove what was actually in the way.” Passing the first tells you nothing about the second.

What’s the difference between a blocker and a surface improvement?

A blocker is the specific thing stopping a visitor from taking the next step at that point in the page. A surface improvement changes how the page looks without touching that thing. The distinction sounds obvious stated this way, and it still gets missed constantly, because most redesign requests arrive as a feeling (“this feels dated,” “this doesn’t feel like us anymore”) rather than a diagnosis.

Three blocker types come up over and over in diagnostic work:

• A trust gap. The visitor doesn’t believe the transaction, the claim, or the business is legitimate enough to proceed.
• A confusing next step. The visitor doesn’t know what happens if they click, or which of several options is the one meant for them.
• A message mismatch. What brought the visitor to the page (an ad, a search result, a referral) doesn’t match what the page delivers, so they don’t recognize this as the right place.

A redesign can improve typography, spacing, imagery, and color, real, visible, defensible improvements, and still leave all three of these completely untouched. That’s not a failure of execution. It’s a mismatch between what the brief asked for and what was actually broken.

How do you name the actual blocker before the brief gets written?

Go back to the diagnostic, not the opinion. A real blocker comes from evidence: a diagnostic review of the step (heatmaps, session recordings, funnel drop-off, direct user feedback), not from someone’s sense that the page looks tired. If a redesign request can’t point to a specific diagnostic finding, it isn’t naming a blocker. It’s naming a preference.

The test is simple to run and hard to fake: put the redesign brief next to the diagnosed problem for that step and ask whether the brief actually addresses it. If the brief never mentions the blocker, the redesign was never actually targeting it, however good the resulting design turns out to be.

Two briefs, same page, only one names the blocker

The pattern below shows up across almost every category of page. Each pair is a constructed scenario, built to show the exact difference a named blocker makes to what design actually gets asked to solve, not a specific client engagement.

Example 1: A checkout page with a stalled step

• Brief without a named blocker: “Checkout feels clunky and outdated. Give it a cleaner, more premium look, better spacing, updated form fields, a more modern button style.”
• Brief with a named blocker: “Diagnostic review shows the largest drop-off is between the cart and the shipping step, and session recordings show visitors scrolling back up repeatedly before abandoning. The shipping cost isn’t shown until step three. Brief: surface total cost, including shipping, before the visitor commits to starting checkout.”

Both briefs could produce a genuinely better-looking checkout page. Only the second one is built to move the number, because it names the actual reason people were leaving.

Example 2: A pricing page with two competing paths forward

• Brief without a named blocker: “The pricing page doesn’t feel differentiated from competitors. Refresh the visual design so it feels more premium and on-brand.”
• Brief with a named blocker: “Diagnostic review shows visitors landing on the pricing page are presented with two equally weighted primary buttons (‘Start Free Trial’ and ‘Talk to Sales’) with no guidance on which applies to them, and exit rate spikes at that exact point. Brief: establish one clear default path, with the second option demoted to a secondary action.”

The first brief could ship a beautiful pricing page that still hands every visitor the same unresolved choice. The second brief treats the choice itself as the problem to solve.

Example 3: A landing page with no trust signal before the ask

• Brief without a named blocker: “The hero section feels flat. Make it feel more dynamic and visually engaging so it grabs attention faster.”
• Brief with a named blocker: “Diagnostic review shows visitors scroll past the hero and pricing anchor without engaging, and exit-intent surveys cite ‘not sure this is legitimate’ as the top reason given. No social proof, review, or credibility signal appears before the pricing block. Brief: place a credibility signal (review, logo, or specific outcome) above the pricing anchor.”

Again: the first brief can ship, look great, and change nothing about why visitors left, because “flat” was never the actual problem. The second brief is aimed at the diagnosed reason, not a feeling about the page.

What’s the rule for rejecting a design brief with no named blocker?

Before approving any redesign, confirm it explicitly targets a named blocker drawn from a real diagnostic review. If it doesn’t, send it back, don’t approve it as a smaller version of the same request.

Use this as a standing filter on every design brief that touches a conversion-relevant page:

1. Does the brief name a specific blocker (a trust gap, a confusing next step, a message mismatch, or another concrete obstacle), not just a general feeling about how the page looks?
2. Is that blocker traceable to a diagnostic finding (funnel data, session recordings, direct feedback), not an assumption about what visitors probably think?
3. Does the proposed design change actually address that blocker, not just improve the page in some unrelated dimension while the blocker sits untouched?

A brief that fails question 1 fails the whole filter regardless of how well-produced it is. “Make it feel more modern” is not a smaller version of a real brief. It’s a different kind of request entirely, one that measures success by an internal reaction instead of a visitor’s behavior, and it should be rejected before it reaches a designer’s desk, not evaluated after the fact based on how the finished page looks.

What if the blocker genuinely is visual?

Then the redesign is the fix, and the same rule applies without modification: name the blocker, then design against it. This isn’t a case against design, and treating it that way would be its own mistake. Visual problems are real problems. A page can genuinely fail because the primary call to action is visually buried beneath competing elements, because a wall of text discourages a visitor from reading the one sentence that would resolve their hesitation, or because inconsistent visual hierarchy makes an already-clear message hard to parse at a glance. All three of those are legitimately design problems, and a visual redesign is exactly the correct response to them.

What makes them pass the filter is the same thing that makes any blocker pass it: the brief names the specific obstacle (“the primary CTA has the same visual weight as three secondary links, and clickstream data shows visitors interacting with the secondary links instead”) rather than a general aesthetic complaint (“this page doesn’t feel premium enough”). The rule was never “design doesn’t matter.” It’s “design has to be aimed at something diagnosed, not something felt,” and a genuinely visual blocker clears that bar as easily as a trust gap or a confusing next step does. The failure mode this article is about is specific: a brief with no named blocker at all, dressed up as a design problem because that’s an easier conversation to have than a diagnostic one.

What to do next

• Before approving a redesign brief, require it to name a specific blocker traced to a real diagnostic finding, not a general feeling about the page.
• Run the three-question filter above on any brief already in flight, and send back anything that fails question 1.
• If a stakeholder pushes for a redesign based on “this looks outdated,” ask what the diagnostic review found at that step. If the answer is “we haven’t run one,” that’s the actual next step, not the redesign.
• Once a blocker is named, confirm the proposed design change is aimed at that blocker specifically, not just an adjacent improvement that happens to ship alongside it.

Alex’s Perspective

The brief that gets rejected fastest in review is never the badly designed one. It’s the one that’s beautifully designed and answers a question nobody diagnosed. A polished mockup is persuasive in a room in a way a funnel chart isn’t, and that’s exactly why the filter has to be a standing rule, applied before the mockup exists, not a judgment call made once a finished design is already sitting in front of a stakeholder who wants to ship it.

Where this fits

This is primarily a Prioritize article, downstream of Experiment: it turns an existing diagnostic result into a standing filter for every future redesign brief.

Alex Harris leads AlexDesigns’ conversion optimization work, where every redesign brief gets checked against a named, diagnosed blocker before it reaches a designer’s desk, exactly the filter this article describes.