How to Check Responsive Design
A responsive design checklist should tell you whether someone can finish a task at different screen sizes. A tidy mobile screenshot is useful evidence, but it cannot tell you whether the menu closes, a comparison remains understandable, or the submit button disappears behind the keyboard.
Start with the task, then inspect the layout while performing it. For a marketing page, that might mean understanding the offer, comparing plans, and finding the next step. For a product interface, it could mean locating a record, changing one value, and confirming the result. Use the same task across widths so that you can tell which changes help and which simply move the problem elsewhere.
Prepare one page that can expose the problems
Pick a page with enough variety to make the review meaningful. A nearly empty landing page may pass easily while the pricing page fails. Choose a page that includes navigation, a substantial heading, an image, repeated content, and at least one important action. If the site has a form or a data table, include a page containing that pattern as well.
Replace unusually convenient sample content before checking. A card called “Team” is unlikely to expose the same issues as “Regional operations and customer support.” Use realistic descriptions, the longest ordinary navigation label, and an image with a clear subject near one edge. These are test inputs, not attempts to make the page fail through absurd content.
Write down what must remain possible. On a fictional workshop booking page, the visitor should be able to read the date, understand the location, compare session options, and start a booking. If the narrow layout hides the location to save space, the design has lost information needed for the task even if its visual composition looks cleaner.
Use checkpoints, then inspect between them
Desktop, tablet, and mobile previews are a practical starting point. They are not the complete set of conditions your page will encounter. A resizable browser window, a split-screen tablet, or a zoomed page can leave the layout at widths that no device preset covers.
Choose a narrow checkpoint, a middle checkpoint, and a wide checkpoint. The particular numbers are less important than including the conditions relevant to your audience. For an initial review, you could inspect around 360, 768, and 1440 CSS pixels, then resize gradually between them.
Look especially near changes in structure. The header might fit comfortably at the wide checkpoint and collapse correctly at the narrow one, yet become crowded just before it switches. A three-column section may need more room than its parent gives it at an intermediate width. The trouble often appears before a breakpoint, rather than at the breakpoint itself.
The responsive design guidance from web.dev recommends choosing layout changes around content needs rather than named devices. Apply that principle by recording the first width where a component stops working comfortably. That gives you a reason for the change and a useful place to retest afterward.
A useful reference: GOV.UK keeps the reading task intact
The GOV.UK layout guidance starts with a single column on small screens and recommends a two-thirds reading column for many wider pages. Its official two-thirds/one-third example shows the same content becoming a vertical sequence when space narrows.
The useful thing to borrow is the relationship, not the fraction. The main explanation remains first; the supporting material follows it. On your own page, a legal condition required before payment is not secondary merely because it fits nicely in a sidebar. Decide its role before copying a layout that gives it lower priority.
This produces a sharper test than “the columns stack.” Choose a sentence in the supporting column and identify the action it qualifies. After stacking, can a reader encounter the action without ever seeing that sentence? If so, the responsive implementation may be geometrically correct and editorially wrong. Move the qualification with the action or make the dependency explicit.
A second useful test is to follow the page with the keyboard. Visual rearrangement can leave the source order untouched. If the screen appears to place a control after the explanation but focus reaches it before the explanation, the review needs both layout and reading-order evidence. A screenshot alone cannot resolve that disagreement.
Make responsive design testing task-based
Use the following checks as a starting record, then remove rows that do not exist on your page. Write the expected result before the review; otherwise it is easy to excuse a defect after seeing it. The examples below are test conditions, not universal breakpoint settings.
| Condition | Do this | A useful passing result |
|---|---|---|
| Just before the header collapses | Open every navigation level | Labels, close control and final destination remain reachable |
| 320 CSS-pixel content width | Read and complete the primary task | Ordinary text and controls fit; any two-dimensional region scrolls locally |
| Enlarged browser text | Read the longest title and next action | The section grows without clipping either |
| Recoverable form error | Submit incomplete input, then correct it | The message stays associated with its field and input survives |
| Sticky action visible | Reach the final line of content | Nothing required for the decision is covered |
| Touch keyboard open | Edit the final field on a device | The field and completion route remain usable |
Do not combine all these observations into one pass percentage. A clipped decorative caption and an unreachable payment action are not equivalent failures. Fix blocked tasks first, then incorrect or missing information, then reading comfort and visual polish. That order gives a small team a workable release decision without pretending that an incomplete review proves every device is supported.
Walk through the page in use
Navigation: open, choose, close, reopen
Open every navigation control that changes with the layout. A menu icon can look perfectly aligned while revealing an unusable panel. Inspect the open state, select a destination, close the panel, and reopen it. If the page contains nested navigation, test a deeper item rather than stopping at the first level.
On the workshop example, the wide header might show Sessions, Speakers, Venue, and Book a place. The narrow version may move the first three links into a panel. Check that Venue still exists, that its label is readable, and that closing the panel returns the visitor to the page without leaving a transparent overlay in the way.
Pay attention to the relationship between the menu and the rest of the screen. A tall panel may need its own scrolling behavior, or it may need to allow the page to scroll. Whatever approach you choose, the visitor should be able to reach the final item and the close control. A panel that only works when the viewport is tall enough is still a responsive problem.
Repeat the task using the keyboard. You are checking whether the layout change has stranded a control or hidden the current focus. Record the exact sequence that causes the problem so the fix can target it.
Reading order: follow the mobile sequence
When columns become a single stack, the reading sequence deserves a fresh review. The desktop version may rely on spatial relationships that no longer exist. A price alongside an explanation can become a price several screens away from that explanation. A caption may appear to describe the next image instead of the previous one.
Read down the narrow page without referring to the desktop layout. Ask what each section prepares you to understand next. On a booking page, session details should arrive before a visitor is expected to choose a session. Putting a large decorative image between the choice and its explanation can make the action feel disconnected.
Watch for alternating desktop sections. A left-image/right-text section followed by a right-image/left-text section may create inconsistent mobile ordering if the implementation simply stacks the source elements. Decide whether each image introduces the text or illustrates it afterward, then make that relationship consistent where the content serves the same purpose.
Overflow: identify the cause before hiding it
Scroll through the full page and look for content extending beyond its container. Common clues include a clipped button label, a card edge that leaves the screen, and a footer link that pushes neighboring content out of place. Check overlays and expanded content too; the resting page may fit while an open control does not.
Distinguish accidental overflow from an intentional scrolling region. A wide comparison table may reasonably scroll horizontally inside its own area. An entire page moving sideways because of one oversized illustration is a different problem. If horizontal scrolling is intentional, the visitor needs a way to notice that more content exists and keep track of what they are reading.
Avoid treating a global overflow-hiding rule as a completed repair. It can make the outer edge look clean while cutting off the item that was causing the issue. First identify the responsible element, then decide whether its width, wrapping, placement, or container needs to change. After the change, verify that no useful content has simply vanished.
For the workshop page, imagine a ticket card with a long venue name. The useful fix may be allowing the name to wrap and the card to grow. Shrinking every piece of text in the card would also make it fit, but it would impose a readability cost on information that was not causing the problem.
Check images for meaning at each crop
An image can be technically contained and still fail to communicate. Look at what survives when its shape changes. If the image is meant to show an entrance, the entrance should remain visible. If it explains a feature, the relevant part of the interface should not become too small to distinguish.
For an editorial photograph, you may be able to change the crop while preserving the subject. For an instructional screenshot, cropping away labels could remove the explanation. These two assets need different decisions. Review the purpose of the image before choosing between a tighter crop, a different asset, or a larger dedicated section.
Use the surrounding text as a check. If the sentence says “Choose the highlighted session,” but the highlight cannot be seen at the rendered size, the illustration is no longer supporting that sentence. A close-up of the relevant control may be more useful than a full-screen image scaled down to fit.
Inspect the actual delivered asset rather than judging only its source dimensions. A high-resolution file can be unreadable when displayed too small; a correctly sized image can appear soft if the wrong variant is loaded. Note which condition you observed. That distinction helps the person implementing the fix choose between a layout change and an asset change.
Keep decisions and controls together
A responsive layout should preserve the connection between information and the action it informs. On a pricing section, that means the plan name, relevant limits, price, and action remain identifiable as one choice. On a booking form, it means the selected session remains clear when the visitor reaches the final action.
Check repeated buttons carefully. Three identical “Continue” labels are easy to confuse if their parent cards become visually fragmented. You may need stronger grouping, clearer plan labels, or a more descriptive action. Start with the least disruptive change that restores the relationship rather than adding heavy decoration to every item.
Test controls when labels wrap. A two-line button can be acceptable if its padding, alignment, and neighboring controls remain coherent. What matters is whether the user can still distinguish the action and activate it comfortably. A label clipped after its first word is a more serious failure than a button becoming slightly taller.
Include sticky elements in this review. A fixed booking bar may help keep the primary action available, but it can cover a price note or the last form field. Scroll to the bottom, open an expandable section, and bring a field into focus. The element needs to earn its space in those states, not only in the polished opening screenshot.
Test forms after they change state
Forms deserve a separate pass because interaction changes the amount of content. An error message, a selected option, or a confirmation notice can add height and alter the relationship between fields. Review the form with realistic input and at least one recoverable error, rather than checking only empty boxes.
On a narrow screen, bring up the on-screen keyboard on a real device when possible. Check whether the active field remains visible and whether the next action can be reached. A desktop preview helps with layout, but it cannot by itself establish how every mobile browser handles its keyboard and viewport.
Use a longer value in a field that ordinarily allows it. A full organization name, a multi-part surname, or a long email address can reveal clipping that a short sample misses. The goal is not to change the application’s validation policy during visual review. It is to make sure accepted input remains understandable in the interface.
After an error, confirm that the page still communicates what needs correction. The error should not become separated from its field because another section moved. If the form uses a summary, inspect the connection between that summary and the individual field. Note whether the issue is layout, wording, focus behavior, or actual validation so that the correct owner can address it.
Separate page-fit problems from content problems
Some apparent responsive failures are caused by unclear content rather than insufficient space. A paragraph that repeats the heading may make the mobile page unnecessarily long. A row of six actions may reflect an unresolved priority decision. Before compressing the design, ask whether the content has a clear role.
Other failures are firmly layout problems. Important terms should not be deleted simply because the current component is too rigid. A cancellation condition on a booking page may be essential even if it complicates the composition. The right response could be a better location, an expandable explanation, or more vertical space, depending on when the visitor needs it.
A useful distinction is whether the information should be available at all widths. If yes, work on presentation. If its relevance genuinely depends on the current task or state, conditional display may be appropriate. Width alone is a weak reason to remove information that supports the same decision on every device.
MDN’s responsive design overview frames responsiveness as a combination of flexible layout, media, typography, and viewport behavior. That is a helpful reminder when assigning fixes: one small-screen failure does not mean the entire page needs to be regenerated.
Turn observations into small, testable revisions
Keep one issue focused on one failure. Describe the component, the condition, and the expected behavior. For example, “At the middle preview width, Venue overlaps Book a place. Collapse this header before those items touch; preserve the labels and booking destination.” That is a more useful revision request than “Make the tablet layout better.”
If you are working in OpenDesign, desktop, tablet, and mobile previews can provide the initial comparison. You can use comments or send the observation to chat, then review the updated HTML. Manual edits to supported text, links, images, and styles are useful when the required change is specific.
For structural changes, identify what should stay stable. If the header needs a different layout, keep its content and destinations fixed during that revision. If an image needs a better crop, avoid changing the surrounding copy at the same time. Holding those variables steady makes it easier to judge whether the change solved the recorded issue.
Retest the failing condition first, then the neighboring widths and related states. A fix that makes the menu fit at one width might create an unnecessarily cramped header at another. A taller button may expose a fixed-height card. This short regression pass is part of the original fix, not an optional round of polishing.
Finish with a review record someone else can use
Before calling the responsive review complete, repeat the primary task from beginning to end at each checkpoint. Read the content, open the controls, and reach the result. Then inspect at least one width between the checkpoints where the layout changes. Save evidence of the important open or expanded states, not just three attractive resting views.
Your final note can be brief: which pages were checked, which widths and browsers were used, which tasks succeeded, and which conditions remain untested. If a real mobile device was unavailable, say so. If a table intentionally scrolls sideways, record that decision so the next reviewer does not mistake it for an unnoticed defect.
Prioritize unresolved issues by what they prevent. A hidden action or unreadable requirement can block the task. An awkward but readable heading is usually a lower priority. This gives the next revision a sensible order without pretending that visual quality is unimportant. It simply prevents minor polish from obscuring the issues that stop people using the page.