What are acceptance criteria in UAT?

Acceptance criteria in UAT are the testable conditions a feature must meet before the people who requested it sign off. Each one is a single statement that is either true or false for a given build, such as "body text meets a 4.5:1 contrast ratio." Testers record a pass or fail result for each criterion, with evidence.

Who writes UAT acceptance criteria?

The product manager usually owns them, with contributions from design (layout, tokens, states), accessibility or QA (WCAG criteria), and business stakeholders (tasks and copy). Developers should review them before the build starts, so unclear or untestable criteria get fixed early.

What is the difference between acceptance criteria and definition of done?

Acceptance criteria apply to one feature or user story and change every time. The Definition of Done applies to all work the team ships and rarely changes. For example, "every component meets WCAG 2.2 AA" belongs in the Definition of Done, while "the pricing toggle defaults to Annual" is an acceptance criterion.

What is an example of UI acceptance criteria?

A good UI acceptance criterion names a condition, a reference, and a context: "At 375px, no content scrolls horizontally and every tap target is at least 24×24 CSS pixels." Other examples: "card grid gap is 24px at every breakpoint" and "error messages use the approved copy and the error-600 token."

How do you document UAT pass/fail results?

Use one table per UAT round with a row per criterion: ID, criterion, result (Pass, Fail, Blocked, or Accepted with known issue), evidence, linked issue, tester, and date. Every Fail needs measured evidence and a ticket. Every "Accepted with known issue" needs a named owner who approved shipping with it.

UAT Acceptance Criteria

UAT Acceptance Criteria: Examples for UI and Design Sign-Off

Last updated: September 24, 2026

UAT acceptance criteria are the pass/fail conditions a feature must meet before the people who requested it sign off. Good criteria are testable statements, not opinions: "the primary button uses the brand-600 token and meets a 4.5:1 text contrast ratio" instead of "the button looks right." Each criterion gets one recorded result, the evidence behind it, and a linked issue if it fails.

New to UAT? Start with our guide to what user acceptance testing means, which covers the UAT definition, UAT vs QA, and the full process.

What Are UAT Acceptance Criteria?

User acceptance testing (UAT) is the last check before release, where the people the work was built for confirm it does what they need. Acceptance criteria are what they check it against. Atlassian defines acceptance criteria as "the conditions that a product, user story, or increment of work must satisfy to be complete," written as "clear, concise, and testable statements." A criterion is only useful in UAT if two different testers, looking at the same build, would record the same result.

Who Owns UAT on a Product Team?

Product manager: owns the UAT plan, final sign-off, and the go/no-go call. Writes criteria for user flows, business rules, content, and empty and error states.
Designer: owns design sign-off. Writes criteria for layout, spacing, typography, color tokens, and component states.
Accessibility lead or QA: owns accessibility acceptance against the WCAG success criteria that apply to the feature.
Business stakeholder or client: confirms the feature solves their problem. Writes criteria for real-world tasks, copy approval, and brand requirements.
Developers: fix failures and retest, and should review criteria before the build starts.

Acceptance Criteria vs Definition of Done

Acceptance criteria apply to one feature or user story and change every time. The Definition of Done, which the Scrum Guide describes as "a formal description of the state of the Increment when it meets the quality measures required for the product," applies to every piece of work and rarely changes. Put accessibility and responsive rules in your Definition of Done so UAT criteria can focus on what is specific to the feature.

What Makes a Good UI Acceptance Criterion?

One condition that is either true or false.
A reference: the design frame, design token, WCAG success criterion, or copy doc it is checked against.
A measurable threshold: a number, a named token, or an exact string. "At least 4.5:1" instead of "enough contrast."
A defined context: viewport, state, and user role.

Write visual criteria as a checklist and interaction criteria in Given/When/Then format, the structure from Gherkin: Given a signed-in user on the Billing page at 375px width, When they tap "Change plan", Then a bottom sheet opens with the current plan pre-selected and keyboard focus moves to its heading.

UAT Acceptance Criteria Examples for UI Products

