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
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
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
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.