UX/UI site audit: where the interface loses visitors and requests
A UX/UI site audit is not a subjective assessment of “like or dislike,” but a step-by-step review of user scenarios: where a person enters, what they look for, at which action they stop, and why they leave.
We reconstruct this path from behavioral data — session recordings, click maps, and the goal funnel in Yandex Metrica — and compare it with what the visitor actually saw on the screen.
Scenario diagnostics show specific drop-off points — the places where users leave.
An order form that loses some of those who filled it out at the phone step; a catalog where filters do not narrow the results and the person starts the search over; a cart without a clear delivery cost — these are not cosmetic flaws, but a lost flow of requests.
Interface usability problems almost always lie in three places: the next step is unclear, there are more required fields than needed, and the promise at entry does not match what is seen later.
We measure not feelings but metrics: the drop-off rate at each funnel step, time to first meaningful action, number of backtracks during filling, share of repeated input attempts.
This shows which screen and which button wording cut off the visitor, and which fixes will change nothing.
The output is a prioritized list: what to fix first, what gain each block of fixes delivers, and how to verify the result after improvements. Next we examine exactly where your interface is losing visitors and requests.
What changes after interface rework: measurable effect
Interface fixes are measured not by “it became more convenient,” but by movement in specific indicators.
Before work begins, we establish a baseline: events at each step of the key scenario, time to target action, share of started and completed operations, reasons for support requests by category.
The mapping of metrics to interface steps is described in industry usability research, including Nielsen Norman Group: without such mapping, any conclusion about effect remains a matter of taste.
The first indicator is conversion of key scenarios.
If the barrier was at a specific step (unclear validation, hidden delivery cost, overloaded form), after the fix the share of completed operations at that very step grows: you can see where users stopped dropping off and how many reach the result.
The second is time to target action. Shortening the path — fewer steps, clear field labels, an explicit emphasis on the primary button — reduces the median time to complete the task.
On a request or checkout, the difference between the old and new version is usually multiple-fold, not within the margin of error: if the spread does not exceed noise, we consider the fix unproven.
The third is support load.
When the interface itself explains the state (empty screens with a hint, plain-language error messages, visible operation progress), the share of requests about interface issues falls: “where to click,” “why wasn’t it saved,” “what’s the status.” The first line switches to substantive requests instead of troubleshooting navigation.
The effect holds when fixes close confirmed barriers rather than change styling. That is why a UX/UI site audit starts with scenarios and event tracking — otherwise there is nothing to confirm improvements with, and disputed decisions remain disputed.
Methods of interface evaluation: three approaches and their limitations
No single method of interface evaluation gives a complete picture — each answers its own question and is blind to the others.
Expert interface review relies on rules of consistency, accessibility, and scenario logic: it quickly covers the entire product, including rare paths, but remains a specialist’s conclusion rather than a fact about human behavior.
| Approach | When it is appropriate | Limitations |
|---|---|---|
| Expert interface review | before release, when migrating a product to a new structure, when the full set of scenarios needs to be evaluated at once | does not show exactly where people stop; disputed points remain hypotheses |
| User testing | when the decision is unclear and a choice must be made between options — preferably on a prototype, before development | a sample of 5–8 people reveals causes but does not provide statistics across the entire audience |
| Behavioral analytics | on live traffic: funnels, heatmaps, session recordings | answers “where they drop off,” but not “why”; noise from bots and rare devices distorts conclusions |
We do not choose a single method.
Expert review produces a list of hypotheses, user testing confirms causes, behavioral analytics measures the scale of the problem across the entire audience — the limitations of the methods are removed by their sequence, not by replacing one with another.
How we conduct an interface audit: stages and artifacts
The audit begins not with heuristics but with task analysis: which scenarios are critical for the business, where users are lost according to data, which support requests repeat.
This way the list of findings relies on facts, and each fix gets a rationale rather than a taste-based judgment.
Workflow
- Context gathering. We interview the product owner and support, collect scenario statistics, review session recordings — and get a list of paths with the largest share of actions.
- Scenario analysis. We go through each path end to end and record the steps where the user stops, goes back, or leaves.
- Interface evaluation. We check navigation, forms, loading and error states, responsiveness and accessibility: keyboard navigation, contrast, size of interactive areas.
- Fix plan. We compile findings into a table prioritized by impact and effort, with each item including reproduction steps and the expected result.
- Change verification. We repeat the same route on a staging environment, compare behavior with the initial measurements, and make sure the fixes did not break neighboring scenarios.
- Handoff of results. We provide mockups, state descriptions, and a verification checklist, and review them with the client’s team.
Priorities in the fix plan make it possible to implement it in parts and, after each batch, see how scenario completion changes.
Screen map, prototypes, and interaction rules
A developer and a contractor who come after us need not a set of images but a description of the system: why the screen looks exactly this way, what happens on failure, and how to make changes without breaking neighboring scenarios.
Therefore, as a result of a UX/UI site audit, we hand over a kit from which the interface can be assembled without verbal guesswork.
- Screen and transition map — a route map with all branches: returns, dead ends, states after an error and re-entry. It shows that no scenario breaks off in the middle.
- State-based screen mockups — empty list, loading, error, partially loaded data, very long text. The developer does not decide on their own what to show in each case.
- Element interaction rules — behavior on hover, press, repeated click, and connection loss; which actions are blocked until confirmation and which are available immediately.
- Field and validation specification — required status, allowed formats, placement and text of the hint, and when it appears relative to input.
- Interface documentation — grids, spacing, size scale, color set, and element states. Values are taken from it rather than eyeballed in each new block.
- Change governance — who approves a change, what is versioned, where the reason is recorded. After handoff, a change goes through the same path as during design.
- Acceptance checklist — used to compare the assembled interface with the mockups before release, not after user complaints.
Such a kit removes the main cause of discrepancies: a dispute about “how it should be” turns into verification against a document. Changes become predictable — the change governance shows which screens they will affect and what will need to be rechecked.
Case study: shortened the path to a request on a services portal
A services portal with online requests: a person selected a service, filled out a long form, and attached documents.
The UX/UI site audit showed that the path to a request took 11 steps, and the draft was not saved — if the connection dropped or the user accidentally navigated away, the entered data was lost and the request had to be started over.
We did not estimate by eye: we broke the route down step by step in Yandex Metrica, reviewed session recordings, and conducted 12 interviews with those who abandoned filling out halfway.
There was one drop-off point — document upload: it accounted for four out of five incomplete requests, and the user learned the file format requirements only after the system rejected them.
We rebuilt the route: 11 steps were compressed to 6, profile data began to be populated automatically, and the form gained draft autosave and return to the last step.
File upload was moved to a single screen with format validation at the moment of selection, and the error text was rewritten to say what to do rather than what went wrong.
Indicators before and after: the share of completed requests grew from 38% to 67%, average completion time decreased from 9 to 4 minutes, and drop-offs at the document upload stage fell almost threefold.
Support requests about filling out the form decreased by 40% — some questions are now resolved by hints within the form itself.
What to do if the site is already in development or was recently updated?
An audit during development does not require stopping work and redoing the structure: it captures what is still cheap to change — section hierarchy, set of screens, element states, and the path to the target action. Everything already hardcoded in released screens is reviewed as is and fixed point by point.
We set priorities by scenario frequency, its proximity to the visitor’s goal, and the cost of an error in it. The paths to a request or purchase, where losses are immediately visible, come first; rare and secondary screens wait for the next batch. This order fits the fixes into an already agreed scope of work.
An updated interface is a separate case: a new visual layer often sits on top of previous rules, and states are lost at the junction. We check empty lists, input errors, long labels, behavior on a slow network, and returning from nested screens. These very points produce more drop-offs than outdated typography.
We make partial fixes in isolation so as not to affect working scenarios: we change style variable values and components, not page markup.
We test disputed decisions on a portion of visitors, comparing options by the number of completed actions, and if it fails, we revert to the previous one. Every fix has a rollback path.
We measure the effect before and after: share of target scenarios completed to the end, depth of returns one step back, number of support requests about navigation. Point fixes in three or four places produce a noticeable shift without rebuilding the structure.
Questions before the start: addressing common doubts
A UX/UI audit relies on data, not taste-based assessments: analytics, session recordings, a test account with a regular user role. If analytics is closed, scenarios are still testable — we go through key paths on the live interface and record where a person stops and why. Below are the things most often clarified before the start.
What access is needed and what to do if it is not provided?
Read-only access to analytics and one test account are enough — we do not touch the working environment; we review a copy or staging environment.
Without data, the audit narrows to manually walking through scenarios: there will be conclusions, but without quantitative confirmation that the problem is widespread.
How long does it take and when is the first result visible?
We analyze a large interface over weeks; a narrow product path goes faster. We deliver findings as we go, without waiting for the final document: critical problems can be handed off for work immediately, the rest by priority.
What is in the report and who implements the fixes?
The report is a list of problems tied to a screen, with an assessment of impact on the user path and priority, not a list of “make it pretty.” Implementation is done by your team according to our specifications, or by us, with metric verification after rollout.
How do you separate interface problems from traffic problems?
We compare behavior by sources and segments: if the drop-off repeats across all channels at the same step, the issue is in the interface; if it differs by source, it is a question of traffic quality and audience expectations. We record this distinction in the report so as not to redo screens where they are not the issue.
Let’s discuss the task: we’ll review the scenarios and come back with a plan
So that the discussion of the task fits into one conversation rather than stretching into a long chat, it is enough to prepare raw inputs for it — without presentations and polished wording.
The more specific the source data, the more accurate the scope estimate and the fewer assumptions will enter the work plan.
- Goal and metric: what task the user solves on key pages and by what sign you will understand that things have improved — share of users reaching a request, number of steps to the result, returns to the previous screen.
- Scenarios: 2–3 typical paths — first visit, repeat contact, access recovery; mark the places where, according to your observations, people stop or leave.
- Constraints: platform and stack, brand requirements, deadlines, what cannot be changed in the current page structure and forms.
- Current data: analytics exports for the period, session recordings, support requests, results of previous interface fixes.
- Critical screens and roles: which pages matter most and who on the team makes decisions about them.
- Access: test environment, staging with data, ability to reproduce the problem hands-on rather than from a description.
With this set, we review the scenarios on real data, separate systemic experience defects from cosmetics, and come back with a work plan: stages, what we do at each, which artifacts we hand over, and how we verify the result. If some data is missing, that’s okay — we will indicate what should be collected before the start.