UX Audit: Scope, Process, and Action Plan
Use a UX audit to find testable barriers across users, tasks, content, flows, access, speed, errors, data, support, business rules, evidence, priority, and ownership.
A UX audit is a bounded review of how well a site or product supports named users and tasks. It can find likely barriers and test needs. It cannot prove every cause or promise a higher conversion rate, sales result, rank, or return.
Define the Audit Question
Name the product, page, user group, task, and business goal.
Set the dates, devices, places, access needs, and exclusions.
List known faults, support issues, and prior changes.
Agree what data may be used and who may see it.
Set the output, budget, owner, and decision date.
Review More Than the Screen
Map entry, search, choice, form, payment, reply, and return paths.
Check content, labels, order, controls, errors, and recovery.
Review speed, mobile use, keyboard use, and access.
Read support logs, field data, search terms, and loss reasons.
Check rules, systems, staff, and handoffs behind the page.
Use Evidence With Limits
Separate observed faults from expert views and open questions.
State the test, sample, date, device, and data gap.
Do not treat one user or one metric as all users.
Join standards review with tests by suitable people.
Mark legal, privacy, security, and access checks for experts.
Turn Findings Into a Test Queue
Rank each issue by user harm, business effect, confidence, effort, dependency, and risk. Give it an owner, proof, fix option, test, and stop rule. Start with severe blocks and easy facts. Recheck after each release and record what changed.
For service scope, read UX Design Services. For a conversion symptom, use How to Fix Low Conversion Rates.
Set the UX Audit Question
Start each audit by naming the product, page, user group, task, and business goal.
Set dates, devices, places, access needs, and exclusions.
Agree on data use, output, budget, owner, and decision date.
Build the UX Test Queue
Rank each issue by user harm, business effect, confidence, effort, dependency, and risk.
Give each issue an owner, proof, fix option, test, and stop rule.
Start with severe blocks and easy fixes, then recheck after each release.
The Short Answer
Define the user, task, scope, evidence, and decision. Review the full path, access, speed, data, support, rules, systems, and handoffs. Rank findings by harm, proof, effort, and risk, then test fixes. A UX audit cannot promise a business outcome.
Need a UX audit brief?
TTGC can map users, tasks, scope, paths, evidence, access, data, findings, priority, tests, owners, and follow-up. Accessibility, privacy, security, and legal approval remain separate.
Sources
- Digital.gov: Usability testing. https://digital.gov/guides/research-collaboration/testing/usability
- Digital.gov: How to conduct a usability test. https://digital.gov/resources/how-conduct-usability-test
- World Wide Web Consortium: Involving users in evaluating web accessibility. https://www.w3.org/WAI/test-evaluate/involving-users/
- World Wide Web Consortium: Web Content Accessibility Guidelines 2.2. https://www.w3.org/TR/WCAG22/
- web.dev: Web Vitals. https://web.dev/articles/vitals
