# How to Conduct a UX Audit

Source: https://www.jvds.cn/en/share/ui-design/ux-audit-guide
Language: en
Published: 2026-09-26
Author: JVDS Design Studio

Many teams have commissioned a so-called UX audit or experience review and received an eighty- or ninety-slide presentation listing 120 issues. A button corner radius being 2px off sits alongside an overly long registration flow. Business stakeholders and engineering leads finish reading it baffled: “We have two weeks in the schedule. Which of these 120 issues do we fix first?” The report ends up gathering dust in a shared drive.

When we help clients with [UI/UX product design](https://www.jvds.cn/en/service/uiux) and legacy-system diagnosis, we follow a practical rule: **do not discuss whether an interface looks good in isolation from business data, and make every audit identify the top 5 bottlenecks affecting the core metrics**.

## Step one: find where the most users drop out, then review the interface with specific questions

![Artwork](https://www.jvds.cn/upload/2026/0824/1787562649832-108916.webp)

If you do not even know which page loses users, taking screenshots of everything and finding faults can easily become an exercise in the designer's personal preferences. Before the walkthrough, pull basic data from the past 30 days—even if it is only Baidu Analytics, a GA4 funnel, or order-status statistics from the backend:

- **For a corporate or independently operated website**: Focus on bounce rates for high-traffic landing pages, average time spent in the product catalog, and the completion rate from opening the contact page to actually submitting the form.
- **For a SaaS product or app**: Focus on the activation funnel from first registration and login → completing onboarding → using the core feature for the first time, together with the recurring errors users complain about most in support tickets.

## Step two: walk through complete tasks as a real user and note the hidden friction

![Artwork](https://www.jvds.cn/upload/2026/0824/1787562649832-267932.webp)

With those data clues in hand, stop looking at pages as an insider who already knows the system. Step into the position of a **real external user encountering the product for the first time with only a few spare moments**, and run through 2–3 main tasks from beginning to end:

1. **Can users connect the information to their needs within 5 seconds?** Someone arrives with a specific question. Does the first screen use plain language or internal jargon? Do the navigation categories match their intuition?
2. **Are there breaks in the sequence of actions?** For example, when reviewing documents in a business system, must users open two browser tabs and keep switching to compare figures? When completing a mobile form, does one incorrect field force them to fill in the entire page again?
3. **Are edge states handled properly?** When a search returns no results, the network is slow, or permissions are insufficient, does the interface provide a clear next step or simply an empty page?

## Step three: prioritize changes with a four-level severity scale

![Artwork](https://www.jvds.cn/upload/2026/0824/1787562649832-687619.webp)

So that the development team can start scheduling improvements the day after receiving the findings, we divide all identified issues into four severity levels rather than treating everything equally:

| Severity | Criteria | Typical examples | Recommended timeframe |
| --- | --- | --- | --- |
| **P0: Critical blocker (Blocker)** | Prevents completion of a core task or causes users to leave directly | A floating bottom panel covers the mobile submit button; required-field error logic gets stuck in a loop; a core quotation page returns 404 | **Hotfix within 24–48 hours** |
| **P1: Serious friction (Major)** | Users can work around it, but it causes clear hesitation, rework, or high abandonment | Product selection lacks key parameter filters; a form has 15 fields without steps; selections disappear when moving between pages | **Prioritize restructuring in the current two-week iteration** |
| **P2: Usability flaw (Minor)** | Adds cognitive effort without directly blocking the main workflow | Weak chart color contrast; lists lack empty-state explanations; modal confirmation buttons switch left/right positions between pages | **Address alongside routine release updates** |
| **P3: Visual polish (Cosmetic)** | Detail alignment and minor aesthetic adjustments | Inconsistent card padding; icon strokes differ by 0.5px; font-weight hierarchy is insufficiently clear | **Incorporate into shared component library guidelines** |

A UX audit should never end with a pile of criticisms. It should include before screenshots and proposed after wireframes for the P0 and P1 issues. Turn complaints into drawings developers can act on directly, and the diagnosis becomes something the team can actually implement.