What each one is
A UX audit is an examination of the product as it is. A specialist walks through the main journeys, reviews the analytics and support tickets, checks the interface against usability and accessibility principles, and ideally watches a few real users. The result is a ranked list of problems, each with evidence and a recommended fix.
A full product redesign reconsiders the interface from its structure upward. Navigation, page layouts, key flows and the visual language are designed again, and then built. Little of the old interface survives, though the features and the data usually do.
The two at a glance
| UX audit | Full redesign | |
|---|---|---|
| Question it answers | What is wrong, and what should we fix first? | What should this product look and work like now? |
| Output | A ranked report with evidence and recommendations | New designs, a prototype and then a rebuilt interface |
| Scale of change | Targeted fixes to existing screens | Most screens change |
| Effect on users | Familiar product, fewer obstacles | A new product to learn |
| Time before benefit | Short. Early fixes can ship while the report is still fresh | Long. Benefit arrives when the new interface is released |
| Risk | Low. Changes are small and measurable | Higher. Regular users may resist, and scope tends to grow |
| Cost | Modest and fixed | Large, and often underestimated |
| Needs from you | Access to the product, data and a few users | Sustained involvement from product, design and engineering |
When each one fits
An audit fits when
- Users complete their tasks but complain or drop out at certain steps
- Opinions inside the company differ about what is wrong
- You need evidence before asking for a larger budget
- The product's structure still matches what it does
- Regular users would be upset by a sudden change
A redesign fits when
- Features were added for years and the navigation no longer makes sense
- The product looks dated beside competitors and loses deals for it
- The business has changed and the interface serves the old model
- An audit found problems in nearly every journey
- The front end must be rebuilt anyway for technical reasons
What a useful audit delivers
- Findings tied to evidence. A screenshot, a recording, a number from analytics or a quote from a user, for each problem.
- Severity. Which problems stop people, which slow them and which only annoy.
- A recommended fix for each. Specific enough for a designer or developer to act on.
- Quick wins marked. Changes that can ship in the next release.
- Accessibility results. Where the product fails common guidelines, and how to repair it.
- A view on structure. Whether the navigation and information architecture are sound, which is what tells you if a redesign is needed.
A report that lists opinions without evidence, or that recommends a redesign without showing why fixes would not do, is not worth much. Our UX audit page shows what ours contains.
The risks of a redesign
A redesign is sometimes necessary and often worthwhile. It is also where product teams lose the most time, for four recurring reasons.
- Familiarity is lost. People who use the product daily have learned its quirks. A new interface, even a better one, slows them at first.
- Scope grows. Once everything is open for change, every stakeholder adds a wish.
- Nothing ships for a long time. Value arrives only at release, and problems known today stay unfixed until then.
- Old features go missing. Small behaviors nobody documented are discovered only when users report them gone.
The answer to all four is the same: redesign in stages. Take the journey the audit ranked worst, redesign and release it, measure, then take the next. Our comparison of a website redesign and a full rebuild applies the same thinking to websites.
A worked example
An invoicing tool and a property platform
Both products are invented.
- The invoicing toolCustomers like it, but a third of new sign-ups never send a first invoice. The team argues about why.
- Its decisionAn audit. It found that the setup asks for tax details before the user has seen any value, and that the send button sits below the fold on laptops. Two fixes shipped within the month.
- The property platformBegan as a listings site and now handles viewings, contracts and payments. Each was bolted onto the menu as it arrived, and new staff need a week of training.
- Its decisionA staged redesign, starting from an audit that mapped every journey. Navigation was rebuilt around the three things users come to do.
The invoicing tool had two obstacles. The property platform had outgrown its own structure. The audit told each of them which case it was.
A checklist to decide
Tick what is true. The first four point to an audit and fixes. The last four point to a redesign, ideally after an audit.
Audit or redesign
0 of 8 checkedWhat to do next
If you cannot yet state the three biggest problems in your product with evidence for each, begin with an audit. If you can, and they are structural, plan a redesign in stages. Either way, show us the product and we will give you a first impression of which case you are in.
Common questions
Will a UX audit just tell us to redesign everything?
A good one will not, unless the evidence demands it. Most audits find a small number of serious obstacles and many minor ones, and most of the benefit comes from fixing the serious few. When an audit does recommend a redesign, it should show which structural problems cannot be solved by fixes and which parts of the product are sound and worth keeping.
Can a product be redesigned in stages?
Yes, and it is usually the safer way. Introduce the new visual language through a shared set of components, then redesign one journey at a time, starting where users struggle most. Old and new screens coexist for a while, which is a little untidy, but users adapt gradually and each release proves or disproves the direction.
How do we measure whether either worked?
Decide the measures before any change. For an audit's fixes, track the specific steps it flagged: completion of sign-up, time to finish a task, error rates, related support tickets. For a redesign, use the same task-level measures and add satisfaction scores from regular users. Compare like with like over the same period, and expect a short dip after a large change.
Does an audit need research with real users?
It is much stronger with it. An expert review finds many problems alone, but watching even a handful of real users attempt real tasks shows which problems matter and often reveals ones no expert predicted. Where recruiting users is hard, recordings of real sessions and support conversations are a workable substitute for part of it.