A useful responsive design test checks whether people can complete the same task as the available space changes. Resizing a page and confirming that columns stack is only one part of that review. You also need realistic content, open menus, errors, and evidence that important actions remain reachable.
Use the checklist below to build a focused test matrix for a web application. The suggested dimensions are starting points for a team's test plan, not a promise of complete device coverage.
Build a matrix around the changed experience
Choose a user task first: saving settings, selecting a plan, filtering a table, or completing a form. Then select the combinations most likely to challenge the changed layout.
| Dimension | Suggested starting cases | What to inspect |
|---|---|---|
| Width | 320, 390, 768, and 1280 CSS pixels | Wrapping, stacking, clipping, and reachability |
| Breakpoint boundary | Just below and above each affected breakpoint | Controls that disappear, collide, or change order |
| Height | A short viewport and the normal task viewport | Fixed footers, dialogs, and access to the last field |
| Content | Short values, long labels, empty results, many results | Assumptions hidden by ideal sample data |
| State | Initial, loading, error, expanded, selected, submitting | Layout changes after interaction |
| Theme | Each supported theme | Text and controls against their actual surfaces |
| Input | Pointer, keyboard, and relevant touch devices | Reachability and usability in the intended environment |
Do not mechanically multiply every row into a huge suite. Start with the changed component, one surrounding page, and the most important user task. Add combinations when they expose a distinct risk.
W3C's reflow guidance uses a width equivalent to 320 CSS pixels for vertically scrolling content, with exceptions for content that requires a two-dimensional layout. A narrow-width check alone does not establish WCAG conformance. W3C Reflow guidance.
Check the layout before and after interaction
- Main content fits the available width without unintended page-level horizontal scrolling.
- Long labels wrap or truncate according to an explicit product decision.
- The primary action remains reachable after validation errors appear.
- Menus, popovers, and dialogs fit their available space and can be closed.
- Fixed headers and footers do not cover the content needed to complete the task.
- Tables and other deliberately wide regions have a usable local overflow treatment.
- Empty, loading, and error states preserve the page's navigation and context.
- Controls remain usable in the smallest supported layout.
For each item, write down the actual route and state you inspected. “Mobile checked” does not say whether the account menu was open or the form had three validation messages.
If your review includes accessibility, evaluate pointer target size against the applicable criterion. WCAG 2.2's minimum target-size criterion specifies 24 by 24 CSS pixels with defined exceptions, including spacing; it is not a blanket 44-pixel rule. W3C Target Size (Minimum).
Test around your actual breakpoints
In Tailwind CSS, unprefixed utilities apply across sizes, and breakpoint-prefixed utilities apply from that breakpoint upward. sm: does not mean “phones.” Projects can also customize breakpoints, so inspect the project's definitions before building the matrix. Tailwind responsive design.
An illustrative toolbar might use a horizontal row at wider sizes and a vertical stack below the transition. Test just below the transition with the longest supported labels. Then test just above it, where the row has the least available space.
Also consider the component's container. A card inside an open sidebar can have less room than the viewport width suggests. Record whether the failure follows the viewport, a parent panel, or a particular content value. That observation helps identify which constraint needs to change.
Diagnose overflow before hiding it
Consider a hypothetical account header with an avatar, a long organization name, and an action menu. The short demo name fits. A longer name pushes the action menu off the screen.
The cause could be a fixed width, an unbreakable string, an oversized child, or an intrinsic sizing constraint. Flex and grid items can use a content-based automatic minimum width, depending on their layout conditions. MDN min-width reference.
Inspect the overflowing element and its parents before choosing a fix. If the text region is the item that should shrink, changing its minimum-width behavior may be appropriate. If the content must remain fully readable, wrapping may be the correct design. If the region is a data table, local scrolling may be intentional.
After any change, repeat the original failing case. Simply hiding page overflow can make the scrollbar disappear while leaving an action inaccessible. Your acceptance criterion should describe the task the user can now complete.
Automate the stable parts of the matrix
Playwright supports configurable viewport dimensions and device emulation parameters, including touch-related settings and color scheme. Choose settings that correspond to the behavior you intend to exercise. Playwright emulation.
Here is an illustrative screenshot test to adapt to an existing Playwright project. It assumes the project already supplies a running application's baseURL, a deterministic /settings/profile route, and any required authenticated state. It has not been run against your application.
Screenshot assertions wait for consecutive stable screenshots before comparison. That does not prove the application has reached the business state you intended, so add a meaningful readiness condition for your fixture. Playwright screenshot assertion reference.
This example captures only the initial viewport. Add scrolling and interaction checks for controls farther down the page; a full-page image alone would still not verify their behavior.
Review initial references before accepting them. Add a separate interaction case when the defect depends on opening a menu or submitting a form. Keep a targeted manual check for behaviors your capture does not exercise, such as the actual on-screen keyboard on a supported phone.
Record a result that another person can reproduce
A practical responsive test record contains the build, route, viewport, content fixture, interaction steps, expected behavior, observed behavior, and evidence. Include which states were not checked when that affects the conclusion.
For example: “At 390 CSS pixels, submitting the empty profile form adds error text that pushes Save below a fixed footer. Save must remain reachable by scrolling without dismissing the errors.” This is an illustrative report with a concrete acceptance condition, not a claim about a real product.
Use the UI bug report template to capture those details and the design QA checklist for the broader release review.
Design Bug Bot reviews mobile layout concerns in GitHub changes and includes screenshots when rendering succeeds. See the product workflow.