Do You Need a Website Redesign? Start With a Usability Audit

Don't redesign what works.

THE IMPULSE

"It Needs a Redesign"

There is a moment in almost every website project when someone opens the existing site, looks at it for thirty seconds and says: "It needs a redesign."

I have done that myself.

Often the verdict is fair. The site looks dated, the mobile version is broken, the navigation confuses people, the typography has no hierarchy, and the whole thing feels like it belongs to another era of the internet. But over the years I have become much more careful with that first impression. Thirty seconds of looking is not enough to decide the fate of a digital product that may have served a business for years.

So the question I try to ask first has changed. It used to be whether the website looks old. Now it is whether the website actually has a problem, and if it does, where that problem lives.

In short

• A website that looks dated is not necessarily a website that fails. Before deciding on a redesign, look at what people actually do on it: analytics, heatmaps, session recordings.
• A usability audit should end in a decision, not automatically in a new website. Sometimes the right answer is a full rebuild. Often it is a careful fix, new code under a familiar interface, or nothing at all.
• We have reached the "leave it alone" conclusion on our own sister studio's website, and on a client site we would happily redesign for the portfolio.
• When a rebuild is justified, the old site still matters: it is the best research material the new one will ever have.
• A usability audit at Peretz starts at $1,500. A redesign we talk you out of costs nothing.

BEHAVIOR

Start With Behavior, Not the Screen

The traditional redesign process is surprisingly simple. Someone opens the existing website. A designer points out what looks outdated, a marketer points to what competitors are doing, the owner says it feels old. Then someone opens Figma.

I don't think that is enough anymore. Before we decide what to redesign, we want to know what is happening on the site right now. We go through the analytics, then the heatmaps and scroll maps, then the clicks, including rage clicks and dead clicks. Then we watch real sessions in tools such as Microsoft Clarity, one person at a time, and try to understand the context behind what they did.

These are three different layers of information. Analytics tells us what happened. A session recording shows what a person actually did. Usability analysis tries to explain why they did it.

The layers can disagree, and that is where it gets interesting. Four minutes on a page could mean someone read the content carefully. It could also mean they spent four minutes hunting for a phone number we buried between a giant hero image, an animation and three promotional blocks. The number in the report is identical. The experience behind it is the opposite.

BEAUTIFUL

When a Beautiful Page Fails

Once you start watching real sessions, one thing becomes obvious quickly. A page can look incredibly polished, with perfect typography, beautiful animation and immaculate spacing, and the visitor can still have no idea what to do next.

Recordings show things a static mockup never will. A visitor clicks three times on something that looks like a button but isn't one. Someone scrolls straight past the block we considered the most important on the page. Someone opens and closes the menu four times, then gives up. Someone reaches the footer, scrolls all the way back to the top and leaves, because what they came for was never there.

None of this shows up as a dramatic failure in a standard analytics report. Bounce rate may look normal, time on page may even look good. Put together, though, these small moments tell a story, and that story is usually more useful than another meeting about whether the hero section should be darker.

A page can look finished and still leave the visitor lost.

DEZZIGN

The Redesign We Talked Ourselves Out Of

Our own sister studio is the most honest example I have, because nobody had to convince us of anything. DeZZign designs architecture and interiors, and its website is ours.

When you work in design, you develop a professional illness. You see new websites every day: new grids, new typefaces, video, motion, WebGL, beautiful editorial layouts. Then you open your own site and think: maybe it's time.

There is plenty we could do with DeZZign visually. A more dramatic first screen, video, a completely rebuilt visual language. It would look more contemporary, and I would enjoy designing it.

Then we looked at the site as a working business tool rather than a design object, and the question became much less exciting: what exactly would we be fixing?

The site is simple and understandable. People find what they came for, and it loads fast. Clarity shows no usability crisis: almost no rage-click patterns, nothing that suggests visitors are fighting the interface. I won't publish the exact figures, but nothing in them points to a problem a redesign would solve. The basic job gets done.

So why rebuild it? Because we are tired of looking at it? That is not a business case. The more we looked, the clearer it became that the same money and time would do more as new projects, content and promotion.

That is a slightly uncomfortable conclusion for a design agency to reach about its own studio. I think it is an important one.

Sometimes the person who wants the redesign most is the designer.

