Acceptance Criteria

Overview

Acceptance Criteria define the specific, testable behaviors and conditions that break a use case into concrete, reviewable parts.

If a use case defines the goal, acceptance criteria define what must be true throughout the experience for that goal to be successfully completed.

They focus on observable user behaviors and outcomes, giving teams a clear way to validate whether a design or flow actually works as intended. In UXit, acceptance criteria turn a use case into something concrete, reviewable, and measurable.

What Makes Good Acceptance Criteria

Acceptance criteria should be:

• Specific - Describe exactly what the user can do or see.
• Measurable - You should be able to verify it with a Pass/Fail.
• Observable - Evaluators can test it directly.
• Independent - Each criterion stands on its own.

Each criterion should describe a single behavior in simple, objective terms.

Some use cases only need a few acceptance criteria. Others may need many, depending on the complexity of the flow and how much of the experience needs to be spelled out.

Structure

Each acceptance criterion is a single statement that describes one user-visible behavior, state, or outcome:

Acceptance Criterion: A user can view a list of all available pizza types
Acceptance Criterion: A user can add a selected pizza type to their cart
Acceptance Criterion: A user can select toppings by clicking on each topping image

How AC Relates to Guidelines and Scoring

Acceptance Criteria and Guidelines work together during evaluations:

┌─────────────────────────────────────────────────────────┐
│  Acceptance Criteria    │  Guidelines                   │
├─────────────────────────┼───────────────────────────────┤
│  WHAT to evaluate       │  HOW to evaluate              │
│  "User can view cart"   │  "Is the cart accessible?"    │
│                         │  "Does it follow WCAG 2.1?"   │
│                         │  "Is feedback immediate?"     │
└─────────────────────────┴───────────────────────────────┘

• Acceptance Criteria define what should be evaluated
• Guidelines define how that behavior is assessed

During an evaluation, each guideline question is scored as Pass, Fail, or N/A. Those results roll up into category scores and an overall Flow score.

In that sense, acceptance criteria serve as the bridge between use cases and measurable UX evaluation, helping teams move from broad user flows to concrete validation and repeatable scoring over time.

Scoring Flow

Acceptance Criteria (behaviors)
        ↓
Evaluated against Guidelines (standards)
        ↓
Pass/Fail per question
        ↓
Category scores (e.g., Accessibility: 75%)
        ↓
Overall Flow score (e.g., 82%)

Example

Use Case: Add pizza toppings

Acceptance Criteria:
├── User can view available toppings after selecting a pizza type
├── Selecting "View toppings" opens a modal listing all toppings
├── User can select multiple toppings simultaneously
├── Selected toppings are visually indicated (checkmark, highlight)
└── User can remove toppings from their selection

Each of these criteria will be evaluated against your chosen Guideline Set during the evaluation process.

Best Practices

• Keep it simple - One behavior per criterion
• Use "user can" language - Focus on observable user actions
• Avoid ambiguity - Be precise about what should happen
• Add only the detail the flow needs - Some use cases are simple, while others need more criteria to cover important decisions, states, or outcomes
• Make it testable - Write criteria that can be clearly assessed during evaluation
• Align with Guidelines - Write criteria that can be meaningfully evaluated against your guideline questions
• Refine during design - Update acceptance criteria as mockups and wireframes become more detailed