Design QA Checklist
Give interface work a consistent review before it merges.
What it adds
A short review pass over hierarchy, spacing, states, copy, responsiveness, and accessibility, applied to every change that touches the interface.
What your agent is told to do
5
What your agent is told to do
5-
1
Write the checklist as a small number of concrete questions a reviewer can answer by looking at the running change, not as a list of principles nobody can verify.
-
2
Require every state to be shown, not described: loading, empty, error, partial, permission-denied, and the state with far more content than expected. A review that only sees the populated happy path approves half a feature.
-
3
Require a keyboard pass and a zoom pass on every change: tab through the new interface without touching the pointer, and view it at 200 per cent zoom with increased text size.
-
4
Keep the checklist short enough that it is genuinely completed. A checklist longer than a screen gets ticked without being read, at which point it is worse than nothing because it manufactures false confidence.
-
5
Mark each item as either a blocker or polish, and let polish items merge with a recorded follow-up. Automated rule checking belongs to the Accessibility Test Suite; this brief covers the judgement a machine cannot make.
Edge cases it handles
7
Edge cases it handles
7- Loading, empty, error, and permission-denied states are the ones shipped untested, because they are awkward to reach in development and the reviewer never sees them unless the checklist demands a screenshot of each.
- An interface that reviews well with a mouse can be unusable by keyboard and unreadable at 200 per cent zoom, so both passes have to be mandatory items rather than optional suggestions.
- A checklist that grows to forty items is completed by reflex, and every item on it stops meaning anything — cap it and remove an item whenever a new one is added.
- Without a blocker and polish distinction, either trivial spacing notes hold up a release or genuine defects are waved through as minor, and both outcomes teach people to ignore the review.
- Copy has to be reviewed as part of the same pass — placeholder text, inconsistent capitalisation, and error messages written for engineers all survive when the review is only about layout.
- The reviewer must see the change running rather than a static mockup, because hover, focus, and transition behaviour cannot be reviewed from an image.
- A checklist with no named owner for each item ends up self-reviewed by the author, which catches almost nothing.
Definition of done
8
Definition of done
8- The checklist fits on one screen and every item is answerable by looking at the running change.
- Loading, empty, error, partial, permission-denied, and overflowing-content states are each demonstrated before approval.
- A keyboard-only pass and a 200 per cent zoom pass with increased text size are required items.
- Every item is classified as a blocker or as polish, and polish items carry a recorded follow-up.
- Copy, capitalisation, and error wording are reviewed alongside layout.
- The review is performed by someone other than the author of the change.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Interaction Test Harness
Interaction Test Harness
Test the app the way a person uses it, through real clicks, keys, and focus.
What it does
A test setup that drives menus, dialogs, forms, and navigation through genuine user interactions and asserts on what the user can see.
How it works
- 1 Find elements the way a user finds them — by their visible label, their role, and their accessible name — rather than by class names or internal test hooks, so a test breaks when the interface becomes unusable and not when a wrapper is renamed.
- 2 Drive each interaction through both pointer and keyboard where both are supported, and assert on where focus ends up as well as on what the screen shows.
- 3 Assert on the visible outcome and wait for it to appear, rather than sleeping for a fixed interval and hoping. A timer-based wait is either slow on every run or flaky on a loaded machine.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/interaction-test-harness
UX Edge-Case Checklist
UX Edge-Case Checklist
Make every UI feature state what it does when things go wrong before it counts as done.
What it does
A required list of non-happy-path behaviours — failure, empty, loading, offline, permission, mobile, and accessibility — answered per feature.
How it works
- 1 Attach the checklist to the point where work is proposed and to the point where it is reviewed, so the answers exist before the feature is built rather than being reconstructed afterwards.
- 2 Require a concrete answer for each category: what the empty state says and what it offers, what appears while data is loading, what the user sees when the request fails, and what a user without permission gets instead.
- 3 Make each answer an outcome someone else could verify. A feature that says errors are handled has not answered; one that says a failed save keeps the form open with the values intact and a retry has.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/ux-edge-case-checklist
Responsive QA Matrix
Responsive QA Matrix
Decide which screen sizes, zoom levels, and text settings every flow has to survive.
What it does
A written matrix of viewports, orientations, zoom levels, and text-size settings that each major flow is tested against.
How it works
- 1 List the app's major flows, then write down for each the exact widths, orientations, zoom levels, and text-size settings it must pass, so testing stops depending on whichever window size the reviewer happened to have open.
- 2 Include the widths that break layouts rather than only the comfortable ones: the tablet in portrait, the narrow desktop window beside a chat panel, the phone in landscape, and the width just below each breakpoint.
- 3 Include a large-text pass at increased browser font size and at 200 per cent zoom, and treat clipped, overlapped, or unreachable content at those settings as a failure rather than a cosmetic issue.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/responsive-qa-matrix
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.