UX audit, user research or redesign?

Name what you don’t know

“Users find the product confusing” is where most of these conversations start. It’s an observation, not a diagnosis. It might mean people can’t find a feature, don’t understand what it’s for, or don’t need it at all. Each of those calls for different work, and jumping straight to a redesign usually produces a nicer-looking version of the same problem.

So before choosing anything, we ask teams to fill in three columns: what we know, what we suspect, and what we need to decide. Put your evidence next to the first column. One support ticket shows that one person struggled. It doesn’t prove a widespread problem. A stakeholder’s opinion goes in the second column until something backs it up.

Once those columns are filled in, the right starting point is usually obvious.

When an audit fits

An audit works when there’s an existing journey to look at and a specific decision to make. Say your team has shipped a reporting flow, the same support questions keep coming in, and you need an outside view of where the friction probably is. A reviewer can walk through the journey, compare it with established patterns, weigh the evidence you already have and recommend what to tackle first.

Its strength is focus. Its limit is just as important: an audit can’t uncover every user need or prove why people leave. Where there’s no direct evidence from users, a good audit says so and flags what needs testing, rather than hiding the uncertainty behind confident scores.

When research comes first

Choose research when you don’t really understand the people, how they work, or the problem itself. Interviews show how a task fits into someone’s day. Watching people work reveals the workarounds they’ve built. Usability testing shows whether they can complete a task with your product or a prototype.

These answer related but different questions, and it’s worth picking the method that fits the question rather than the one your team happens to know. Here’s an example. Interviews might reveal that approvals are often shared between colleagues. Testing might then show that a new handover design hides the outstanding action. An audit could have flagged the hidden action as a risk, but it couldn’t have told you how people actually share the work.

When to move into design

Design becomes the priority once you understand the problem well enough to explore solutions. That doesn’t mean every question is settled. It means you can name the people, the task, the constraints and the assumptions the next design has to deal with.

“Make the dashboard modern” isn’t a design brief. “Give reviewers a faster way to compare requests, assign responsibility and chase missing information” is. With a brief like that, prototypes can test the risky decisions before anyone commits to detailed production work.

A quick routing check

There’s no compulsory order here, and you don’t need to buy all three. Ask what decision ends each stage and what evidence would justify the next. As a rough guide:

• The flow is difficult, but priorities are unclear: start with an audit.
• You don’t understand user needs or behaviour well enough: plan some research.
• The problem is understood and you need a new interaction: consider Complex Workflow Design.
• Your designers are doing the work but need an experienced second opinion: consider Design Leadership.

You can compare all four routes on the services page. An audit is one way in. It’s not a prerequisite for everything else.