Acceptance criteria are the specific, testable conditions a feature or user story must satisfy before the team can consider that behavior correct.
Start with this user story:
As a cardholder, I want to freeze my card so that I can prevent unauthorized transactions.
That still leaves important behavior undefined.
Acceptance criteria could include:
Given the card is active,
when the user confirms “Freeze card,”
then the card status changes to Frozen.
Given the freeze request fails,
when the system receives an error,
then the card remains Active and the user is told the freeze did not complete.
Given the card is already frozen,
when the user opens card controls,
then the interface shows the frozen state instead of offering another freeze action.
The Given-When-Then structure is useful because it separates context, trigger, and expected behavior.
A user story asks: What does the user need and why?
Acceptance criteria ask: What must be true for us to say that need has been correctly supported?
One story can have several acceptance criteria.
Acceptance criteria are usually specific to one story or feature.
A Definition of Done is a broader quality standard that a team applies across work.
Acceptance criterion: A declined card displays a recovery option.
Definition of Done: Code reviewed, tests passing, analytics instrumented, accessibility checked, and documentation updated.
“Works correctly” is meaningless. State what actually happens.
The team should be able to verify the result.
Describe expected product behavior without unnecessarily prescribing implementation.
Two people reading the criterion should not imagine two different outcomes.
Success behavior alone rarely describes a complete product.
Story: User can reset password. Criterion: User can reset password. Nothing became clearer.
“The page should load quickly” is not testable until “quickly” has a measurable meaning.
Valid input is only half the behavior. Invalid input, permissions, failures, and state conflicts may matter just as much.
The point is to expose ambiguity before implementation, not document it afterward.
Product, engineering, design, and QA can all contribute. Shared understanding matters more than authorship.
There is no fixed number. If the list becomes enormous, the story itself may be too broad.
Only when a particular UI behavior is genuinely required. Avoid freezing design decisions before they need to be fixed.
Acceptance criteria turn “it should work” into “this is exactly what must happen for us to call it working.”
That small shift prevents a remarkable amount of interpretation later.
User story · PRD · Product management · MVP
See practical Given-When-Then examples in Figr’s guide to writing PRDs.