A UI/UX audit that ends in a fix list, not a slide deck
A structured review of the product you already have — where people hesitate, what is causing it, and what to change first — delivered as a prioritised list your team can start on next sprint.
What you get
- Heuristic review of the flows and screens that carry the most traffic
- Findings written up with the screen, the problem and the reason
- A prioritised fix list, ordered by impact against effort
Most redesigns start as an audit question
"Should we redesign?" is almost never the real question. The real one is which parts of the product are costing you users, and a rebuild is an expensive way to find out — it changes everything at once, including the parts that were already working.
An audit separates the two before any money goes into design. Plenty of them end with a handful of targeted changes rather than a redesign, which is a good outcome even though it is the smaller invoice.
Every finding carries its reason
A finding names the screen, shows it, describes what a user is likely to do there and why that is a problem. Without the reason it is just taste, and taste is the easiest thing in the world for a stakeholder to overrule.
That also makes the list arguable in a useful way. If your team disagrees with a finding they can disagree with the reasoning rather than with an opinion, and sometimes they are right — they know constraints an outside reviewer does not.
Prioritised, because everything cannot be first
Findings are ordered by what they cost you against what they cost to fix. A contrast failure in the primary button and an inconsistent icon set are not the same urgency, and a flat list of forty issues gets read once and filed.
The top of the list is deliberately short: the few changes worth doing this month. Everything else stays on the list for when there is room.
What it costs
Quoted individually
An audit is quoted against the size of what is being reviewed — how many flows, how many screens — rather than from a package, because a five-screen product and a fifty-screen one are not the same read.
Compare all packagesCommon questions
How is an audit different from a redesign?
An audit diagnoses; a redesign treats. The audit tells you what is wrong and what it would take to fix, and it is deliberately useful on its own — your own team can act on the list without me. A redesign is a separate, larger piece of work that some audits recommend and many do not.
Do you audit the code and page speed as well?
Not in this one. This audit covers the interface and the flows: structure, hierarchy, states, copy and usability. Core Web Vitals, load performance and WCAG accessibility testing are a separate technical audit, and the two are often booked together because they answer different halves of the same complaint.
Do you fix what the audit finds?
If you want me to, as a separate scoped piece of work. There is no obligation and no discount tied to it — an audit that exists to sell a redesign is not an audit, so the deliverable is written to be useful in the hands of a team that never hires me again.
Other services in this area
Already have the design, and need it built? Custom development
Have a project in mind? Let’s talk.
Get in touch