Commission an expert review to identify experience obstacles, user testing to observe relevant people, and functional QA to verify behaviour against requirements. More than one may be appropriate, but buying an undefined “application check” makes the resulting evidence difficult to assess.
A product can follow its specified rule while users misunderstand it. An interface can be clear while saving data fails. An expert can identify a likely obstacle whose practical context needs user research. These situations require different evidence, not one overall score for the application.
Compare the question and evidence, not just the service name
| Review | Main question | Evidence source | Expected output |
|---|---|---|---|
| UX/UI audit | Where are visible obstacles or inconsistencies in the agreed journey? | Expert inspection | Documented issue, potential effect and remediation priority |
| Usability testing | How do relevant users understand and perform a task? | Participants attempting tasks | Behaviour, difficulty, assistance and task outcomes |
| Functional QA | Does the system produce expected behaviour in specified cases? | Executed verification cases | Pass or failure with reproducible steps and evidence |
GOV.UK describes moderated usability testing as watching participants attempt specific tasks. Testing reference. A designer’s screen review should therefore not be called user testing, however useful the observations are.
The distinction also changes procurement inputs. Expert inspection requires an agreed experience scope and access. Participant research additionally needs suitable recruitment and consent. Functional testing requires expected behaviour, controlled accounts and a testable environment. One brief cannot omit these differences and still support like-for-like proposals.
Worked hypothetical example: an order awaiting approval
Imagine an office-equipment ordering platform that requires an authorized manager to approve requests. A user reaches a “Submitted” page and then calls to ask whether the order is confirmed. Three reviews of the same journey could produce different findings.
In a UX/UI Audit, the reviewer notes inconsistent use of “Confirm” and “Submit” and a status page that does not explain the next step. They document possible ambiguity with screen references and a clarification proposal. That does not establish how many people are affected or what users actually do.
In a User Research study, suitable participants attempt the task and explain what they think happened. Some may understand that approval is outstanding; others may believe fulfilment has started. The report preserves context, interpretation and any assistance. It does not generalize those observations to the entire market or customer base.
Software Quality Assurance checks that submission creates the required state, approval is restricted to the intended role, and repeat submission does not create an additional request under the agreed rule. Passing these cases establishes what was checked in that version and environment. It does not establish that the wording is understood or that no defects exist elsewhere.
Functional tests could pass while status meaning remains unclear. The team might first clarify the content and then observe understanding with new participants. User Experience Design can support a revised flow or state explanation rather than assuming the system needs rebuilding.
The three reports should be connected through the same journey identifier, but their evidence should stay distinct. That allows the product owner to see whether a proposed fix addresses an implementation defect, an experience hypothesis or a demonstrated comprehension problem.
Decide where to start
If a precise error is already reported, such as a selection not being saved or inconsistent state across screens, start with functional verification and the environment needed to reproduce it. Participant sessions should not be used to diagnose an already known technical failure that can be checked directly.
If the interface is inconsistent or the journey has grown complex, an expert audit can provide initial prioritization. Ask the reviewer to distinguish direct observations from hypotheses about their impact. When the decision depends on user understanding or behaviour, design relevant participant research rather than trying to resolve it through internal opinions.
There is no universal sequence. Sometimes a blocking defect must be fixed before research. Sometimes an observed user problem identifies the journey requiring deeper verification. The supplier should explain the sequence and how each stage changes the next decision.
Keep accessibility scope explicit
These reviews may identify accessibility barriers, but a general experience report is not automatically a comprehensive evaluation against a specified standard. W3C explains that a tool alone cannot determine standards conformance. Accessibility-evaluation reference. Ask for the standard, scope, methods, skills and exclusions; do not treat a report as a certification or legal guarantee.
Likewise, one participant does not cover every ability and device. Conclusions must fit the people, environments and tasks studied. If additional specialist work is required, make it an explicit scope with a qualified owner rather than an implied promise inside “comprehensive testing.”
Compare proposals on their actual outputs
Give suppliers the same journeys and version and ask them to address the same question. Compare access needs, evidence source, coverage, severity classification, deliverables and whether verification after remediation is included. A screen count does not make an expert audit and participant study equivalent purchases.
Shared acceptance checks, while preserving evidence differences:
- Each finding connects to a journey, task or expected behaviour.
- Readers can identify whether evidence came from an expert, participant or test case.
- Version, environment, accounts and scope limits are documented.
- Observations are not presented as prevalence or established causation without support.
- Each issue has a justified priority and a remediation or investigation step.
- Retesting and authority to accept the fix are clear.
Request a sample reporting structure rather than promises to find every problem. A useful report makes developers and decision makers able to act on a finding and understand its uncertainty.
Frequently asked questions
Can one supplier perform all three?
Yes, within an agreed scope if suitable roles and skills are confirmed. Request distinct evidence for each discipline rather than assuming one specialty covers everything.
Does passing QA mean the experience is easy?
No. Software can work to specification while being difficult to understand. Specification quality and usability need additional evidence when they are in question.
Does an expert audit require participants?
Not by definition, but without participants it has limits on claims about actual user behaviour. Make that distinction explicit in the proposal and report.
Must every recommendation be implemented?
Not automatically. Assess impact, evidence and constraints, approve an appropriate response and verify it. A recommendation is not an instruction to build regardless of cost or relevance.
Start with the problem, existing evidence and the decision that depends on it. Choosing the review becomes easier when the unknown is explicit.
