Organise user acceptance testing
Acceptance testing checks whether a service supports expected tasks under defined conditions. It needs observable criteria, test data and a correction decision. A general opinion about appearance does not replace a completed journey.
Photo: Glenn Carstens-Peters / Unsplash · Context photograph; no affiliation with FDS is implied.
Write observable scenarios
Describe a task without prescribing every click: find information, compare an option or submit an enquiry. Specify the starting point and expected result. Avoid guiding participants towards the right answer.
Prepare authorised trial data and disable real-world actions where necessary. Also test errors: missing fields, empty results and interruptions.
Vary testing contexts
Include people representative of tasks and use situations. Test phones, wide screens and keyboard navigation. Record device, browser and experience to interpret results.
User observation complements technical accessibility checks. It does not independently establish full conformance. Offer suitable participation arrangements and informed participation.
Describe reproducible defects
For each discrepancy record page, steps, expected result and actual result. Add a useful screenshot without sensitive data. Separate blockers, possible workarounds and personal preferences.
Prioritise by task impact and affected journeys. An invisible button preventing submission takes priority over a decorative adjustment. Assign an owner and a recheck.
Retest and decide on launch
Retest corrections under the conditions that revealed them. Check neighbouring journeys when a shared component changes. Do not close a defect solely because a file changed.
Retain test limitations, deferred items and the decision owner. A decision may accept an identified gap with a deadline, but should remain explicit. Prepare checks immediately after launch.
A record to keep with the decision
| Item | Evidence |
|---|---|
| Scenario | Starting point and expected outcome |
| Defect | Reproducible steps and impact |
| Decision | Retest, owner and limitations |
Frequently asked questions
How many participants are needed?
The number depends on audience diversity and journey risks. Start with focused tasks, document covered situations and add missing contexts rather than relying on a universal number.
Reference material
W3C · Évaluation avec les utilisateurs
The practical checklist is an editorial synthesis to adapt to your service. It does not constitute a certification or an audit result.