product delivery
User Acceptance Testing: A Founder’s Practical UAT Guide
User acceptance testing proves a key workflow works for the people who own the outcome. Use this lightweight UAT plan before a release.
TL;DR — User acceptance testing is a release check led by the people accountable for the business outcome. Give them real scenarios, expected results, a safe test environment, and authority to say whether the release is ready.
User acceptance testing, or UAT, is where a business owner checks whether software supports the job it was built to do. It is not a second round of developer testing and it is not a meeting where people click around a staging site. The difference matters: QA asks whether the system behaves according to its specification; UAT asks whether a real workflow is acceptable to the person who must use, sell, support, or govern it.
NIST’s Guide to Software Acceptance recommends tracing test designs to requirements, including expected inputs and outputs, start and stop conditions, interfaces, and acceptance criteria. That sounds formal, but a founder can apply it to a small release in one page.
Start with the release decision
Write the decision before inviting anyone to test: “Can an account owner invite a teammate, assign a role, and see the correct access without support intervention?” This statement is better than “test permissions” because it gives the participant a job and gives the team a boundary for release.
Choose two to five scenarios that represent the highest-consequence paths. A founder might select first purchase, team invitation, report export, cancellation, or recovery after a failed payment. Ask a participant who knows the work, not the person who designed the feature. If the workflow has a compliance or finance consequence, include that owner as well.
Digital.gov’s usability testing guide is a helpful complement: plan the scenario, recruit the right users, prepare a script, and observe where their mental model differs from the product. UAT can capture that evidence while still ending in a clear release decision.
Build a small UAT plan
For each scenario, record the starting state, the steps in plain language, the expected business outcome, and what counts as a blocker. Avoid scripts that tell a user where to click; that only proves they can follow instructions. Say “invite a teammate who should only view invoices,” then observe whether the route and labels make sense.
Use a dedicated test account with realistic-but-safe data. List integrations that are simulated, disabled, or live so nobody mistakes a staging email for a customer notification. Name a single place to record findings. Each finding needs severity, evidence, owner, and a decision: fix before release, accept with a workaround, or defer with a trigger for revisit.
For a hypothetical example, a subscription flow could pass its screen-level checks yet fail UAT because the finance owner cannot reconcile a refund with the customer record. The remedy may be a missing audit field, not a visual adjustment. That is exactly the kind of problem automated checks rarely discover.
Keep QA and UAT separate
Engineers should still run unit, integration, and deployment checks. UAT is not permission to skip them. It uses a stable build as input and tests the business workflow that the team’s lower-level checks cannot judge. The production readiness work should already provide environments, logs, rollback paths, and ownership before UAT begins.
Do not turn a UAT session into requirements discovery for a large feature. If participants disagree about the intended outcome, record the decision gap, pause that scenario, and return to the product requirements. A useful product delivery cadence separates a bounded release from a new round of scope.
Close the loop after the session
End with a written outcome: accepted, accepted with named limitations, or not accepted. Link each finding to the resolved change or the accepted risk. If a participant needed explanation to finish a supposedly routine task, capture that too; it may be a documentation issue, a product issue, or an onboarding gap.
UAT becomes valuable when it changes the release decision occasionally. If every session ends with automatic approval, narrow the scenarios less or invite people closer to the real work. If every session generates dozens of taste notes, make the acceptance criteria sharper. A small, repeatable UAT practice is a practical way to find the gap between a feature that runs and a product someone can own.