How to choose a UX audit agency: 10 questions to ask before you sign

Insights · Buyer's guide

What should you look for in a UX audit agency?

Judge a UX audit agency by what it lets you check before you sign: who does the work and what they know about software like yours, how the sample is chosen, how findings separate what was seen from why it happens, and what your team can do with the report. Ten questions below test each.

You may find the same offer sold as an agency, a company, a service or a specialist. The label matters less than the answers. A UX audit here means a structured review of a live software product that ends in decisions the team can act on, not a list of screens that look inconsistent.

One disclosure first. Tcules sells UX and product audits, so the questions are ones we expect to be asked. Where a question says how Tcules answers it, the answer comes from how Tcules describes its audits on its own site. Hold us to it on the call, and ask every other provider the same ten.

Which kind of provider are you comparing?

Providers fall into a few recognisable types. These are generalisations, not rankings. Any type can do good work, and each has a question it most needs to answer.

Scope and people

1. What decision will this audit help us make?

An audit commissioned as "review our UX" has no finish line. Start from a decision the findings should change: which workflow failures enter the next roadmap, whether the product needs a redesign or structural modernisation, where design and production have diverged, whether roles and permissions can support the next market. The decision tells the provider which evidence and which expertise the work needs.

A good provider will push you to name the decision, and will tell you when an audit is the wrong purchase. If you already know what has to change, the better next step is that work, not another diagnosis. That is a judgement, but a provider who cannot say it has an incentive problem you should know about before you sign.

How Tcules answers: its audits page says each assessment begins with the decision and the evidence available, and that the output can recommend that Tcules continue, that your team act, that a specialist answer is required or that no larger intervention is justified yet. If your real choice is between redesigning, replatforming, rebuilding and retiring, rebuild or modernise legacy software sets out that decision.

2. Who will actually do the audit, and what have they worked on?

Ask for the named practitioner or practitioners, not the person on the sales call. Then ask three things: what software like yours they have evaluated before (dense workflows, roles and permissions, regulated or high-consequence tasks), how many people will look at your product, and whether anyone reviews another person's findings and severity ratings.

Two findings from the usability-evaluation literature explain why those questions matter. They are evidence about heuristic evaluation and recorded usability tests, which are parts of an audit, not about audits as a whole.

• Expertise in the interface type helps. A 1992 study of heuristic evaluation found that usability specialists were better than non-specialists, and that evaluators with specific expertise in the kind of interface being evaluated did better still.
• Different evaluators find different problems. In a later study, 19 experienced evaluators analysed the same recorded usability sessions. In the moderated group, each evaluator reported on average 33% of the problems reported by all nine evaluators, and as much as 24% of the problems reported by more than one evaluator were rated critical by one and minor by another. The authors call this the evaluator effect.

What follows is an inference, not a measured result about any agency: one reviewer's list is one reviewer's list. Ask how the provider handles that, for example through a second reviewer, an explicit confidence level on each finding, or a requirement that every finding names its evidence.

3. How do you choose the sample, and what will it not tell us?

No audit covers everything, and one that claims to deserves suspicion. The useful question is what the chosen sample can and cannot support. A representative slice should include the roles, states, content and exceptions that the symptom depends on, and you should agree it before work begins. In our judgement, a consequential workflow examined properly can produce a better decision than a shallow pass over every screen.

The accessibility field has formalised the same discipline. The W3C's evaluation methodology for WCAG has evaluators build a structured sample of the key views and functions, add a randomly selected set to test whether the structured sample is representative, and include every step of any complete process they sample. It also says that conformance claims for a whole website cannot be based on a sample of its pages alone. You are not buying a WCAG evaluation, so treat this as an analogy: findings from a sample are statements about the sample, and a provider should tell you where the sample stops.

How Tcules answers: a representative slice of roles, states, content and exceptions, agreed before work begins, with the report stating where the sample cannot support a wider conclusion.

Evidence and method

4. What evidence will you use besides looking at the screens?

A review of the interface alone can show that something is inconsistent. It cannot show how often it happens, what it costs, or what the user intended. A heuristic review can identify likely usability problems quickly, but not prevalence, business effect or user intent on its own.

Ask which of these the provider will use for your question, and what they will need from you to do it:

• representative workflows and edge states;
• product analytics, with the limits of interpretation stated;
• support and sales evidence;
• research your team already holds;
• interviews or usability evaluation;
• accessibility review against a named standard and level, such as WCAG 2.2;
• a comparison of design files and running code;
• the object model, business rules, permissions and handoffs behind the screens.

A provider who needs nothing from you except a URL will give you an opinion on screens. That can be useful for a narrow question. It is not the same as an audit of a workflow.

5. How will you separate what you saw from why it happens?

In our judgement, this question does the most to separate a useful audit from a long list. An interface can show a failure, such as users retrying a step or an unclear screen, while the cause sits somewhere else: an unresolved business rule, an implementation difference, or a missing product decision. A redesign aimed at the wrong layer may not fix the problem.

Ask to see how a finding states three things separately: what was observed and in which surface, what the consequence could be, and what is still unknown about the cause. The pattern looks like this in a fictional example written for this guide, not a client result: An operations manager can reassign an overdue approval, and the dialogue does not say who stays accountable or whether the escalation clock resets. The finding records that the missing explanation is established in the inspected screens, that its cause is not, and that the next action is a rule check by the product owner with operations and engineering before any interface change.

A provider who moves straight from "this looks wrong" to "redesign it" has skipped the step this question tests.

6. Where does software do the looking, and who decides what counts as a finding?

Some offers include automated scanning or AI-generated review. Software can look at more of a product than a person can, and that is its value. The risk is treating its output as a finding.

