User acceptance testing has an enterprise reputation — test plans, sign-off matrices, a dedicated QA function. Most small teams conclude it isn't for them and skip it.
Then they launch, and the client's finance director discovers the invoice form doesn't work in the browser their whole company uses.
UAT doesn't require a department. It requires answering four questions: who tests, what they test, how they report, and what "passed" means.
What UAT actually is
UAT is not "find bugs." That's QA, and it should already have happened. Our website QA checklist covers that pass.
UAT asks a different question: does this do the job the people who commissioned it need it to do?
A site can be technically flawless and fail UAT — because the booking flow doesn't match how the business actually takes bookings, or because a required field asks for information customers won't have. Those aren't bugs. Nothing is broken. The build just doesn't fit the work.
That's why UAT is done by the people who'll use the thing, not by the people who built it. Developers test whether it works. Users test whether it helps.
Who should test
Pick real users of each function, not managers of them:
- The person who'll update content, not their director
- Whoever handles enquiries that come through the contact form
- Someone who'll process an order end to end
- A representative customer, if you can get one
- The stakeholder with a compliance interest, for legal and privacy pages
Four to six people is plenty for most sites. More than that and coverage overlaps while coordination cost climbs.
The common failure is testing by proxy — a manager answering on behalf of a team they supervise but whose daily workflow they don't share. They'll approve things their staff will struggle with.
Write scripts, not invitations
"Have a play with it and tell us what you think" produces "looks great" followed by three weeks of trickled complaints.
A UAT script is a short list of tasks in plain language, tied to real business outcomes:
- Find the product you sell most and add it to the basket
- Complete a purchase using a test card
- Update the opening hours on the contact page
- Submit an enquiry as a customer would, then find it in the inbox
- Locate last month's invoice in the account area
Note what these have in common: an outcome, not a route. Don't tell them which button to press — the point is finding out whether they can find it. If a tester can't complete a task, that's the finding, and it's more valuable than any bug report.
Include the awkward paths too: an out-of-stock item, an invalid card, a required field left blank, an unusually long company name. Real users hit these constantly and happy-path testing never does.
Make defect reporting take seconds
UAT testers are doing you a favour on top of their real job. Their tolerance for reporting overhead is close to zero — and unlike your team, they won't push through friction because they don't have to.
If reporting means screenshot, crop, describe, email, they will report the two things that blocked them completely and silently absorb everything else. You lose the long tail, which is where most usability findings live.
Click-to-report on the page removes that. In pinreview a tester clicks the element, types a sentence, and the report automatically carries:
- A screenshot of exactly what they saw
- The CSS selector of the element
- Browser, OS, viewport and URL
- Console errors present at that moment
That last group matters especially in UAT, because your testers are on machines you've never seen — the corporate laptop with the locked-down browser and the ad blocker nobody mentioned. The context arrives without anyone having to know what a viewport is.
Guests are unlimited and free, so inviting six testers for two weeks costs nothing and requires no seat planning.
Triage: three buckets, not one
Everything from UAT lands in one of three places, and mixing them is what makes UAT feel endless:
Defects. It's broken. Fix before launch.
Usability findings. It works, but users struggle. Judgement call — some fix now, some go to the backlog.
Change requests. It works as specified; they want something different. These are new scope, quoted separately.
Sort every item as it arrives. The failure mode is letting change requests masquerade as defects — that's how a two-week UAT window becomes a second build phase nobody quoted for.
Tag them at the point of triage, in the tool, so the classification is visible to everyone rather than living in your head.
Define "passed" before you start
Agree the exit criteria up front, in writing:
- All critical-path tasks completable by every tester
- Zero open defects rated critical or high
- Medium and low defects reviewed and consciously accepted or scheduled
- Change requests logged and quoted, not silently absorbed
- Named approver signs off in writing
Without this, UAT ends when everyone gets tired, which is not a standard.
A two-week UAT that works
Days 1–2: Freeze the build. Set up access and the feedback widget. Send scripts and deadlines.
Days 3–7: Testers work through scripts. Triage daily — don't let a backlog accumulate.
Days 8–11: Fix defects. Mark items done so testers see movement, which keeps them engaged for the second pass.
Days 12–13: Confirmation round. Testers verify their own items only.
Day 14: Exit criteria reviewed, sign-off requested from the named approver.
Freezing the build in step one is not optional. Testing a site that changes underneath people produces contradictory reports and wastes everyone's time.
The bottom line
UAT for a small team is four decisions: real users testing real tasks, scripts written as outcomes, reporting that takes seconds, and written exit criteria agreed before anyone starts.
That's a fortnight of modest effort that catches the class of problem which is embarrassing and expensive to find after launch.