Blog Overview
An audit is not a ninety-slide deck. It is a problem register built from five evidence sources, ranked by severity, ending in a written decision. Here is the full two-week plan.
Most redesign requests start with a screenshot and a complaint: “this does not look right” or “customers do not finish the order.” Two weeks of discussion later, the decision is either a full rebuild, a small fix, or nothing. The difference between those decisions does not come from taste. It comes from evidence someone can open and review.
An audit is the fastest way to turn a complaint into a ranked problem list, each item with its source, severity, and decision. This is the audit we run before touching a screen.
What an audit is for
An audit has three purposes. First, to find where users actually drop out, not where the team believes they do. Second, to set a baseline before any change: task completion, drop-off points, support contacts. Third, to create a shared language across product, design, engineering, and support, because each team sees the problem from a different angle.
What an audit does not do is prove that a redesign is necessary. Sometimes it finds that the problem is one error message, a returns policy, or a payment form that does not accept the way the customer pays. In that case, a full redesign wastes money.
If you are comparing the cost of an audit with a full design sprint, UI/UX design cost in Saudi Arabia explains the difference between the two scopes before you request a quote.
The evidence stack
We use five sources, and each has a blind spot. Analytics shows where drop-off happens, not why. Support shows what the people who contacted support complained about, not the ones who left silently. Sales shows buyer objections, not daily product use. Users explain the reason, but the sample is small. An interface review finds systemic barriers, not their size.
The strength comes from the overlap. If analytics shows drop-off, support repeats it, and a user explains it in a session, the hypothesis is strong. If it appears in one source only, it deserves a test, not a full budget.
The two-week plan
The plan below assumes analytics access and five to eight users. If one is missing, the days move, not the stages.
| Days | Work | Output |
|---|---|---|
| 1–2 | Kickoff, access, evidence inventory, stakeholder interviews | Audit plan, source map |
| 3–4 | Analytics funnel review, search logs, support tickets | First drop-off map |
| 5–6 | Five to eight moderated user sessions | Notes, clips, reasons |
| 7–8 | Interface review, accessibility check, RTL test | Systemic barrier list |
| 9–10 | Synthesis, severity scoring, prioritisation | Unified problem register |
| 11–12 | Prototype of the proposed fix, decision session, handover | Decision memo, next-step plan |
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
Severity, not a wish list
Every problem gets three scores from one to five: frequency, impact on the task, and confidence in the evidence. We multiply and rank. A problem that hits every user, blocks completion, and is supported by three sources is not the same as a cosmetic issue in a rare corner.
We use four classes: blocker, major, minor, and note. A blocker prevents task completion or causes a financial error. A major issue adds time or creates repeated confusion. A minor issue annoys without blocking. A note is recorded but does not enter the fix plan. Every item carries its source link, so the discussion does not collapse into opinion.
The final ranking is not a long list. We present ten problems in the first session only, because a team cannot fix forty items in one quarter. The first ten are the ones that change the outcome; the rest stay in the register for the next review.
What you receive on day twelve
Five files, no more: a one-page summary, a ranked problem register, a journey map with drop-off points marked, short clips from the sessions, and a decision memo that says what happens next week. The interactive prototype is optional in an audit and included in a design sprint.
The memo is the most important file. Without it, the audit is a report read once. With it, the audit becomes a decision with an owner, a date, and a measurement. If the decision-maker cannot attend the day-twelve session, we send the memo and ask for a written decision within two days.
What to do with the findings
Fix blockers first. Do not start with visual polish while a flow cannot be completed.
Assign an owner to every item. An item without a name is an item that will not ship.
Set a date and a decision. “Soon” is not a plan.
Measure before and after. Same event, same window, same segment.
Retest with new users. Do not use the team as a substitute for users.
Update the register. An item closes with evidence, not an impression.
Share the clip with the team. One clip is stronger than ten slides.
Defer what is not a blocker. Written deferral protects the launch date.
Frequently asked questions
Do we need analytics to start? It helps a lot, but it is not a precondition. Without it we rely on user sessions, support, and sales, and state in the report that effect size is unknown.
How many users are enough? Five to eight per segment. That is enough for recurring problems, not a statistical study.
Can you audit a competitor's product? Yes, within what is publicly available. A competitor will not give you access to their analytics or users.
Is accessibility included? Yes, against WCAG 2.2 AA, with manual keyboard and screen-reader checks.
What if we already know the problem? We test the assumed cause before building the fix. Many teams know the symptom and misdiagnose the cause.
Is an audit enough to start building? Yes if the scope is one flow. A full product needs definition and design after it.
Sources
- W3C: What's new in WCAG 2.2 — nine success criteria added on 5 October 2023.
- Baymard: checkout usability — 11.3 fields on average, and 22% who abandoned because of complexity.
- McKinsey: The Business Value of Design — why design deserves measurement, not opinion.
- UI/UX design and research at Rasad — how we run the audit and the design work.
