What a UX audit is, and what it is not
A UX audit is a review of how people use your product, done by someone who has not been staring at it for two years. They walk through your main flows, read your numbers, and tell you where users get stuck and why.
It is not a redesign. It is not a round of user interviews. It is not an opinion on your brand colors. It is a diagnosis. The output is a list of problems, ranked, with a clear suggestion for each.
We think an audit is only worth paying for if it ends in a fix list your team can start on the same week. Everything else in this post follows from that.
What we review
When we run a UX audit, we look at three things. Each one answers a different question.
1. The flows
We pick the paths that matter most to the business. For a SaaS product that is usually sign-up, the first session, the main task people come to do, and the step where someone pays or upgrades. We walk each path ourselves, as a new user would. We write down every place where we hesitate, click the wrong thing or have to guess.
2. The numbers
If you can give us read-only access to your analytics, we look at where people leave. A funnel tells us which step loses the most users. Event data tells us which buttons get used and which get ignored. Numbers show where the problem is. They do not show why, so we always match them against what we saw on screen.
If you have no analytics yet, that is fine. The audit still works. The report is just less data-led, and we say so.
3. The screens
We check the screens against well-known usability rules, such as the ten heuristics Jakob Nielsen published in the 1990s. Are labels clear? Does the product tell you what happened after you click? Can you recover from a mistake? Is the same thing called the same name everywhere? These are old rules, and products still break them every day.
We also look at the less exciting parts: error messages, empty states, loading states, settings pages. These are where trust gets lost.
How findings get ranked
A list of forty problems is not useful. Your team cannot fix forty things, and it will argue about the order. So we rank every finding on two axes: how much it hurts users, and how hard it is to fix.
| Impact | Effort | What we tell you |
|---|---|---|
| High | Low | Do this first. Often a label, a button position or a missing message. |
| High | High | Plan it. Usually a flow that needs redesign and some engineering time. |
| Low | Low | Do it when someone has a free hour. |
| Low | High | Leave it. We tell you plainly that it is not worth the cost now. |
That last row matters. A good audit tells you what not to fix. Teams lose weeks on polish that no user ever noticed.
What the final report and call look like
In our audit, you get a written report, a short list of quick wins, one key screen redesigned, and a 45-minute walkthrough call. Here is what we put in each finding:
- Where it is. The screen or step, with a screenshot.
- What we saw. One or two plain sentences, with the number from your analytics if we have one.
- Why it matters. What the user is likely thinking or doing at that moment.
- What to do. A specific change, not a general principle.
- Impact and effort. The two ratings from above.
We redesign one key screen so you can see what a fix looks like in practice. Words in a report are easy to agree with and hard to picture. A real screen makes the direction clear, and it gives your developers something to build from.
The call is for questions and push-back. You know your users and your code. If we got something wrong, or a fix is harder than it looks, we want to hear it on the call, not three weeks later.
How to tell a good audit from a long PDF
We have seen reports that run to eighty pages. They are thorough, and nobody acts on them. Here is what to check before you buy, or when you read the result.
- Can you start on Monday? If the report ends in themes like "improve clarity", it is not ready to use. Each finding should name a screen and a change.
- Is it ranked? If everything is marked "important", nothing is.
- Does it use your data? A report that could be about any product is a template. Look for your page names, your step names and your numbers.
- Does it show, not only tell? At least some of the fixes should be drawn out.
- Is there a person to talk to? A report with no walkthrough leaves you guessing what the author meant.
- Is the price fixed? You should know the cost and the time before it starts. Ours is $950 and one week.
When an audit is the wrong first step
Sometimes we tell people not to buy one. Here are the cases we see most.
You have no product yet. There is nothing to audit. If you have an idea or a rough prototype, you need to decide what to build, and that is a design sprint, not a review.
You already know the problem. If your team agrees that the onboarding is broken and has a plan, an audit adds little. Fix it, and bring us in later if it does not work.
You need to hear from users. An audit is an expert review. It cannot replace talking to people who use the product. If the question is "why did customers cancel?", interviews will tell you more.
The product is about to change a lot. If you are rebuilding the app next month, audit the plan, not the old screens.
Nobody can act on the results. If there is no developer time in the next few weeks, the list will sit there. Wait until there is.
Where an audit fits with the rest of our work
For many teams, the audit is the cheapest way to try working with us. If you start an MVP design sprint within 30 days, we credit the audit fee toward it. You can also take the list and fix everything yourself. Both are fine. You can read how we run every project on our process page, and see who we work with on the SaaS design agency page.
If you are not sure an audit is the right step, send us one page or flow through the free design review on the contact page. We will tell you what we see, and whether a full audit would help.
