A UI/UX audit is a structured evaluation that identifies, validates, and ranks usability problems against business goals, and the concrete deliverable is a prioritized list of issues, backed by evidence, paired with recommended fixes and metrics to confirm they worked. This guide walks through the full workflow: setting scope, gathering quantitative and qualitative evidence, running a heuristic evaluation, checking accessibility against WCAG 2.2, and turning findings into a report your team can act on.
TL;DR:
- Conduct a task-specific or funnel-focused audit when KPIs like conversion or retention decline, rather than a full site review every time.
- Define clear, measurable usability goals linked to business KPIs before testing screens to ensure prioritized fixes and avoid scope creep.
- Use quantitative analytics, heatmaps, and session replays to identify where problems occur and validate root causes before manual review.
- Prioritize findings based on severity and impact, addressing high-impact, low-effort issues immediately, and schedule complex fixes strategically.
- Incorporate WCAG 2.2 accessibility checks into the audit with simple tests like keyboard navigation and contrast assessment to improve usability for all users.
Table of Contents
- When should you run a UX audit?
- Define scope, objectives, and measurable usability goals
- Collect quantitative data: analytics, funnels, heatmaps, and session replay
- Run a heuristic evaluation using Nielsen's heuristics
- Qualitative research: usability testing, interviews, and session replay analysis
- Synthesize and prioritize findings: severity ratings and impact × effort
- Write an actionable audit report and present to stakeholders
- Accessibility checks to include (WCAG 2.2) and simple tests you can run
- Tools, templates, and a repeatable checklist you can copy into your workflow
- Requestum's approach: how a delivery team runs an audit and turns it into product outcomes
- Common mistakes and practical shortcuts from experienced auditors
- Requestum services: how we help teams run audits and deliver fixes
- FAQ
- Sources
When should you run a UX audit?
Most teams wait too long to audit, then try to fix everything at once. A better approach is to watch for specific signals and scale the audit to match the problem, rather than defaulting to a full site review every time.
Several triggers should prompt an audit:
- A key metric drops: conversion rate, signup completion, or retention falls without an obvious cause.
- Support tickets spike around a specific flow, suggesting users cannot complete a task without help.
- You are preparing for A/B testing and need a baseline of known usability issues before testing variants.
- A redesign or new feature launch is coming up and you want a pre-launch sanity check.
- Stakeholders request a usability review ahead of a funding round or board presentation.
Match the audit's scale to the trigger. A single checkout drop-off calls for a task-level audit focused on that flow, maybe three to five screens and the heuristics that apply to them. A broader retention decline across multiple touchpoints calls for a full funnel audit, covering onboarding through repeat engagement. Before committing resources, run through a short checklist: Is there a specific metric or complaint driving this? Can we isolate the flow or does it span the whole product? Do we have at least two weeks of analytics data to work from? If the answer to the first two is yes and the data exists, you are ready to scope the work.
Define scope, objectives, and measurable usability goals
An audit without defined objectives tends to produce a long list of opinions rather than a prioritized set of fixes. The fix is to translate business KPIs into specific, measurable usability goals before any screen gets reviewed.
Start by setting goals using a structured approach:
- Identify the business KPI at risk, for example checkout completion rate or trial-to-paid conversion.
- Translate it into a usability goal: "90% of first-time users complete checkout without contacting support," rather than a vague "improve checkout."
- Document acceptance criteria: the specific metric, target value, and measurement window that will confirm success.
- Involve stakeholders early, including product owners, support leads, and engineering, so the scope reflects real constraints and everyone agrees on what "done" looks like.
- Decide the scope level: task-level (one flow), funnel-level (multiple connected steps), or site-wide (full product review).
The measurable usability goals template from usability.gov gives a ready-made structure for this step, mapping business objectives to testable usability criteria so the audit stays anchored to outcomes rather than preferences.
Pro Tip: Write your acceptance criteria before you look at a single screen. It keeps the findings phase honest and prevents scope creep once you start noticing unrelated issues.
Task-level scopes suit a single reported problem, like a confusing form field. Funnel-level scopes suit multistep conversions, like signup through first purchase. Site-wide scopes suit major redesigns or when multiple unrelated complaints suggest systemic issues. Choosing the wrong scope is the most common reason audits stall. A site-wide scope on a task-level problem burns weeks on screens nobody asked about.
Collect quantitative data: analytics, funnels, heatmaps, and session replay
Quantitative data tells you where to look before you spend hours reviewing screens manually. Without it, an audit relies on intuition about where users struggle, which is often wrong.
Pull these metrics first:
- Funnel conversion rate at each step, so you can see exactly where users drop off.
- Error rates on forms or input fields, which often point to validation or labeling problems.
- Click-through rate on primary calls to action, compared against secondary or decoy elements.
- Time-on-task for key flows, which flags friction even when users eventually succeed.
- Drop-off rate by device and browser, since mobile and desktop often reveal different problems.
Analytics show the "where." Heatmaps and session replay show the "why." A funnel report might tell you that 40% of users abandon a form on step three, but a heatmap reveals that most clicks are landing on a field that looks interactive but is not, and session replay shows users repeatedly clicking it before giving up. Combining analytics with session replay and usability testing reduces false positives: analytics identifies where to look, session replay shows the actual behavior, and testing confirms the root cause rather than a guess about it, a sequencing NN/g recommends for exactly this reason.
Many usability issues hide in the gap between what analytics report and what users actually experience, which is why heatmaps and replay sessions remain essential evidence in a well-documented audit rather than optional extras.
For your audit evidence file, export three things: a funnel report showing conversion and drop-off at each step, a heatmap screenshot of the problem screen with annotations, and two or three short session replay clips showing representative struggle points. These become the backbone of your findings section later, giving stakeholders something concrete rather than a subjective description of "confusing navigation."
Run a heuristic evaluation using Nielsen's heuristics
Heuristic evaluation is the fastest way to catch a large share of usability problems without recruiting a single test participant. Jakob Nielsen's 10 usability heuristics remain the standard framework for this: principles like visibility of system status, consistency and standards, error prevention, and recognition rather than recall give evaluators a shared vocabulary for what "bad UX" actually means on a given screen.
A reliable process looks like this:
- Recruit three to five evaluators, ideally a mix of designers and people unfamiliar with the product, since fresh eyes catch different problems.
- Give each evaluator the same scope document and task list so findings are comparable.
- Timebox each evaluation session, typically one to two hours per flow, to keep findings focused on real friction rather than minor nitpicks.
- Have each evaluator log violations independently before discussing, to avoid groupthink skewing the results.
- Aggregate findings into a single sheet, noting which heuristic each issue violates and how many evaluators flagged it independently.
NN/g's guidance on conducting heuristic evaluations specifically recommends this three-to-five evaluator range because individual evaluators tend to catch different subsets of problems. Nielsen also describes heuristic evaluation as a form of discount usability engineering: fast, cheap, and effective at surfacing many issues quickly, but not a substitute for direct user testing.
Pro Tip: Log every finding with the exact heuristic it violates, a screenshot, and a one-line description of user impact. "Error prevention violated: users can submit the form with an empty required field and get no warning until the next page" is far more useful to a developer than "form has issues."
A typical observation might read: on the account settings screen, the save button gives no confirmation after a click (visibility of system status violated), captured with a screenshot and a note that three of four evaluators flagged it independently. That level of specificity is what separates an actionable audit from a vague one.
Qualitative research: usability testing, interviews, and session replay analysis
Heuristic evaluation and analytics tell you where problems likely exist. Usability testing confirms whether real users actually experience them the way you predicted, and often reveals a different root cause than the one your team assumed.
Choose a testing approach based on your timeline and the nature of the problem:
- Moderated testing works best for exploring unfamiliar flows or early-stage designs, where you want to ask follow-up questions in real time.
- Unmoderated testing scales faster and suits validating a specific, well-defined task across a larger sample.
- Five to eight participants per user segment is generally enough to surface the majority of recurring usability problems in a given flow.
- Recruit participants who match your actual user profile, not convenience samples of coworkers or friends, since mismatched recruiting produces misleading findings.
- Write tasks that map directly to your audit objectives: instead of "explore the checkout page," ask "find a way to apply a discount code and complete your purchase."
Interviews add context that behavioral data cannot. A user might complete a task successfully in a test but mention afterward that they almost gave up twice, which is a signal worth capturing even when the task technically succeeded.
When synthesizing qualitative findings, pull together three types of evidence for each recurring issue: direct quotes from participants describing their confusion, the specific friction pattern observed (hesitation, repeated clicks, backtracking), and a short session replay clip that shows the moment it happened. This combination gives stakeholders both the emotional context and the visual proof, which tends to land better than a statistics-only summary. Grouping findings by root cause rather than by individual participant also helps: if four of six participants stumble on the same step for different surface reasons, that step likely has a structural problem worth fixing before anything else.
Synthesize and prioritize findings: severity ratings and impact × effort
A long list of usability issues is not an audit deliverable. It is raw material. The real work is turning that list into a small number of prioritized actions that a team can actually commit to.
Severity ratings work better than simple pass or fail checklists because they capture how much an issue actually matters, not just whether it exists. A missing hover state is a real issue but rarely severe. A checkout field that silently rejects valid input is severe because it blocks revenue. Practitioners recommend ranking findings by severity and exposure (how many users are affected) rather than treating every item on the list as equally urgent, since that approach is what makes a long findings list tractable.
Once severity is assigned, plot each finding on an impact × effort matrix:
- High impact, low effort: fix immediately, these are your quick wins and should ship within the current sprint.
- High impact, high effort: schedule as a strategic project with its own timeline and stakeholder sign-off.
- Low impact, low effort: batch these into a cleanup sprint when bandwidth allows.
- Low impact, high effort: deprioritize unless it blocks a higher-priority fix.
| Impact | Effort | Example | Action |
|---|---|---|---|
| High | Low | Missing error message on required form field | Fix immediately |
| High | High | Redesigning the entire checkout flow | Schedule as project |
| Low | Low | Inconsistent button corner radius | Batch into cleanup sprint |
| Low | High | Rebuilding navigation for a rarely used admin panel | Deprioritize |
Severity should be calibrated to conversion impact and the engineering cost to fix it, which creates a ranked roadmap rather than a flat to-do list. Once findings are prioritized, convert each high-priority item into a ticket with the same structure: observation, violated heuristic or guideline, evidence, recommended fix, and owner. That structure is what lets an engineering team pick up a ticket without needing a follow-up meeting to understand it.
Write an actionable audit report and present to stakeholders
A report that buries the important findings on page twelve will not get funded. Structure matters as much as the findings themselves.
Build the report around these elements:
- An executive summary stating the business goal, overall health of the experience, and the top risk areas in three or four sentences.
- The top five prioritized findings, each with severity, evidence, and recommended fix, presented before any lower-priority items.
- Supporting evidence for each finding: annotated screenshots, a short video clip from a session, or a heatmap callout showing exactly where users struggled.
- A metrics section naming what you will monitor after fixes ship, tied back to the measurable goals set during scoping.
- A handoff section listing tickets, owners, and target sprints, so engineering and design know what happens next.
Visual evidence changes how a report lands with stakeholders. A screenshot with a red box around the confusing element, paired with a fifteen-second clip of a real user hesitating there, makes the case faster than three paragraphs of description ever will. Each finding should include an observation, the violated heuristic or WCAG criterion, a screenshot or replay clip, a recommended fix, and a measurable success metric, since that is what turns a report from a critique into a work plan.
Pro Tip: Set a 30/60/90 day follow-up plan in the report itself. Thirty days to confirm quick wins shipped, sixty days to check the metric movement, ninety days to revisit anything still open. Putting dates in the report makes accountability automatic instead of optional.
Accessibility checks to include (WCAG 2.2) and simple tests you can run
Accessibility checks belong in every UX audit, not as a separate compliance exercise but as a core part of usability. A button that is hard to tap on a touchscreen is a usability problem for everyone, and an accessibility problem for people with limited dexterity.
WCAG 2.2 defines testable success criteria across three conformance levels: A, B double-A (AA), and triple-A (AAA), with sufficient and advisory techniques for meeting each one. A few criteria are worth scanning for in nearly every audit:
- Target size: interactive elements should generally be at least 44 by 44 CSS pixels, per W3C's guidance on Success Criterion 2.5.5, which also covers legitimate exceptions and why this matters for users with limited dexterity.
- Keyboard focus: every interactive element should be reachable and clearly indicated using only a keyboard, with no focus traps.
- Non-text content: images and icons need meaningful alt text, not filler like "image1.png."
- Color contrast: text against its background should meet WCAG's minimum contrast ratios so low-vision users can read it.
Enlarging touch targets to meet the 44 by 44 pixel recommendation often improves mobile conversion broadly, not just for users with dexterity limitations, a point worth highlighting to stakeholders who see accessibility as a compliance cost rather than a usability investment, as W3C's target size guidance explains.
For quick manual checks, try tabbing through a page using only your keyboard, running a page through an automated scanner, and zooming your browser to 200% to see if layouts break. Accessibility improvements also tend to help search visibility, since accessible markup and clear structure overlap significantly with SEO best practices. Report accessibility findings the same way as other usability issues: observation, violated criterion, evidence, fix, and a way to measure that the remediation actually worked, such as a follow-up scan showing the criterion now passes.
Tools, templates, and a repeatable checklist you can copy into your workflow
Running an audit repeatedly across a team requires a consistent toolkit, not a different approach every time. Map your tools to the audit steps rather than collecting tools for their own sake.
A workable toolkit covers these categories:
- An analytics platform for funnel and conversion data to identify where users drop off.
- A heatmap and session replay tool to see actual on-screen behavior at the problem points.
- A moderated or unmoderated testing platform to recruit participants and run tasks.
- An automated accessibility scanner to catch common WCAG violations quickly.
- A shared spreadsheet or ticketing template to log findings consistently across evaluators.
Your single-page audit checklist should capture five fields for every finding: the scope it falls under, a snapshot of evidence (screenshot, clip, or heatmap region), the severity rating, the proposed fix, and the owner responsible for it. Keeping the format identical across audits is what makes results comparable over time, so a redesign six months later can be measured against the same criteria.
Store templates somewhere the whole team can access and version, such as a shared drive or project wiki, and date each audit artifact clearly. Treating old audits as throwaway documents wastes the baseline data you need to prove that fixes actually worked.
Requestum's approach: how a delivery team runs an audit and turns it into product outcomes
We approach a UI/UX audit the same way we approach any delivery engagement: start with evidence, not opinions, and end with a roadmap engineering can execute. As a software development agency building web and mobile applications across industries, we treat an audit as the diagnostic step before design and development work begins, not a standalone report that sits unused.
We pair UX findings with technical execution rather than leaving clients with a list of problems and no path to solving them. We also bring AI and data science capabilities into audit work where it fits, using pattern analysis to surface friction points that manual review alone might miss.
The outcome we aim for is always the same: a prioritized set of fixes tied to a measurable business goal, handed to a team equipped to build them.
Common mistakes and practical shortcuts from experienced auditors
The same mistakes show up across most audits we have seen fail to produce change. Scope creep is the biggest one: a task-level question turns into a full-site review, and nothing ships for months. Unprioritized findings are a close second, a forty-item list with no ranking gets ignored because nobody knows where to start. Recommendations without a measurable validation plan are the third: a fix ships, nobody checks whether it worked, and the same issue resurfaces in the next audit.
A few shortcuts consistently help:
- Keep the scope narrow enough to finish in two to three weeks, not two to three months.
- Tie every recommendation to one primary KPI so success is unambiguous.
- Validate high-severity fixes with a rapid A/B test before rolling them out everywhere.
- Revisit the audit checklist at 30, 60, and 90 days to confirm the metric actually moved.
The best auditors we have observed treat the report as the start of a measurement loop, not the end of a project.
— Dmitry
Requestum services: how we help teams run audits and deliver fixes
When a UX problem needs more than an internal review, we offer a direct path from audit to delivery. Our UI/UX Design Services cover audit-style discovery work through to redesign, and we pair that with Software Testing and Quality Assurance Services to verify that fixes actually solve the problem before launch.
A typical engagement starts with a discovery call where we walk through your current metrics, the triggers that prompted the audit, and what a successful outcome looks like for your team. From there:
- We scope the audit against your specific business goals, not a generic checklist.
- Our Business Analysis Services translate findings into clear requirements and backlog items.
- We prioritize fixes by impact and effort, so your roadmap reflects real returns rather than guesswork about what to build first.
- We validate each fix against the original metric before calling it closed.
If you would rather hand the full process to a team that has delivered this kind of work before, reach out to discuss your project and we will walk you through what a discovery call covers.
FAQ
How much does a UX audit cost?
Pricing for a UX audit depends on scope, team size, and whether accessibility testing or usability testing with recruited participants is included. We do not publish a flat rate for audits specifically, since cost scales with the depth of the engagement; a discovery conversation is the fastest way to get an accurate quote for your scope.
Is UI/UX still in demand in 2026?
Digital products continue to compete heavily on user experience, and teams that catch usability problems early tend to retain users better than those that do not. Demand for structured UX work, including audits ahead of redesigns and feature launches, remains tied directly to how much revenue flows through digital interfaces.
Is UI/UX design being replaced by AI?
AI tools increasingly support parts of the UX process, such as analyzing session data or flagging patterns across large datasets, but judgment calls about user intent, business context, and tradeoffs still require human designers and researchers. AI works best as a tool that speeds up analysis within an audit, not as a replacement for the evaluation itself.
What does UI/UX stand for?
UI stands for user interface, the visual and interactive elements a person directly interacts with, like buttons, forms, and navigation. UX stands for user experience, the broader sense of how easy, efficient, and satisfying it is to accomplish a goal within a product.