Website UX audit: what should the report include?

A website UX audit should explain what prevents a customer from completing a specific task, what evidence supports the finding and which changes deserve attention first. A useful report goes beyond screenshots and comments such as “this button is too small”. It should help the business owner make decisions and give designers and developers enough detail to plan the work.

If you are considering an audit, compare its scope, methods and deliverables. The length of the PDF tells you little about the value of the service. The following criteria will help you agree a meaningful brief and assess the report when it arrives.

When is a UX audit worth commissioning?

An audit is useful when a site works but visitors appear to struggle with choosing a service, making an enquiry or completing a purchase. It can also inform a redesign: rather than transferring existing problems into a new visual style, you identify what actually needs to change.

Suitable objectives include:

• simplifying the journey from a service page to an enquiry,
• checking whether customers understand the offer and its conditions,
• identifying obstacles in checkout or booking,
• reviewing important tasks on mobile devices,
• setting priorities before commissioning a redesign.

Failed payments or contact messages that never arrive primarily need technical investigation. An audit may uncover these faults, but identifying them does not repair them. Our guide to improving a site or rebuilding it explains how to separate targeted changes from a larger project.

Define tasks, not just a number of pages

“An audit of five pages” can describe very different services. Specify who uses the site, why they arrive and what they need to accomplish. Then agree which screens and interface states will be reviewed.

An example for a service business

Consider a prospective customer looking for window installation. They land on a service page, check whether the company covers their area, compare what installation includes and request a quote. The review therefore covers more than the page design: it includes finding conditions, reaching the contact form, entering invalid information and understanding the submission confirmation.

This is an illustrative scenario, not an AMCompany client story or a claimed result. You can describe a similar task for your own service. For an online shop, it might involve choosing the correct product variant and understanding delivery costs before ordering.

The proposal should name the devices, browsers, journeys and exclusions. Agree separately whether customer accounts, additional languages and third-party booking or payment systems are included. Otherwise, both parties may assume a different meaning of “the whole website”.

Expert reviews and usability tests are different methods

During an expert review, a specialist examines the interface against usability principles. This identifies likely problems; it does not prove that every customer behaves in the same way.

Nielsen Norman Group's guide to heuristic evaluation describes evaluating a design against selected guidelines. It also explains that this approach cannot replace research with actual users. The methods can complement each other.

Usability testing involves observing people as they carry out agreed tasks. If testing is included, ask how participants will be recruited, what they will be asked to do and how findings will be documented and analysed. Do not assume the term “audit” automatically includes recruitment and research sessions.

The report should distinguish between:

• an issue reproduced while inspecting the site,
• a difficulty observed during a research session,
• a signal in analytics data,
• an expert hypothesis that still needs validation.

This distinction matters when deciding whether to fix a clear defect immediately or investigate a proposed redesign more carefully.

Use analytics without overstating what it proves

Analytics can help select journeys for closer review. It cannot explain every underlying cause on its own. Fewer mobile enquiries may reflect the interface, but they may also reflect different traffic sources, the offer itself or unreliable tracking.

Google explains that the GA4 Landing page report identifies pages where sessions begin. This makes it a useful starting point for choosing journeys to examine, not a ready-made diagnosis of customer behaviour.

Before drawing conclusions, check whether tracking records an accepted enquiry or merely a button click. Our article on better website contact forms explores that distinction. When data is sparse or configuration is uncertain, the auditor should document the limitation rather than calculate apparently precise lost sales.

Ask which reporting period and segments support a finding. An observation based on one campaign should not automatically become a conclusion about every visitor to the website.

What should each finding contain?

A practical report gives each clearly defined problem its own entry. For every finding, expect:

1. the page, screen or journey stage involved,
2. the device and conditions in which it occurs,
3. steps that another person can follow to reproduce it,
4. a screenshot or another form of supporting evidence,
5. the consequence for the user's task,
6. a clear separation between observation and interpretation,
7. a proposed solution and relevant dependencies,
8. a priority and a way to verify the change.

“Improve the form” is not enough. A more useful entry would say: “After an invalid phone number is submitted, the remaining fields are cleared. Preserve entered values and show the error beside the relevant field. After implementation, repeat both an invalid and a successful submission.”

That description can become an implementation task. The developer does not need another meeting simply to discover what the recommendation means. Where alternatives exist, the report should explain the trade-off rather than present a stylistic preference as an unavoidable requirement.

Priorities should support an actual work plan

Not all observations deserve equal attention. A fault preventing an enquiry should be assessed differently from a preference about heading spacing. Ask the auditor to explain how priorities are assigned.

A workable plan can separate:

• faults that prevent task completion,
• obstacles in important, frequently used journeys,
• changes requiring further evidence or research,
• smaller improvements that can be combined with other work.

Issue severity and implementation effort are different pieces of information. A serious obstacle may have a straightforward fix, while a minor-looking change may require an integration to be rebuilt. If development estimates are outside the audit scope, the report should not pretend to be a finished engineering schedule.

Clarify the boundaries of performance and accessibility checks

Performance and accessibility affect the user experience, but not every UX audit includes specialist assessment of either. Agree whether the deliverable simply flags barriers or includes dedicated testing and verification after changes.

For performance, distinguish controlled measurements from real-user data, as explained in web.dev's guidance on lab and field results. A single tool score does not describe the entire experience or prove that a specific number of customers has been lost.

An audit does not automatically include implementation

Agree what happens after the report is delivered. Will the auditor discuss findings with your team? Answer the developer's questions? Produce wireframes? Review changes after launch?

A well-defined commission separates diagnosis, solution design, implementation and verification. This prevents you from buying a report while assuming the checkout will be rebuilt within the same fee. Our website handover checklist covers acceptance of implemented work.

If you plan to implement recommendations in stages, ask which issues depend on shared components. Changing navigation or form behaviour may affect several pages, so checking only the originally reported screen can miss regressions elsewhere.

What should you send when requesting audit proposals?

Prepare the website address, business objective, important journeys and known problems. Include the technology, available data and the person responsible for implementing changes. Grant access only after agreeing the scope, with permissions appropriate to the work and without sharing an owner's password.

Request an anonymised sample finding, a deliverables list and clear acceptance criteria. Do not expect guaranteed sales growth: the audit improves the basis for decisions, while the effect of implemented changes must be evaluated afterwards.

With AMCompany, you can discuss website development or redesign without committing immediately to a completely new site. Browse the portfolio, then describe your objective and the obstacles on your current website. The starting point is a customer task and a scope of work that can be checked, not an arbitrary list of cosmetic changes.