An effective UX audit: a detailed checklist by area
An effective UX audit reviews a product area by area: navigation and structure, content and language, forms and inputs, visual design and hierarchy, feedback and errors, accessibility, performance, mobile experience and trust. Each issue is logged with evidence, scored for severity and effort, and turned into a short, prioritised report with clear recommendations.
Why use a checklist
UX audits can easily become inconsistent. One reviewer focuses on visual details, another on content, and important areas such as accessibility or performance get overlooked. A structured checklist solves this by making sure every audit covers the same ground, in the same order, with the same scoring. It also makes audits easier to repeat over time, so teams can compare results and track improvement. For the business case and process, see our posts on why a UX audit matters and running your first UX audit.
Before you start
- Agree the audit goals and the journeys in scope
- Collect analytics, heatmaps, support tickets and reviews
- Gather any previous research or audit reports
- Prepare a shared issue log with consistent fields
- Test on the main devices and browsers your users have
How to work through the checklist
Walk through each key journey as a typical user would, from the first page to task completion, checking every area of the list as you go. Take screenshots of anything that fails a check and note where it occurs. It helps to complete the walkthrough on a phone first, then on a desktop, since many issues only appear on smaller screens. If possible, have two people audit independently and compare findings, which reduces individual bias and catches more problems.
Keep the checklist as a starting point rather than a rigid script. Every product has its own risks, so add checks specific to your industry, such as identity verification for fintech, booking rules for healthcare or delivery information for retail.
Navigation and structure
| Check | What good looks like |
|---|---|
| Main navigation | Short, clearly labelled and consistent on every page |
| Current location | Users can always tell where they are |
| Search | Visible, tolerant of typos and returns useful results |
| Information architecture | Content grouped the way users think |
| Links | Descriptive link text; no broken links |
| Back and exit | Easy to return or leave any flow |
Content and language
| Check | What good looks like |
|---|---|
| Clarity | Plain language without internal jargon |
| Headings | Descriptive headings that support scanning |
| Calls to action | Specific, action-based labels |
| Microcopy | Helpful hints in forms and empty states |
| Consistency | The same terms used for the same things |
| Bilingual content | Arabic and English equally clear and complete where needed |
Forms and inputs
| Check | What good looks like |
|---|---|
| Number of fields | Only what is needed at this stage |
| Labels | Visible labels above fields, not placeholder only |
| Input types | Correct keyboards, pickers and autofill support |
| Validation | Inline, specific and timely error messages |
| Progress | Steps and progress shown for long forms |
| Recovery | Data kept when errors occur |
Visual design and hierarchy
| Check | What good looks like |
|---|---|
| Primary action | The main action stands out on each screen |
| Hierarchy | Size, weight and spacing guide the eye |
| Consistency | Components and styles match the design system |
| Readability | Comfortable font sizes and line lengths |
| Whitespace | Content grouped and separated clearly |
| States | Hover, focus, disabled, loading and error states designed |
Feedback and errors
- Every action produces visible feedback
- Loading states appear for slower actions
- Success messages confirm completed tasks
- Error messages explain what went wrong and how to fix it
- Destructive actions ask for confirmation or offer undo
Accessibility
Check colour contrast, keyboard navigation, visible focus states, labels for form fields and icons, alternative text for images, captions for video and support for screen readers and zoom. Use automated tools for a first pass, then test key journeys manually. Our guide to accessibility in UI/UX design explains the WCAG 2.2 criteria.
Performance and mobile
| Check | What good looks like |
|---|---|
| Loading speed | Key pages pass Core Web Vitals on mobile |
| Images | Compressed and sized for each screen |
| Responsive layout | No horizontal scrolling or tiny text |
| Touch targets | Large enough and well spaced |
| Mobile forms | Easy to complete on a phone |
| Offline or weak connection | Helpful messages and graceful behaviour |
Trust and credibility
- Clear contact details and support options
- Transparent pricing and fees
- Visible security cues on payment and data entry
- Genuine reviews and proof
- Clear privacy information and consent
Combining the checklist with data and users
A checklist finds potential problems; data and users confirm which ones matter most. Compare findings with analytics to see where users actually drop off, check support tickets for recurring complaints and run a few usability sessions on the most important journeys. Issues that appear in the checklist, the data and user testing together should go to the top of the list. Our guide to running a usability test explains how to add this step.
Scoring and prioritising
Log each issue with its location, a screenshot, the evidence behind it, a severity rating and an estimate of effort to fix. A simple four-level severity scale works well: cosmetic, minor, major and critical. Combine severity with effort to prioritise: fix critical, low-effort issues first, plan larger changes into the roadmap and group cosmetic issues into a later clean-up.
- Log: Record each issue with screenshot and evidence.
- Rate severity: Cosmetic, minor, major or critical.
- Estimate effort: Low, medium or high.
- Prioritise: Impact and effort together.
- Report: A short summary with top recommendations.
Frequently asked questions
What should a UX audit checklist include?
Navigation, content, forms, visual design, feedback and errors, accessibility, performance, mobile experience and trust.
How long does a checklist-based audit take?
For a few key journeys, typically one to three weeks including user testing and reporting.
Can we reuse the same checklist every time?
Yes. Reusing it makes audits consistent and lets you compare results over time, though you may add product-specific checks.
Is a checklist enough on its own?
No. Combine it with analytics and user testing to confirm which issues affect real users most.
Who should run a UX audit?
An experienced UX designer or researcher, ideally someone not involved in designing the product, so findings are objective.