Two pieces of evidence, both limited:

• Automated accessibility scanners miss a lot. In 2017 the UK Government Digital Service built a test page with 143 deliberate accessibility failures and ran 10 automated tools against it. Forty-two of the failures, 29%, were missed by every tool, and the best tool found 37% when counting only its errors and warnings. The team's conclusion was that such tools should be combined with manual checking, an accessibility audit and user testing. This is accessibility, not general UX, and a page built to fail is not a real product, so read it as an illustration of what scanners can miss, not an estimate for your product.
• AI feedback on interface design is useful and uneven. A CHI 2024 study tested GPT-4 on 51 interface mockups with guidelines written as heuristics. The feedback helped with catching subtle errors, improving text and considering what the interface means, but its usefulness decreased over iterations, and a study with 12 expert designers looked at how it fits existing practice. It studied mockups, not running products, and models have changed since.

The question to ask is concrete: which parts of the work does software do, which parts does a named person do, and who signs off each finding? The answer you want is that software adds coverage and a practitioner owns every finding.

How Tcules answers: its audit page says AI may increase coverage, not certainty, that AI support does not replace source verification, and that Tcules verifies source context and consequential conclusions. Tcules also says it avoids arbitrary scores and percentages that imply more certainty than the evidence supports.

What you receive

7. Can I see a sample finding and a sample report before I sign?

Ask early. Some agencies keep real reports confidential, so a redacted or fictional example is a fair request, but be clear about what it proves. A sample shows the format. It does not show the quality of judgement on a product like yours, so also ask how they would write up a finding of the kind you are worried about.

What to look for in a finding: the observation, where it came from and how strong the evidence is, the condition it applies to (which role, state or device), the consequence, the diagnosis (interface, product model, implementation, policy or missing evidence), the recommended decision, an owner, and how you would know it worked. Descriptions written for the person who has to act matter more than they seem: a finding the engineer cannot act on has not done its job.

How Tcules answers: the UX and Product Audit page lists what you receive as a scope and evidence record, a finding-to-decision ledger, consequence and confidence, an action disposition and owner, and a validation recommendation.

8. How do you prioritise, and who owns each finding?

A ranked list of problems is not a plan. Ask how severity is assigned, by whom, and on what basis. The evaluator-effect study above is the reason: experienced evaluators in that study disagreed about severity, so a score with no stated reasoning is one person's view dressed as a measurement. Prefer a provider that orders actions by consequence, dependency and the strength of the evidence, and says plainly where evidence is weak.

Also ask what kinds of action the report can recommend. A useful report separates fix now, investigate first, redesign, modernise underlying structure, align design and code, accept with a stated reason, and defer with a trigger for review. A report that only ever recommends redesign raises the question of who benefits.

Finally, ask who on your side needs to accept each finding, and whether the report names an owner and a validation step for each one. An audit with no owner on the client side can end as a document.

How Tcules answers: each finding ends in a decision with an owner and a validation step, and the audit separates quick corrections from structural work.

Access, risk and what comes after

9. What access do you need, and what happens to our data?

Ask for the access list in writing. Useful access includes realistic product roles in a test or sandbox account, the concerns your team already has, and time with people who understand the workflow. Source code is needed only when the question depends on implementation, such as a suspected difference between design and build. Be wary of a request for production access or customer data when the question does not need it.

Then ask the practical questions your security or legal contact will ask anyway: who will see your product and data, how long materials are kept, whether any software in the process sends your screens or content to an outside service, and what the confidentiality terms cover. These are procurement questions we are raising from practice, not from a study, and your own policies decide the answers.

How Tcules answers: its audit page asks you to bring product access, intended users, current concerns, known evidence, representative data, relevant analytics or support themes and the decision the audit must inform.

10. What happens after the report, and who profits from the next step?

An audit has two possible conflicts of interest. A provider that also sells design or engineering has a reason to find work only it can do. A provider that sells only audits has a reason to find more audits. Neither is disqualifying. You should simply ask how each one handles it.

Good signs: the report is usable by your team, another supplier or the provider; the provider will say when no further work is needed; there is a stated option to retain a behaviour deliberately, with a reason and a review trigger; and the engagement does not assume you will buy the repair. An audit has done its job when the next commitment is clearer, not when the backlog is largest.

How Tcules answers: its audits page says the output is not a disguised proposal, Tcules says your team can act on the findings without Tcules, and findings can be carried into a larger delivery scope where that fits.

What makes one quote higher than another?

This guide gives no price figures, because quotes differ mainly by scope, and comparing price before scope compares different things. Factors that can move a quote include:

• how many workflows, roles and states are in the sample;
• how many reviewers look at the product, and whether findings are cross-checked;
• whether the work includes user sessions, interviews or analytics work or relies on expert review alone;
• whether code or design files are compared with the running product;
• how much of the deliverable is a decision record with owners and validation versus a findings list;
• whether follow-up, such as a readout or support for the first fixes, is included.

Ask each provider to restate the scope in its own words before you compare numbers. Two quotes that look the same can cover different samples.

A checklist to take to the call

What this guide cannot tell you

The research cited here comes from usability evaluation, one accessibility test and one study of AI feedback on mockups. It is old in places (1992, 2014, 2017, 2024) and none of it tests whether choosing a provider by these questions produces a better audit. The questions are a judgement informed by that evidence and by how Tcules describes its own audits, not a validated selection method. We also sell audits, so read our answers as a description of our approach, not independent proof.

Ask us the same ten questions

If you want to test these questions against a real provider, start with ours. The Tcules audits page lists six audits and assessments, organised by the decision each one is meant to inform, and you can describe the decision your team cannot yet make.