Designing UAT scenarios is challenging because you must balance realism, coverage, and time. If scenarios are too generic, users will not exercise their actual workflows. If they are too detailed or technical, business stakeholders may feel overwhelmed or confused. Good UAT design connects acceptance criteria to real business tasks.
From Acceptance Criteria to UAT Scenarios
Start with documented acceptance criteria and user stories, then translate them into end-to-end scenarios that a real user would understand. Each scenario should have a clear goal, starting conditions, main steps, and expected outcomes. Unlike detailed system test cases, UAT scenarios often describe what to do at a higher level, leaving room for natural variation.
# Example UAT scenario
Title: Finance user sends a corrected invoice to a customer.
Goal: Ensure finance can correct and resend an invoice without losing audit history.
Preconditions:
- Customer has an existing unpaid invoice.
Steps:
1. Open the customer account and locate the invoice.
2. Edit the invoice line items to correct quantity.
3. Add a note explaining the correction.
4. Save changes and resend the invoice.
Expected outcomes:
- The corrected invoice is sent to the customer.
- Audit log shows who made the change and when.
- Previous invoice version remains visible for history.When designing UAT scenarios, consider variations such as different user roles, customer types, or data sizes. You do not need to cover every combination, but including a few representative variations helps reveal issues that only appear under certain conditions.
Traceability and Coverage
Link UAT scenarios back to requirements or user stories so coverage is visible. This traceability helps project managers see which business capabilities were exercised during UAT and which still need attention. It also supports audits and compliance requirements in regulated industries.
Common Mistakes
Mistake 1 — Designing UAT scenarios without business input
When QA creates UAT content alone, they may miss critical workflows.
❌ Wrong: Building all scenarios from QA assumptions only.
✅ Correct: Collaborate with business users to ensure scenarios reflect actual tasks.
Mistake 2 — Ignoring negative and exception flows
UAT should also cover what happens when things go wrong.
❌ Wrong: Including only happy-path scenarios in the UAT pack.
✅ Correct: Add scenarios for failures, rework, and exceptions that matter to the business.