THE INSTITUTE

When the Data Argues With Your Eyes

The Institute of Trichology is a different version of the same problem, with higher stakes.

Look at the site purely through a contemporary design lens and you can imagine a very different product: a new visual system, a large video hero, more motion, a cinematic presentation. It could look fantastic.

Then you look at what is actually happening. The site loads quickly. The main journeys work, from a symptom to the right department, the right doctor and an appointment. The behavioral picture in Clarity is healthy, and the visual identity has aged surprisingly well.

So the honest question is whether a new website would help the patient more. We don't know that. We know a new site would look newer. Whether it would work better is a separate claim, and nobody has evidence for it yet.

A new website would look newer. That doesn't mean it would work better.

Medicine raises the bar

A medical website carries a different responsibility from a fashion brand or a hotel. The person arriving may be worried, or in pain. They may not know the right terminology, and they may be searching late at night because something is wrong. Their priority is an answer: what this could be, which specialist to see, how to book, where to go.

There is nothing wrong with video, storytelling or brand presentation on a clinic's site. There has to be a hierarchy, though. If a patient meets a large promotional film and several screens of brand messaging before finding the booking link, we have optimized the wrong thing. A medical website should be judged by how quickly it helps the patient, not by how long it keeps them on the page.

UNDER THE HOOD

New Code, Not a New Identity

There is an old engineer's rule: don't interfere with a machine that is already running. If the engine works, the car moves and the brakes hold, you don't take the whole thing apart because you dislike the paint.

Websites are similar, with one important caveat. Leaving the interface alone doesn't mean leaving everything untouched. Quite often the part that needs work is under the hood.

A site can feel old because its frontend is old. The CSS may have become impossible to maintain, components may have grown without any system, the CMS may block what the business needs to do, and the backend may be several framework versions behind. Accessibility and performance may need serious work. None of this automatically requires throwing away an interface that people already understand.

The smarter move is often to keep what works for users, the information architecture and the journeys that convert, and rebuild what sits underneath: the code, the frontend where it is brittle, the parts that have become technical liabilities. We describe how that looks in practice in Upgrading an Old Laravel or PHP Site.

Good engineering of this kind is almost invisible. Visitors don't know you replaced half the system. They notice that the site feels faster, more stable and easier to use, and that is enough.

WHEN TO REBUILD

When a Rebuild Is the Right Call

None of this is an argument against redesigns. There are situations where rebuilding is clearly the right decision, usually when the technology itself has become the constraint. A company moving from WordPress to a custom platform is changing far more than colors and typography. A company moving from OpenCart to its own commerce architecture may be changing how its entire business works online.

A furniture catalog we built a few years ago went the other way. It was designed as a presentation: each product page worked more like a small landing page, with large photography and a story, than like a product card, and there was no way to buy. Both the data and the people told us it wasn't enough. Visitors were leaving from the product pages, at the very point where they had found something they wanted, and the client's sales managers kept hearing the same thing on the phone: customers wanted a proper product card and a way to order online. Here the audit said rebuild, and we turned the catalog into an online store.

That project is also why, back when most of our sites ran on ready-made platforms, we often built catalogs on OpenCart and simply switched off the store features a client didn't need yet. The site looked and worked like a catalog. When the business was ready to sell, adding the store was a small project rather than a new website.

Even then, the old website should not simply be thrown away. It knows things nobody wrote down: which pages mattered, which journeys worked, what people searched for, where they clicked and what they kept trying to do. That makes it research material for the new one. We don't have to keep its design, but we should understand its behavior before we replace it. The same logic applies at a larger scale when two companies merge, as we describe in What Happens to the Website After an Acquisition?

TASTE

"I Would Do It Differently" Is Not a Method

Designers have opinions; that is part of the job. I have plenty. I can look at a page and know immediately how I would structure it. Sometimes I'm right, and sometimes I'm not.

The trouble starts when personal taste is treated as evidence. "I would move this button." "I would make the hero much bigger." "I would remove this section." Each of these might be an excellent call, but until real visitors meet it, it is a hypothesis.

That is what a usability audit is for. It doesn't replace professional judgment. It gives that judgment something to argue with, and occasionally that is exactly what a designer needs. The same discipline applies to brands, which we wrote about in When Not to Rebrand, and to the design work people shouldn't even notice, in Design You Don't Notice.

