Browser Support Matrix
State which browsers the app supports and prove it, instead of assuming.
What it adds
A documented list of supported browsers and versions, the fallbacks for unsupported ones, and automation aligned to that list.
What your agent is told to do
5
What your agent is told to do
5-
1
Derive the supported list from who actually uses the app and what the business has committed to, using real usage data and any contractual or regulatory requirement, rather than copying a default list from somewhere else.
-
2
For each capability the app depends on, write down what happens when it is missing — the feature degrades, the feature is hidden, or the user is told the browser is unsupported — and make sure something is defined for every case.
-
3
Make the automation run against the browsers the policy names. A stated support commitment that no test exercises is an unverified claim.
-
4
Detect an unsupported browser and say so plainly at the point of entry, naming what will not work, rather than letting the user discover it through a blank screen halfway through a flow.
-
5
Review the list on a fixed schedule against current usage, and remove a browser only after usage has fallen below the agreed threshold. Viewport sizes and zoom levels are the Responsive QA Matrix's concern, not this one's.
Edge cases it handles
7
Edge cases it handles
7- A support list chosen from habit rather than from usage data will spend effort on browsers nobody uses while breaking for a version a large customer is standardised on, so the decision has to be evidenced.
- Every unsupported capability needs a defined fallback path — silently doing nothing leaves the user with a control that appears to work and does not, which is worse than an honest refusal.
- Automation that runs in one engine while the policy claims three means two of those claims are untested, and the gap only surfaces as a customer report.
- Support lists go stale quietly; without a scheduled review the app carries workarounds for browsers with no remaining users and misses versions that have since become common.
- Version ranges expressed as latest only are meaningless for locked-down corporate estates and for users who do not update, so the policy must state a minimum version rather than a moving target.
- Embedded and in-app browsers inside social and messaging apps behave differently from their standalone counterparts and must be listed explicitly if any inbound traffic arrives through them.
- Feature detection is the correct basis for a fallback; user-agent sniffing misidentifies new versions and locks out browsers that would have worked.
Definition of done
8
Definition of done
8- The supported browser and version list is written down and traceable to usage data or a stated requirement.
- Each capability the app depends on has a documented fallback or an explicit unsupported message.
- Automated tests run against every browser the policy claims to support.
- An unsupported browser is detected and told what will not work before the user begins a flow.
- Fallback decisions are made by feature detection, not by parsing the user agent.
- The list carries a review date and a documented threshold for dropping a browser.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Visual Regression Testing
Visual Regression Testing
Catch unintended visual changes before they reach users, not after.
What it does
An automated comparison of rendered screenshots against approved baselines, run on every change.
How it works
- 1 Identify the surfaces where a silent visual change would actually hurt — the shared components, the pricing table, the checkout, the dashboard — and capture those rather than screenshotting every route in the app.
- 2 Freeze everything that varies between runs before capturing: load fonts and wait for them, fix the clock to a known instant, disable animations and transitions, and render from seeded fixtures rather than live data.
- 3 Capture each surface in every theme and at every viewport the app claims to support, and label each capture with that combination so a diff says exactly which one moved.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/visual-regression-testing
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
Theme Acceptance Criteria
Theme Acceptance Criteria
Set the bar every theme has to clear before it ships to anyone.
What it does
A release gate for light, dark, branded, and customer-supplied themes, covering contrast, first paint, tokens, and print.
How it works
- 1 Write the criteria against the theme layer, not against individual screens. The question is whether a set of token values is fit to ship, and the answer should not require walking every page by hand.
- 2 Require measured contrast for text, icons, borders, focus rings, and disabled content in every interactive state — resting, hover, focus, active, and selected — because a palette that passes at rest often fails on hover.
- 3 Cover the surfaces that sit outside the component library: chart series and their gridlines, map and image overlays, embedded documents, illustrations, and any asset shipped as a fixed-colour file that will not follow the theme.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/theme-acceptance-criteria
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.