Design sign-off

At 1440px, the page layout matches the approved Figma frame: same section order, column count, and alignment.
All text uses styles from the design system, and all colors resolve to design tokens.
Section spacing uses the spacing scale: 64px between sections and 24px inside cards.

Visual regressions

The global header, footer, and reused components show no change from the current production release.
The change does not alter any page outside its stated scope, and no text truncates or overflows in the longest supported translation.

Accessibility (WCAG 2.2)

Body text meets a contrast ratio of at least 4.5:1, and large text at least 3:1 (SC 1.4.3, Level AA).
Input borders, focus rings, and meaningful icons meet 3:1 against adjacent colors (SC 1.4.11, Level AA).
Every interactive element shows a visible focus indicator (SC 2.4.7, Level AA).
Pointer targets are at least 24 by 24 CSS pixels or meet the spacing exception (SC 2.5.8, Level AA).

States and responsive behavior

Buttons show default, hover, focus, active, disabled, and loading states as specified.
At 375px, 768px, and 1440px, no content scrolls horizontally and the layout matches its breakpoint frame.

Stakeholder verification

All customer-facing copy matches the approved copy doc word for word.
A stakeholder can complete the core task without help, and legal text appears where the legal reviewer specified.

How to Document UAT Pass/Fail Decisions

Record every criterion in one table per round with an ID, the criterion, a result (Pass, Fail, Blocked, or Accepted with known issue), evidence, a linked issue, the tester, and the date. Every Fail needs measured evidence, such as "caption text #9CA3AF on #FFFFFF measures 2.5:1," not a description. Every "Accepted with known issue" needs a named owner who approved shipping with that defect.

Turning a Failed Criterion Into a Bug Report

A failed UI criterion becomes a fixable bug when the report carries the criterion ID, page URL and viewport, the element's CSS selector, the computed CSS values actually rendered, a screenshot, and a severity. The criterion holds the expected value and the capture holds the actual one.

Running UI Acceptance Rounds With OverlayQA

OverlayQA is a design QA and website feedback tool that fills the evidence and bug-report columns. Click a failing element to capture a screenshot, CSS selector, computed CSS values, URL, and viewport. Set a severity, use the optional AI assist to draft the issue, and export to Jira, Linear, Notion, Asana, or Trello with two-way sync. Visual Comparison checks design sign-off against a Figma frame or uploaded image, the accessibility audit runs WCAG checks, and stakeholders can pin comments on a shared review link with no account or extension.

Frequently Asked Questions

What are acceptance criteria in UAT?: Acceptance criteria in UAT are the testable conditions a feature must meet before the people who requested it sign off. Each one is a single statement that is either true or false for a given build, such as "body text meets a 4.5:1 contrast ratio." Testers record a pass or fail result for each criterion, with evidence.
Who writes UAT acceptance criteria?: The product manager usually owns them, with contributions from design (layout, tokens, states), accessibility or QA (WCAG criteria), and business stakeholders (tasks and copy). Developers should review them before the build starts, so unclear or untestable criteria get fixed early.
What is the difference between acceptance criteria and definition of done?: Acceptance criteria apply to one feature or user story and change every time. The Definition of Done applies to all work the team ships and rarely changes. For example, "every component meets WCAG 2.2 AA" belongs in the Definition of Done, while "the pricing toggle defaults to Annual" is an acceptance criterion.
What is an example of UI acceptance criteria?: A good UI acceptance criterion names a condition, a reference, and a context: "At 375px, no content scrolls horizontally and every tap target is at least 24×24 CSS pixels." Other examples: "card grid gap is 24px at every breakpoint" and "error messages use the approved copy and the error-600 token."
How do you document UAT pass/fail results?: Use one table per UAT round with a row per criterion: ID, criterion, result (Pass, Fail, Blocked, or Accepted with known issue), evidence, linked issue, tester, and date. Every Fail needs measured evidence and a ticket. Every "Accepted with known issue" needs a named owner who approved shipping with it.