Because looking better and working better are different projects, and most redesigns only fund the first one. A new site can win every internal compliment and still lose leads, because nobody checked whether the changes helped the people who were already converting on the old site.
We have delivered more than 150 projects, and the redesigns that go wrong almost never go wrong on the design. They go wrong on the decisions made before anyone opened Figma, and on the things quietly dropped in the last two weeks before launch.
This is our honest account of what we see fail, including the parts that are our industry''s fault rather than the client''s.
A redesign fails when the business is worse off after it than before. That usually shows up as fewer enquiries, less organic traffic, or a slower site, not as ugly pages. The uncomfortable part is that a failed redesign often looks like a success for months, because nobody was measuring the right thing.
The failure we see most is a site that gets the same traffic and converts less of it. Nobody notices, because traffic is the number people watch. Enquiries drift down quietly and get blamed on the market.
So the first thing worth fixing is the definition. If you cannot say what number should be higher after launch, you cannot tell whether the project worked, and you will end up judging it on taste.
Usually because URLs changed and nothing told search engines where things went. But some drop is normal and expected. Google''s own documentation on site moves says to expect temporary fluctuation in rankings during a move, and that a medium-sized website can take a few weeks for most pages to move in its index.
That distinction matters enormously in the two weeks after launch. A dip is not proof of failure, and a flat line is not proof of success. Google also notes it will temporarily crawl your new site more heavily than usual after a migration, so early data is noisy in both directions.
What is not normal is a drop that never recovers. That is nearly always missing redirects, pages that quietly did not get rebuilt, or content that was trimmed because it looked untidy in the new layout. We treat the URL map as a deliverable in its own right, and the mechanics of getting it right are covered in our guide to migrating a website without losing SEO.
Google suggests timing a move for when your traffic naturally dips, which is sensible advice almost nobody follows. Launches get scheduled around board meetings instead.
Often, yes. A surprising number of redesigns begin with the sentence that the site looks dated. That is a feeling, not a brief. It gives a design team no way to make a tradeoff, so every decision defaults to whoever has the strongest opinion in the room.
We push hard on this at the start, because a vague goal is expensive later. If the goal is more demo requests, we will fight to keep the form high on the page. If the goal is credibility with enterprise buyers, we will spend that space on proof instead. Those are opposite layouts, and only a stated goal tells you which one is right.
The honest version of most briefs is that a new leadership team wants the site to feel like theirs. That is a legitimate reason to redesign. It just needs saying out loud, because it changes what success means.
Because internal opinion is free and available in the room, and user evidence is not. So the person who feels most strongly about the hero image wins, and the site ends up reflecting an internal debate rather than what visitors need.
The pattern is predictable. Stakeholders review the design as though they were buying from the company, which they are not. They already know what the product does, so the explanatory copy feels obvious and gets cut. The result is a site that makes perfect sense to people who work there and none at all to a first-time visitor.
We are not innocent here either. Studios pitch on visuals because visuals win pitches, which trains clients to judge the work on how it looks in a presentation. Then everyone is surprised when the thing optimised for looking good in a presentation performs like something optimised for looking good in a presentation.
Far less than teams assume, which removes the usual excuse. Nielsen Norman Group''s long-standing guidance is to test 5 users in a qualitative usability study, because testing with 5 people finds almost as many usability problems as testing with many more. Jakob Nielsen has made this argument since 1989.
Five people is an afternoon. It is cheaper than one round of internal review meetings, and it settles arguments that would otherwise run for weeks. Watching two strangers fail to find your pricing page ends a debate faster than any amount of internal discussion.
NN/g does list exceptions, and they are worth knowing so you do not overclaim. Quantitative studies aiming at statistics need at least 20 users, card sorting needs at least 15 per user group, and stable eyetracking heatmaps need 39. But NN/g''s own position is that the vast majority of research should be qualitative, aimed at insight rather than numbers.
If you have budget for more, NN/g suggests spending it on additional studies rather than more people in one study. Testing five users three times through a project beats testing fifteen once, because you get to fix things in between.
Because performance is treated as a technical detail rather than a design constraint, so it gets discovered at the end when the expensive decisions are already made. Every full-width video, custom font, animation library, and tracking script arrives as a design choice and lands as a performance cost.
The measurable targets are public and specific. Google''s guidance is that Largest Contentful Paint should be 2.5 seconds or less at the 75th percentile of page loads, and web.dev states that an Interaction to Next Paint of 200 milliseconds or less is good, while anything above 500 milliseconds is poor. Those are the numbers a redesign has to hold.
We set a performance budget before design starts, and we treat it like any other requirement. When something exceeds it, the conversation is about what to remove, not whether the number matters. That single habit prevents most of the slow relaunches we get called in to fix.
The mobile side is where it usually bites. StatCounter Global Stats put worldwide mobile share at 51.51 percent in June 2026, so more than half your visitors experience the heavy version of your design on the weaker device.
In pieces, unless you have a strong reason not to. A big-bang relaunch changes hundreds of variables on the same day, which means when something breaks you cannot tell which change broke it. Shipping in sections gives you attribution, and attribution is what lets you learn anything.
We will say the honest counterpoint. Sometimes a full rebuild is genuinely correct, because the old site''s structure, content model, or platform is the actual problem, and patching it page by page just spreads the cost over a longer period. A typical project for us runs four to eight weeks, and part of scoping is deciding which of these two shapes the work should take.
What we would resist is the phased redesign that never finishes. Two years of half-migrated pages with two different design languages is worse than either option, and it is the most common outcome when nobody sets a deadline for the second half.
They keep what was already working. The teams that succeed start by finding their best performing pages and their highest converting paths, and treat those as things to protect rather than things to modernise. Everything else is fair game.
They also keep the content. A great deal of ranking and conversion value sits in text that looks unglamorous in a design review. Cutting it because it makes the layout busy is the single most expensive edit in a redesign, and it happens in almost every project unless someone actively defends it.
The last thing they share is a system rather than a set of pages. When the output is a consistent set of components and rules, the site can keep evolving after launch instead of ageing until it needs another full replacement in three years. That is the argument for building on a proper design system rather than a pile of one-off layouts.
None of this is glamorous, and all of it is what separates a redesign that pays for itself from one that just resets the clock. The underlying discipline is the same one behind designing for conversions.
Write down the one number that should be higher in six months. Export your top 20 pages by traffic and your top converting paths. Record your current Core Web Vitals. Then show your existing site to five people who have never seen it. That is a week of work and it will change the brief.
Most failed redesigns were decided before the first design was made, in the gap where nobody wrote down what they were trying to change. Closing that gap costs almost nothing and is the highest leverage thing you can do.
If you are about to start a redesign and want a second opinion on the brief before anyone commits, we are happy to look at it with you. Reach out at phoenix.studio and we will tell you honestly what we would do differently.
Tell us where you want to go. We'll tell you how we'd get you there.