Your Signup Page Conversion Dropped After a Redesign

G. K. Chesterton put a fence across a field in an essay about reform in 1929. A reformer comes upon it, can see no use for it, and proposes to clear it away. Chesterton's answer was that the objection runs backwards. Go and find out why the fence was built, and come back when you can say. Then, and only then, may you take it down.

Conversion friction is anything on a page that makes a visitor hesitate, get confused, or leave before completing the action the page exists for: an unclear form, a missing trust signal, a value proposition that never lands. When a signup page conversion dropped after a redesign, the cause is rarely something the new layout added; it is usually something the old layout was quietly doing that nobody had written down.

A redesign removes fences at speed. Not maliciously, and usually not even deliberately. A new grid has less room, a new type scale makes a paragraph look heavy, a reassurance line reads as clutter in a comp with no real content in it, and the element goes. The design review then does what design reviews do: it examines the screen in front of it. Every question asked is about what is present. The regression is in what is absent, and absence has no component in Figma to click on.

Why a redesign hurt conversion while looking better

The team is not wrong that it looks better. That is what makes this situation hard to talk about.

Visual quality is a real axis and the redesign probably moved it. Conversion is a different axis, and on it a page is a sequence of small answers to questions a visitor never asks out loud: am I in the right place, is this company real, what happens after I hand over my email. Each answer lives in something concrete: a line of microcopy, a row of customer logos, a step indicator, a sentence of plan comparison sitting where the eye lands before the form does.

Those are the fences. Here is the list I would check first, in roughly the order they get removed:

• A reassurance line under the primary button ("no card required", "cancel any time", "takes about two minutes").
• Customer logos or review marks that sat near the form and now sit in a footer, or nowhere.
• The value proposition, which has moved below the fold because the new hero is taller.
• A step counter, removed because the new flow "feels shorter" without one.
• Field labels replaced by placeholder text, which vanishes the moment a visitor starts typing.
• An explanation of why you need a particular field, dropped because it made the form look longer.

None of those is a design failure on its own terms. Each one was removed by a reasonable person for a reasonable reason, and each one was carrying something.

The single clearest example of this pattern in our own reference set is not even a redesign. An audit of one company's pages found twelve enterprise customer logos on the homepage and zero on the signup page. The proof existed, the company had earned it, and it simply was not present at the step where a visitor decides whether to hand over a work email. A redesign produces that same state in one sprint, across several elements at once, and calls it a cleanup.

Why the people who built it are the last to see it

Nobody on the project can read the new page cold. You know where the pricing link is because you moved it. You know the second field is optional because you argued about it for an hour. You read the hero as "clean" because you have seen it forty times, and a first-time visitor reads the same hero as "I still don't know what this does."

That is not a failure of talent. It is what happens to anyone who has spent three weeks inside a layout, and it is the reason design review cannot catch this class of problem. Review asks whether the screen is good. The question that matters is whether the screen still answers everything the old one answered.

Analytics, meanwhile, tells you the rate fell and nothing else. It has no opinion about which of the eleven things that changed on that page is responsible, because it never saw the page, only the outcome. What usually follows is a thread of guesses. Someone thinks it is the button color. Someone else thinks the new headline is too clever. Someone points at the illustration. These are all plausible and none of them is evidence, and the person whose theory wins is typically the person with the most standing in the channel rather than the one who happens to be right.

How do you trace a conversion regression after launch?

Start by writing the removal list, then score the new page against named dimensions so the findings arrive ranked instead of argued. That is the short version, and it is deliberately boring, because the interesting-sounding approaches here mostly produce confident guesses.

The removal list is a manual exercise and it takes about twenty minutes. Open the old page, from the Wayback Machine or a screenshot in the pull request, next to the new one. Write down every element that appears on one and not the other. Include the small things. Microcopy under a field is an element. A security mark is an element. The order of the fields is an element even when all the fields survived.

Then score the page. A conversion health audit reads the live page and rates it across 14 dimensions, 7 for the humans reading it and 7 for the AI agents parsing it, and each finding is pinned to a specific region of the screenshot with an estimated impact and a confidence level. For a redesign regression the human-plane 7 are the ones that matter: cognitive clarity, decision clarity, trust signal, motivation strength, comfort level, flow coherence and identity match. The full breakdown of what each one measures is in the dimensions walkthrough, and the definitions themselves sit in the conversion friction entry.

The useful output is not the composite number. It is a sentence of the form "trust signal scores 4 because the only proof on this page is a testimonial below the form, and the form is above the fold", which you can check against your own screen in ninety seconds and either accept or argue with specifically.

If an audit of the old page exists, this gets considerably better. Re-auditing the same URL produces a version with a per-dimension delta, so instead of debating the redesign you can read that trust signal fell by three and everything else held. Most teams do not have that, which is an argument for auditing a page before rebuilding it rather than a reason to feel bad afterwards.

Two honest limits before you act on any of this. First, the drop might not be the redesign at all. Redesigns tend to ship alongside campaigns, seasonality, pricing experiments and traffic-mix changes, and a new page that launched the same week a paid channel scaled up will look guilty when it is merely present. Check the source mix before the layout. Second, an audit scores what is on the page now. It reasons about what a reasonable visitor would struggle with, not about what your specific buyers tolerate, and where a Nudgent report is unsure it says LOW confidence and means it. Pair it with session recordings on the new page, which will at least tell you where people are stopping now versus before.

What to do when the new signup page converts worse

Do not revert, unless the bleeding is genuinely expensive this week. A revert throws away work that is mostly good and, worse, throws away the information: you end up back at the old number with no idea which change cost you the points, which means the same element gets removed again in the next rebuild.

The sequence that works:

1. Write the removal list. Twenty minutes, both pages side by side.
2. Run an audit on the live new page and read the top three findings.
3. Look for the overlap. An element on your removal list that also shows up as a ranked finding is your first candidate, and it is usually one of two or three things rather than eleven.
4. Restore that one element, in the new design language rather than by pasting the old component back in.
5. Measure for long enough to believe the result, then take the next candidate.

One change at a time is the part teams skip, and it is the only version of this that teaches you anything. Restore four elements at once and the number may recover, but you will still not know which fence was load-bearing, and you will be in exactly this position after the next redesign. More on how we score all of this is across the blog and the glossary, and the scoring procedure itself is written out in the methodology.

There is one document I have never seen a team produce, and it is the one this whole problem turns on.

Every redesign ships with a list of what it added. Feature by feature, screen by screen, that list gets written, reviewed and celebrated. Nobody writes the other list. So write it. Open the two pages, put down every element the new one no longer has, and go through them one at a time. Can anyone on the team still say what each of those was doing there?