Audit before or after a redesign? Before, or you pay twice
You plan to audit once the new site is live. By then you have paid to rebuild the problems you already had. Independent before-and-after data on 99 redesigns, and the four lines that belong in the brief.
Auditing after a redesign means paying to rebuild the problems you already had, and auditing before turns those same problems into the brief.
Here is the sentence almost everybody says first: "I will audit it once the new site is up. No point measuring something I am about to throw away."
That is reasonable. You are replacing the thing. Surveying it feels like measuring a house the week before the builders arrive.
What it misses is that you are not knocking the house down. You are redecorating it. Your form, your headline, your pricing block, the order of your checkout steps: all of it gets rebuilt from the same assumptions that produced the current version, into nicer markup. The brief is where a problem gets fixed or gets carried. Almost nobody audits the brief.
Should you audit before or after a redesign?
Before. An audit after launch grades work you have already paid for. An audit before launch becomes the requirements list, so the problems get designed out rather than restyled. Then run it again after, because that is how you find out whether the rebuild moved anything.
Both readings help. Only one is still cheap.
Not sure what your own list looks like? Paste your URL before the brief gets written.
Which problems will the new design actually remove?
Only the ones somebody wrote down. A rebuild reliably removes problems living in layout and code: slow pages, broken mobile, navigation nobody can use. It does not remove a vague headline, a form asking for more than it needs, or an offer people do not understand. None of those are design faults.
Two minutes, no theory. Open your brief and count the lines naming a measurable problem on a named page. "Modern and clean" does not count. "The demo form asks for nine fields and most people who start it never finish" does.
A count of zero means you have commissioned a taste project with a sales hope attached.
Why does a redesign carry the old problem forward?
Because the brief inherits the assumptions that built the old page. Baymard Institute benchmarked 344 leading ecommerce sites and found the average checkout flow carries 39 usability issues. Most sit in field design, wording and the order of steps, so new visual styling leaves them where they were.
Across the 134 sites Revslip has audited, the findings carrying the largest euro figures are usually wording, offer clarity and form length rather than layout. Worth stating the bias: sites that get audited are sites whose owners already suspected something.
Waiting has a number on it too. The free-tier estimate is one line you can run by hand:
traffic × CVR gap × AOV × mobile weight = monthly leak
Put real numbers in. Six thousand visitors a month, a 1.1% rate against the 1.8% your own best page already does, a €90 average order, 60% of traffic on a phone. About €2,270 a month, so a twelve week build loses roughly €6,300 before the new site is even measurable. That estimate assumes your traffic holds, so halve it before it reaches a plan.
What do 99 before-and-after case studies show?
That a redesign is an unreliable instrument for moving sales. Nielsen Norman Group compared improvement scores across 99 case studies and found the average gain fell from 247% in 2006 to 2008 down to 75% by 2020. The 2020 confidence interval runs from 8% to 104%.
The 8% is the figure worth sitting with. A rebuild returning close to nothing is inside the normal range, not an unlucky exception. Half that set landed between 13% and 157%, a spread wide enough that "we redesigned it" predicts almost nothing.
- 247% to 75% fall in average improvement score between 2006 to 2008 and 2020
- 8% to 104% the 2020 confidence interval, so near-zero gains sit inside normal
- 39 usability issues in the average checkout flow, across 344 benchmarked sites
Now the interesting part. The same research house also tells you when to rebuild. In 2015 Hoa Loranger listed severely low site-wide conversion rates among the conditions justifying a full overhaul, and said otherwise to "only resort to a complete redesign if the data tells you to do so". Five years later her colleague Kate Moran measured what overhauls returned and found the average had dropped by 69%.
Those two are not in conflict. They explain each other. Moran attributes the fall to the rest of the web getting better, which lifted both your starting baseline and what visitors expect. A rebuild in 2008 competed with bad websites. Yours competes with good ones, which is why the brief has to carry named problems instead of an ambition.
The UK Government Digital Service puts it in one line: "Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons." A redesign is the opposite shape, one large change released at once, which is why the problem list has to exist first.
What belongs in the redesign brief?
A problem list with page names and numbers attached. Three or four lines saying what is wrong, where, and what it is worth a month. That turns the brief from a document about taste into a specification you can test the finished build against.
- Audit the live site first. Get the ranked list while the old pages still exist to be measured.
- Fix the cheap ones now. Wording, form fields and a clearer offer do not need the new build, and they pay from this week.
- Write the rest in as requirements. "Checkout collects five fields, not nine" is a requirement. "Cleaner checkout" is a mood.
- Keep your measurement. Record current rates by device and by source before launch, or there is nothing to compare the new site to.
Want the list before the build starts? Run a free audit and every finding arrives priced.
How will you know the new site is better, not just newer?
By reading the same metric on the same traffic mix. Record conversion rate by device and by source for the four weeks before launch, then read that same split four weeks after. A site that looks better and sells the same amount is a cost, not an improvement.
Launch weeks lie. Redirects settle, rankings wobble, your own team is on the site constantly. Give it a fortnight, and treat a difference under 20% as directional until you have a few hundred sales each side. The 20-minute diagnostic has the splits worth recording first.
When is auditing first the wrong order?
When the current site is genuinely going away. If you are moving platform, changing what the business sells, or replacing a four-page brochure with a real product site, a problem list about the old pages describes something that will stop existing. Audit the new build instead, before launch rather than after.
The other honest case: if the contract is signed and the build ships next week, the pre-audit has missed its window. Measure properly instead, and read whether you needed the redesign at all before commissioning the next one.
What this cannot read in advance Revslip audits pages on a public URL, so it cannot check a design still in Figma or a staging site behind a login. Point it at the new build the day it goes live and you get the list before your visitors do.
A rebuild is a bet on your taste. A problem list is a bet on your numbers. Only one of those you can check first.
Improvement data from Nielsen Norman Group, 99 case studies, 2020. Overhaul conditions from Hoa Loranger, NN/g, 2015. Checkout issues from Baymard Institute, 344 benchmarked sites. Iteration principle from the UK Government Design Principles. Costs in what a CRO audit actually costs.