04 — UI, UX, and Usability Checklist#

Review whether the product helps people complete meaningful tasks with understandable navigation, predictable interactions, inclusive experiences, and evidence-based improvements. This focuses on product usability; complete the dedicated Accessibility, Testing, Security, and Performance checklists separately.

Scope: Backend / API-specific. This file is one part of the 04_UI_UX_and_Usability.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this template into project-specific review records; leave the shared template unchecked.
2. Mark [x] only when a check has been verified with user-research findings, design reviews, prototypes, task-based observations, implementation evidence, or recorded decisions. Track failed and N/A items with reasons in project notes or issues, keyed by UX ID, not in this shared checklist.
3. Prioritize real user goals, observed task outcomes, and critical errors rather than visual preference alone. Tailor checks to supported platforms, user groups, risk, and product maturity.
4. Complete ## API Checks and ## Frontend Checks separately where applicable; record N/A with a reason for projects that lack the relevant interface.
5. Revisit important journeys after changes to target users, features, navigation, integrations, or design patterns. This checklist does not establish formal WCAG conformance.

API Checks#

• UX-069 Document which API responses determine the user-visible state of each critical flow.
• UX-070 Ensure user-facing loading, error, success, and no-results experiences are specified for expected API outcomes.
• UX-071 Map validation failures to specific, understandable field messages without exposing internal stack traces or raw implementation codes.
• UX-072 Define a consistent error representation so the frontend can distinguish authentication, permission, validation, rate-limit, and server failures.
• UX-073 Specify user-facing behavior when a request times out, is cancelled, or returns after the user navigates away.
• UX-074 Design retry and idempotency expectations to avoid confusing duplicate submissions or duplicate transactions.
• UX-075 Provide predictable pagination, filtering, and sorting contracts that preserve user context as results change.
• UX-076 Supply machine-readable availability or progress signals for asynchronous tasks when the user needs to track completion.
• UX-077 Ensure API response fields provide the labels, help content, units, dates, and localization data required for accurate presentation.
• UX-078 Document how stale, partial, or eventually consistent data should be communicated to users where material.
• UX-079 Define ownership and fallback UX for third-party API failures, missing data, quotas, and service disruptions.
• UX-080 Use stable public-facing identifiers and deep-link targets where API-driven navigation or sharing is required.
• UX-081 Review API changes with frontend/consumer teams for user-visible regressions in wording, missing states, and workflow continuity.
• UX-082 Keep authorization outcomes consistent with clear, recoverable user experiences while enforcing permissions on the server.

Release gate#

• Priority user journeys, target user groups, and expected outcomes are documented and have been reviewed with appropriate stakeholders.
• Representative usability evidence supports that users can complete critical tasks, including handling common errors and recovery paths.
• No unresolved, unaccepted usability issue blocks essential tasks, causes material confusion, or risks significant unintended consequences.
• Core navigation, forms, system feedback, and critical mobile/responsive experiences have been reviewed against agreed design and user needs.
• API and frontend user-experience dependencies are understood, with owners and documented treatment of failures, latency, and partial results where applicable.
• Responsible reviewers have recorded the decision and accepted risks in project-specific records.

Domain-specific approval rule: Block UX sign-off for unresolved critical-task failures, deceptive or materially misleading interface behavior, inaccessible core journeys awaiting required specialist review, or unknown user-impact risks lacking an accountable owner. UX approval does not substitute for accessibility conformance or production verification.

Trusted references and scope#

The checklist adapts the following authoritative user-experience, design, and accessibility guidance into observable project review questions. General design heuristics are not universal hard requirements; evaluate their suitability for the actual audience and context.

• Nielsen Norman Group — 10 Usability Heuristics for User Interface Design — feedback, consistency, user control, error prevention, recognition, and recovery.
• GOV.UK Service Standard — Understand users and their needs — evidence-driven problem framing.
• GOV.UK Service Standard — Make the service simple to use — intuitive tasks and end-to-end usability.
• GOV.UK Service Manual — Plan user research for your service — inclusive research questions, participants, and iteration.
• GOV.UK Service Manual — Using moderated usability testing — representative tasks and observational findings.
• Nielsen Norman Group — Tree Testing: Evaluate Menu Labels and Categories — information architecture and findability testing.
• U.S. Web Design System — Components — established visual and interaction patterns.
• GOV.UK Design System — Recover from validation errors — clear messages, field recovery, and preservation of input.
• W3C WAI — Form Instructions — labels and accessible instructions.
• W3C WAI — Validating Input — error guidance and accessible validation.
• W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — relevant accessibility success criteria, with detailed conformance review in 05_Accessibility.md.

Applicability: Some practices are service-, platform-, or audience-specific. Do not treat GOV.UK's design-system implementation decisions as mandatory for unrelated products. Human usability evaluation is essential where risks or complexity warrant it; quantitative usability metrics require a suitable sample and method.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: navigation, responsive layouts, form errors, visual states, and user flows; include API and service behavior where applicable.
• Cross-stack: Lighthouse + Storybook.
• Python: Playwright + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Playwright + Storybook + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Playwright + Storybook + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• web-design-guidelines — Audit interface design and usability patterns (vercel-labs/agent-skills, 33,937 repo stars).
• webapp-testing — Exercise key browser flows and visual states (anthropics/skills, 193,495 repo stars).
• interaction-design — Review interaction, feedback, and error handling (wshobson/agents, 42,437 repo stars).

How to check: In a project-specific copy, have the agent audit the backend / API scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.