[Optional opener: 1 or 2 lines about a real audit you ran. What the team thought was wrong, and what it turned out to be.]
A UX audit answers 2 questions. Where does your product lose people? And what should you fix first?
It’s worth doing when something feels off and nobody can say why. Sign-ups look fine, but people don’t come back. Or a redesign is coming, and you want to know what to keep before you change anything.
I run every audit in the same order. It usually takes [how long an audit takes, and for how many flows]. Here’s what happens in each part, and what your team gets at the end.
Understand the product and the goals
I don’t start with the screens. I start with the people who use them and what they’re trying to get done.
On the first call I ask questions like these:
- Who is the main user, and what should they get done in their first session?
- What does success look like for the business? More sign-ups, more paid plans?
- Which flows bring in money, or keep people coming back?
- What do you already know? Analytics, support tickets, old research, anything counts.
If people on your team give different answers to the first question, I write that down. It’s the first finding. An audit without a clear goal turns into a list of opinions, and nobody can act on that.
After the call I get access to the product (a test account is fine), your analytics and the design files, if you have them.
The output of this part is a short scope. It names the flows I’ll audit and what “working” means for each one. Usually that’s sign-up and onboarding, plus the one task the product exists for.
Walk through every main flow
Now I go through each flow the way a new user would, on desktop and on a phone. I take a screenshot of every screen and note every step, even the ones that feel too small to matter. They add up.
At each step I test the flow against basic usability principles. In plain words, I ask:
- Do I know where I am and what to do next?
- After I click, can I see what happened?
- Can I undo a mistake? Better yet, does the product stop me from making it?
- Does each button say what it does?
- Is the same thing called by the same name everywhere?
- Can everyone use it? Contrast, text size, tap targets and keyboard focus.
I also break things on purpose: a wrong password, a failed payment. Those screens are easy to forget in design, and users see them at the worst moment.
Every issue goes into one list with a screenshot, the step where it happens and the principle it breaks. I don’t fix anything yet. This part is only about collecting.
[Add a real example: a flow you audited, and the first issue you found in it.]
This part finds a lot. It also has a blind spot. It shows where people could struggle. It doesn’t prove that they do.
Find where users actually struggle
This is the step that turns a review into an audit. My walk-through finds problems. Data and testing show which of them cost you users.
I start with the numbers. In your analytics I look for the step where people drop out of a flow, and for screens where they stay much longer than they should.
Then I read what people say. Support tickets and sales call notes are full of friction. If the same question comes in every week, the product isn’t answering it.
Then I watch people use the product. I give a few people from your audience one task each, and I stay quiet. When they hesitate or go back, that’s friction. When they ask what something means, the copy failed.
Now the list changes. When the evidence matches an issue from part 2, that issue moves up. When the data shows a problem I missed, it goes on the list. And some issues I was sure about turn out not to matter much. They move down, and that’s fine. It’s why this step exists.
If the product is new and has no data yet, testing does this job on its own.
[Add a real example: a problem the data showed that the walk-through missed.]
Rank the fixes and hand over the plan
A long list sorted by screen helps nobody. Your team needs to know what to do first.
So I score every issue on impact and effort. Impact is how many people it hits and how close it sits to money or retention. Effort is how much design and development the fix needs.
After that, the order mostly writes itself. High impact and low effort goes first. These are the quick wins, often just a label or a missing state. High impact and high effort becomes a planned redesign. Low impact waits.
Quick wins matter more than they look. They ship fast, and they show your team that the audit leads somewhere.
In the plan, every issue is annotated: a screenshot, what’s wrong, why it matters and the evidence behind it. Each one gets a suggested fix and a place in the order, so your team always knows what comes next.
I deliver it as [the format you deliver in, like a Figma file, a PDF or a Notion page], and I walk your team through it on a call. Nobody should have to decode a document alone.
What happens after that is up to you. Your team can fix things in-house, or I can design the fixes with you.
Not sure where your product is losing people? Book a call and we’ll look at it together.
