User Acceptance Testing is the last honest checkpoint before production. Product owners and real users decide whether the build matches how the business actually works — not whether the unit tests are green.
Done well, UAT catches wrong workflows, bad terminology, and "technically correct but useless" screens before customers do. Rushed or skipped, it turns into a week of firefighting after launch.
UAT is not QA with nicer stakeholders
QA checks that the software behaves as designed. UAT checks that the design matches the business. You want people who run the process day to day — not developers clicking through their own happy path.
Typical finds in a real UAT:
- A required approval step nobody implemented
- Validation rules that don't match finance's actual constraints
- Labels that confuse users ("deactivate" vs "retire")
- Reports that crawl under production-sized data
- Integrations that break a weekly ops ritual
- UX gaps that make people invent workarounds on day one
Timeline that doesn't blow up the release
Before UAT (about 2–3 weeks out)
Write acceptance criteria people can argue about. "Feels fast" is not a criterion. "Report generates in under 5 seconds for 50k rows" is.
Build scenarios from real work. Core jobs-to-be-done, not edge-case puzzles. Edge cases belong in QA.
Prep data and roles. Clean environment, realistic volumes, anonymized production-like data, accounts for admin / standard / guest (or whatever your roles are).
Name the signers. Product owner, a business analyst if you have one, and one or two power users per major role. If nobody has authority to say "ship anyway," UAT stalls on every medium bug.
Block the calendar. Most products need 1–2 weeks of UAT. Send access docs and a short "how to file an issue" note before day one.
During UAT (1–2 weeks)
Run parallel tracks when you can — checkout and reporting don't need the same person. Log pass/fail, notes, severity, and date for every scenario. Keep a short daily sync for blockers only.
Split findings into launch-blockers vs deferrable. Not every annoyance deserves a delay.
After UAT (a few days)
Fix blockers first. Retest with the same stakeholder who found the issue. Then get a written sign-off. Verbal "looks good" evaporates the first time something goes wrong in prod.
Practices that keep UAT useful
Keep engineers out of the tester seat. They know where the bodies are buried. You need people who don't.
Give a one-page test guide. Environment URL, how to reach each scenario, what to verify, how to report (what they did, what they saw, evidence).
Don't crush it into one afternoon. Five to seven business days is a minimum for anything non-trivial; complex systems often need two to three weeks.
Test with boring, heavy data. Ten sample records will not reveal the query that dies at a million rows.
Decide in the room. When someone finds an issue, choose fix-now vs next-release quickly and write the reason down. Scope creep loves an undecided UAT.
Pitfalls I see constantly
Using UAT as a second QA cycle. If functional testing isn't done, stakeholders drown in broken buttons and never reach business questions.
Fuzzy pass/fail. Disagreement at sign-off almost always traces back to vague criteria.
Toy data. Performance and weird validation only show up at realistic scale.
No decision maker. Every medium issue becomes a committee.
UAT in production. If you're "accepting" in prod, you're already late for safe fixes.
How stakeholders should file what they find
Business users will not open DevTools. They need a path that takes a minute: mark the screen, say what they expected, send. Tools that attach session replay, screenshot, and browser info (SnagRelay included) keep UAT feedback from turning into a scavenger hunt for engineering.
The goal isn't a perfect ticket every time. It's enough evidence that a fixer doesn't need a meeting to understand the failure.
What "good" looks like at the end
You leave UAT with signed acceptance on critical flows, a short list of deferred issues with owners, and a team that isn't guessing whether the business can actually use the release. That's the whole point — confidence with receipts, not a ceremonial checkbox.