Device Testing Presets
Give every tester the same named conditions instead of whatever their laptop does.
What it adds
Named presets bundling viewport, pixel ratio, pointer type, safe-area insets, network speed, and CPU throttling for repeatable testing.
What your agent is told to do
5
What your agent is told to do
5-
1
Define a small set of named presets that each bundle a viewport, pixel ratio, pointer type, safe-area insets, network profile, and CPU throttle, so a defect can be reported as a preset name rather than a paragraph of settings.
-
2
Include at least one deliberately hostile preset with a slow network and a throttled processor, because loading states, skeletons, and timeout handling are invisible on a fast machine and are exactly what breaks for real users.
-
3
Include presets that exercise a touch pointer and a device with safe-area insets, so hit targets, hover-only affordances, and content trapped under a home indicator are caught rather than assumed.
-
4
Require a preset to cover a keyboard appearing and an orientation change during a flow, not merely at its start, since both resize the viewport while state is already on screen.
-
5
Version the presets with the QA documentation and change them in the same commit, and state clearly that these presets do not replace testing on real hardware. Which viewports each flow must pass is owned by the Responsive QA Matrix; this brief owns the reproducible conditions themselves.
Edge cases it handles
7
Edge cases it handles
7- An emulated device is not the device — touch latency, real font rendering, memory pressure, and browser-specific quirks only appear on hardware, so presets must be presented as a first pass rather than as sufficient coverage.
- Without a slow-network and throttled-CPU preset, nobody ever sees the loading state, the request timeout, or the layout shift that real users on a poor connection see every time.
- The on-screen keyboard and a rotation mid-flow both change the usable viewport while a dialog or a form is already open, and testing only from a fresh load in each orientation misses the resulting clipping and lost scroll position.
- Presets that drift away from the QA documentation produce results nobody can reproduce, so the two must move together and each preset must be named and dated.
- A preset that sets a viewport but leaves the pointer as a mouse will report hover states working on a device that has no hover at all.
- Throttling that is applied inconsistently between runs makes performance observations meaningless; the profile must be fixed and stated rather than approximate.
- Presets accumulate for devices no longer in the support list, so retiring one has to be as routine as adding one.
Definition of done
8
Definition of done
8- Each preset has a name and specifies viewport, pixel ratio, pointer type, safe-area insets, network profile, and CPU throttle.
- At least one preset applies a slow network and a reduced CPU, and loading and timeout behaviour is verified under it.
- At least one preset uses a touch pointer and non-zero safe-area insets.
- Presets cover a keyboard appearing and an orientation change occurring during a flow, not only at its start.
- Preset definitions live with the QA documentation and are updated in the same change.
- The documentation states which findings require real hardware and are out of scope for the presets.
- 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.