UX audit or website redesign? How to choose the next step

Start with a UX audit when you need to understand where people get stuck. Consider a redesign when the evidence points to problems across the site's structure, content and core journeys. A dated visual style alone gives you little information about either.

An audit investigates the current experience. A redesign changes it. They can belong to the same project, but choosing the change before understanding the problem makes the brief harder to defend.

Describe the task that is failing

“We need a better website” leaves too much open. Name the person, the task and the obstacle instead: a prospective customer cannot work out which service fits their needs; an applicant cannot find eligibility requirements; a mobile visitor cannot recover from a form error.

Separate what you know from what you suspect. A support request describes a reported problem. A recorded usability session shows what happened during that task. An analytics drop-off identifies a place to investigate, but does not explain the person's reason for leaving.

GOV.UK's usability-testing guidance describes observing actual or likely users attempting realistic tasks. Use neutral instructions so participants can show you how they approach the site.

When an audit is the useful next step

Choose an audit when the problem is unclear, when teams disagree about its cause, or when you need to decide which changes deserve attention.

A useful review follows a defined journey. Can someone find the relevant page, understand the content, take the next action and recover if something goes wrong? Examine navigation, labels, page hierarchy, interaction states and accessibility along that route.

At Zensite, our published UI/UX process includes research, reviewing existing interfaces, mapping flows and testing prototypes. That gives this decision a practical starting point: understand the current experience before deciding what to replace.

An expert review can identify likely usability problems. Keep those findings distinct from observed user behaviour. Where an important assumption remains untested, record the research needed to check it.

When focused repairs may be enough

Consider a focused repair when evidence points to a contained problem and the surrounding journey still works.

A confusing navigation label may need clearer wording. An error message may need to explain how to correct an entry. A service page may need its key information moved closer to the action it supports.

Check whether the proposed fix addresses the cause. Changing a button's colour will not explain an unfamiliar service. Rewriting an error message will not fix a broken submission.

After implementation, repeat the relevant task check. Keep a record of what changed and what you observed. Avoid calling the repair successful merely because it shipped.

When a redesign deserves consideration

A redesign becomes more plausible when problems share a wider cause: the navigation no longer fits the content, audiences need substantially different journeys, or repeated template limitations prevent necessary improvements.

Document why isolated changes would leave those problems unresolved. Identify what still works, too. Useful content, familiar interactions and discoverable pages should be deliberate preservation decisions.

A redesign still needs evidence and testing. New screens do not establish that people can complete their tasks. Test the proposed structure or prototype before carrying assumptions into the build.

A hypothetical example: the service enquiry journey

Imagine a website where visitors struggle to choose a service before making an enquiry. This is an illustrative scenario, not a Zensite client result.

If users understand the service categories but overlook an unclear next step, test a focused content or interaction change. If they repeatedly misunderstand the categories across several pages, investigate the information architecture before designing replacement screens.

Both paths start with the same task. The evidence determines how much of the experience needs to change. Neither path guarantees a particular result.

Write a brief that supports the decision

Before commissioning work, agree:

• The audience and task being examined.
• The pages, devices and interaction states in scope.
• The evidence already available and its limitations.
• The questions that still need user research.
• The technical and content constraints.
• Who will implement changes and check them afterwards.

Ask for findings that connect a specific obstacle to its evidence, likely consequence, proposed action and validation method. Prioritise obstacles that prevent important tasks, while making uncertainty visible.

The output should help your team choose a focused repair, a wider redesign or further research. If you are preparing that decision, explore Zensite's UI/UX design approach and start your brief with the task people need to complete.