Process · 26 May 2026 · 5 min read

The best redesign starts with what still works

Why useful redesign work begins by preserving the parts of an existing product that are already earning their keep.

A redesign should not begin with a bonfire. It should begin with the slightly less dramatic question: what here is already working?

That question sounds obvious until the project gets emotional. A site or product reaches the point where everyone can see the friction. The navigation feels tired. The interface has accumulated exceptions. The copy is carrying assumptions from three versions ago. Someone says “redesign” and the room quietly imagines a clean sheet of paper.

Clean sheets are appealing because they do not have history on them. Unfortunately, history is where most of the useful evidence lives.

The old thing knows things

An existing product has already survived contact with real people. That makes it more valuable than a perfect concept sketch.

It knows which page still gets searched for by name. It knows which awkward field is there because one customer type genuinely needs it. It knows which tiny bit of copy reduces support emails, even if nobody remembers who wrote it. It knows the difference between a surface mess and a load-bearing mess.

The job is not to worship the old thing. Plenty of old decisions deserve to go. But if the first move is to treat everything as failed, you throw away the product’s memory before you understand it.

Redesign notes


            audit:
          
            keep: known search terms
          
            keep: support microcopy
          
            change: manual workaround
          
            remove: dead campaign page
          
            watch: return-user path
          

A redesign has two responsibilities

The visible responsibility is improvement. Make the product clearer. Make the interface calmer. Reduce the little moments where the user has to stop and decode what the site means.

The quieter responsibility is continuity. Keep the parts people already trust. Preserve the URL that still earns its place. Keep the familiar path if changing it would mostly satisfy the designer and punish the regular user.

This is where redesign work becomes less glamorous and more useful. You are not just making a new visual system. You are deciding which promises the old product was already keeping.

Some rough edges are evidence

I like looking at the rough bits before I look at the polished ones. The rough bits often explain the real system.

A confusing form might reveal that the business has three different intake paths pretending to be one. A crowded homepage might reveal that the organisation has never agreed what it is actually selling. A strange filter label might be the only plain word users understand in an otherwise tidy interface.

When you remove those things too quickly, the product may look better and work worse.

Good redesign is partly restraint. It is knowing when a rough edge is noise, and when it is a visible symptom of something the new version still needs to handle.

The audit should be practical

Before changing the shape of a product, I want a plain inventory:

  • pages that still earn attention
  • paths that people use even though they are ugly
  • copy that answers a real objection
  • features that exist because of support pain
  • data fields that look odd but carry operational meaning
  • broken or stale areas that can safely disappear

That list is not strategy theatre. It is a way to stop the redesign from becoming a mood board with a login form attached.

It also makes decisions easier. If a piece of the old product is useful, keep the value and improve the expression. If it is not useful, remove it without sentiment. If nobody knows, test it in the smallest honest way before pretending the new version has solved it.

Improvement should feel earned

The best redesigns I have worked on do not feel like costume changes. They feel like the product finally became clearer about itself.

The same purpose is there, but the dead ends are gone. The same audience is served, but the language has less residue on it. The same work is being done, but the interface no longer makes the user carry the system’s uncertainty.

That kind of redesign starts by admitting the old thing was not only a problem. It was also a teacher.

The rebuild is part of the work gets at the same idea from the other side: sometimes the first version has done its job by revealing what the next version needs to become. The trick is carrying the learning forward, not just replacing the evidence with a cleaner-looking guess.