MACHINES

Structure for People, Readable by Machines

There is another reason this matters more now than a few years ago. Humans are no longer the only readers of a website. Search engines crawl it, AI systems retrieve answers from it, and AI agents increasingly use it to understand what a company does.

The tempting response is to put more of everything everywhere: more text, more sections, more keywords. I think that easily makes a site worse for both audiences. Nobody arrives on a page asking to see everything an organization knows. They arrive with a specific intention: what is this, can you help with my problem, how does it work, what does it cost, can I trust you, what do I do next.

A page that walks a person through that logic is also the page a search engine or an AI system interprets most easily. We shouldn't write websites for AI. We should structure information so that its logic is clear, to a person first and to a machine as a consequence. We explain why visibility work amplifies a good site rather than rescues a weak one in SEO, AEO and GEO Are Amplifiers, Not Engines.

INTENTION

The Real Unit of Usability

The simplest way I can describe what we look for in an audit is the distance between what a person came to do and what the interface makes them do.

If someone wants to book an appointment and has to dig through the site to find the right path, that distance is friction. If someone wants to understand a service and has to watch a three-minute video before getting a plain answer, that is friction too. So is a clinic that hides whether it treats your condition under marketing language, or a store that makes it hard to compare two products side by side.

Some friction is intentional: a confirmation step before a payment, a form that asks one extra question to route a request correctly. Most of it isn't. Telling the two apart is the job.

THE AUDIT

What an Audit Actually Produces

This is where the word "redesign" becomes misleading. A usability audit shouldn't automatically produce a new website. It should produce a decision.

In practice we combine three sources: analytics for what happened, heatmaps and session recordings for what people did, and an expert review of key pages and journeys for why. If a site has no behavior recording yet, the first step is to install it and let real sessions accumulate before anyone draws conclusions. The result is a short written report: where people struggle, how much it costs the business, and what we would change first.

The decision at the end usually lands on one rung of this ladder, from the smallest change to the largest:

Every one of these is a legitimate outcome. The audit doesn't exist to justify a project. It exists to tell us which project, if any, is justified. A usability audit at Peretz starts at $1,500.

WHY WE SAY IT

What Kind of Agency Writes This?

You might reasonably ask why an agency that earns money on redesigns would publish an article about not redesigning. It's a fair question.

We outgrew that model a long time ago, the one where managers have to sell services so the agency can make its month. Today Peretz works more like a network of senior specialists. Some of them work at the level of M&A and technical due diligence. Others run their own businesses and products, so they know from the inside what it feels like to spend money on something that doesn't pay back. What holds us together is process and quality, and we look for clients who chase the same things we do: quality and results.

So we approach a business the way a good doctor approaches a patient. First the examination, then the diagnosis, and only then the treatment. Very often the treatment turns out to be a different service from the one the client came asking for, and we run into this almost every day: a strategy session instead of a new website, new code instead of a new design, a fix in the sales process instead of a redesign.

We do redesign websites, rebuild them and replace entire platforms, when the examination says that is what will solve the problem. A redesign sold to someone who didn't need it makes for an expensive project and a short relationship. An audit that says "not yet" is a small project, and often the beginning of a long one.

BEFORE FIGMA

The Question Before Opening Figma

There is a strange pressure in digital design to keep replacing things. A five-year-old website is automatically "old", a seven-year-old one is "outdated", and when a competitor launches with a giant video hero, everyone suddenly wants one. Visitors don't experience websites as screenshots in a portfolio, though. They use them as tools, with a goal in mind, and a familiar, clear and fast interface that gets changed only because it looks older can create problems that didn't exist before.

I still love designing new websites: the blank canvas, finding a new visual language, watching a product turn from an old interface into something new. But I'm increasingly convinced the first question shouldn't be what the new website should look like. It should be what people are actually doing on the current one, where they struggle, and what the smallest meaningful change is that would solve it.

That answer might be a completely new website or a new frontend. It might be better code behind the same interface. It might be nothing more exciting than a developer fixing what was broken under the hood. That's fine. The purpose of a website is to help a business and the people who use it, not to prove that we can redesign it.

So before we change the bodywork, we should probably check the engine.

Don't redesign what you haven't understood.

FAQ