Choose a UX audit when the team needs evidence about existing task problems and a prioritised set of findings. Choose redesign when the problem and intervention boundary are understood well enough to develop and test a changed experience. An audit and a redesign can be connected stages, but they should not be treated as interchangeable deliverables.
Let’s plan your UX improvement plan.
Bring your requirements and the decisions you need to make. We’ll help you clarify the scope, explore the trade-offs and plan the next step.
Identify the uncertainty behind the request
“The product looks old” and “users cannot complete onboarding” are different concerns. Gather observed failures, support records, user feedback and existing metrics before deciding the engagement.
State whether the team needs diagnosis, interaction alternatives, visual change or a broader operating-process review. A new interface cannot by itself resolve unavailable data, a broken integration or an unclear business rule.
Compare the starting points
| Situation | Starting work to consider | Useful evidence |
|---|---|---|
| Problems suspected but poorly understood | Audit and focused task research | Reproducible findings and uncertainty |
| Known task failure with a bounded cause | Targeted redesign | Tested interaction alternatives |
| Several roles affected by changed business rules | Workflow discovery and design | Agreed responsibilities and transitions |
| Visual inconsistency across teams | Component and system assessment | Repeated patterns and ownership gaps |
| Technical constraints prevent required behaviour | Combined design and engineering review | Feasible intervention options |
The table supports discovery, not an automatic buying rule. The product's evidence may justify a different sequence.
Define what the audit must produce
Request a finding tied to a task, supporting evidence, impact, confidence and proposed next action. Distinguish an observed failure from an expert hypothesis that still needs user validation.
An audit can recommend a change without supplying complete production designs. Specify whether prototypes, content changes or verification sessions are included so the engagement can be compared fairly.
Use a hypothetical onboarding case
Suppose users abandon a setup step. An audit may reveal that required credentials are held by another administrator. Redrawing the same form might not solve the authority problem.
Potential interventions include a request-for-access path, a different first task or a revised setup sequence. Evaluate the alternatives with the intended roles and the product's actual constraints. The example illustrates diagnosis and intervention, not a measured conversion improvement.
Scope redesign around states and evidence
Once a change is justified, include loading, empty, error, permission and recovery states. Use realistic content and define what engineers need to implement the behaviour.
Agree how the redesigned task will be reviewed. Before-and-after appearance alone cannot establish usability or business impact. Record the task, participants, assistance and limitations of the evaluation.
Plan the handover to implementation
Prioritise findings with product and engineering owners. Identify dependencies, unresolved questions and the smallest useful intervention. Keep the original evidence available so implementation does not lose the reason for the change.
Questions buyers ask
Does an audit always need to come first?
Not necessarily. If the problem and supporting evidence are already clear, focused design work may be appropriate. Confirm rather than assume that clarity.
Can a redesign guarantee better conversion?
No. Define and measure the intended outcome and investigate other changes that affect it.
Prepare the engagement brief
Bring task failures and what is already known. Use the UX audit deliverables guide, app redesign decision guide and UI/UX design overview.