Responsive design means the content makes the right decision at the moment space runs out — not that a separate stylesheet is written for every phone model. If a service card at a narrow width turns into three lines of heading, an overflowing button and a squashed image, that is your content-break point, and it should drive the layout change.
Find the moment the content breaks
The viewport tag has to be in the head; without it some mobile browsers interpret the page at the legacy width of 980 pixels. That is a different thing from producing three fixed layouts labelled “mobile, tablet and desktop”. Defensive design means the site stays readable at a width you have not seen yet, which is exactly why flexible units and minimum/maximum values matter.
Why the viewport is a prerequisite
Choose a breakpoint by watching a card, menu or collapse when it gets squeezed; a phone’s model name is not a reliable criterion a year from now. Verify the viewport exists in the final source, not only in the mockup. When a browser interprets the viewing width differently, every breakpoint that looked correct on paper can stop working on a real handset.
From a single column to a flexible grid
One column on mobile is a defensible starting point because it keeps reading order and touch order obvious. Test the cards with real data: a long service name, a multi-digit price, a discount badge and a button with its full label. The first width at which that combination becomes hard to read is where your CSS decision belongs.
Images, text and touch on mobile
Grid suits stable ratios such as 1fr and 2fr, but it has to collapse back to one column when the content no longer fits. Responsive images are not only an overflow problem. Downloading a wide photo over a slow connection for something that will never be seen large on a small screen degrades the experience, so source selection is part of the design.
The three-width test protocol
Do not shrink a large image with max-width alone; srcset and sizes can prevent fetching a file that does not match the slot. Mobile-first typography does not mean a tiny font. Base size, line height and measure have to let people read without forced zoom, and keep the layout intact when they zoom voluntarily.
Problems a shrunk desktop layout will not solve
Font size should never be driven by vw alone; text must stay readable when the user zooms. A desktop menu that merely hides at small widths is still not a mobile solution. Check the open and closed states, the focus order, the button label and the ability to reach the primary goals separately.
The call button has to be tappable, and the gap around it has to prevent accidental taps. Resizing the browser window is not enough for testing: emulators and real devices differ in keyboard, safe area, touch behaviour and fonts. Try at least one form and one expandable menu on an actual phone.
Three test widths — 320, 768 and 1440 pixels — are a good substitute for guessing how devices behave. Write the defect report as width, content and behaviour: “at 320 pixels the three-line heading pushes the button down” is actionable in a way that “the mobile version is bad” is not.
One CSS pattern to start from, not to finish with
.cards { display:grid; grid-template-columns:1fr; gap:1rem; }
@media (width >= 48rem) { .cards { grid-template-columns:repeat(2,minmax(0,1fr)); } }
img { max-width:100%; height:auto; }
The three-width protocol for handover
At 320 pixels, run the primary path: open the menu, read the heading, tap the call-to-action, fill one field. If any step needs horizontal scrolling, zooming or repeated tapping, log it as a defect.
At 768 pixels, review cards and columns with long text. This is the width where many designs are neither mobile nor desktop, which is why ratio errors become visible.
At 1440 pixels, look at line length, whitespace and reading order. Being responsive is not only about not compressing; text set too wide destroys readability as well.
For every failure, ask first whether the content should change or the CSS should. Sometimes a long heading is not a design problem but a sign that the business message has become too vague or too wordy.
Avoid piling up breakpoints. If you are writing three exceptions for one component, the underlying layout model may be wrong and the Grid, Flex or HTML structure needs revisiting.
Test images under a constrained-bandwidth scenario too. The placeholder, the aspect ratio and the alt text should keep the page structure stable before the image finishes loading.
Finally, walk the mobile version with the keyboard or the browser’s accessibility tools. Invisible focus or an illogical order is not merely a technical flaw; it closes the path to completing the job for some users.
The output of this review is not a device list. It is a list of content constraints and expected behaviours that every future CSS change has to pass.
Common questions about shipping responsive
Do I need a breakpoint for every phone?
No. Set the break point where the content or the interaction fails, not on a device name.
Why does the page scroll sideways?
Find the fixed width, the unconstrained image, the long word or the bad min-width in DevTools; hiding the overflow only conceals the symptom.
The sign that the work is done
MDN explains that without a meta viewport, mobile browsers may render the page at 980 pixels, and that breakpoints should be derived from content failure rather than device names. Until that rule is honoured in real testing, the page has only been made smaller — it is not yet responsive.
Do not separate meaning from layout
On a small screen, dropping a sidebar must not mean dropping essential information. If the user needs the price, the limitation or a way to make contact in order to decide, that content stays in a sensible HTML order and only its presentation changes. The problem becomes obvious when visual order and source order diverge for someone using a keyboard or a screen reader.
Reserve space with an aspect ratio
For cards with a photo, set an explicit aspect ratio so buttons and text do not jump while the image loads. On mobile that jump feels unstable and can send a tap to the wrong element. Reserving the space is a design decision, not a secondary performance optimisation.
Test the form on its own
The card grid can be perfectly correct while the mobile keyboard covers the submit button over the phone field. A real test means entering bad data, seeing the error message, correcting it and submitting. In that test, check where focus lands after an error and how the user knows the submission succeeded.
Use fixed heights with care
A fixed height on a hero or a card is dangerous in a version that has translated text, error messages or a larger browser font. Let essential content take the height it needs instead of hiding the overflow. If the design only looks good when text is clipped, you have found a content or structure error.
Record every breakpoint with a test
Write down a screenshot and a reason for each break point — for example “at 640 pixels the services table became cards because the third column caused horizontal scroll”. That note prevents pointless reversals in the next redesign and shows the number came from observation.
The common failure of hiding content
Sometimes an explanation, a helper text or a trust signal is removed with display:none so the small screen looks tidy. Before doing that, ask whether the same information is needed for the user’s decision. If it is, show it in a clearly labelled accordion or a shorter order — do not take it away from everyone.
Do not forget the zoom test
A user may enlarge the browser text or use a system setting. In that state the collapsed menu, the card heading and the adjacent buttons still have to preserve the path to the goal. The 200% zoom test tells you whether the design was built only for the default size or genuinely flexes.
What belongs in a responsive handover report?
The handover should include three screenshots at the test widths, the list of failures found, the reason behind each breakpoint and the result of the form test. That report tells the next developer which behaviours were deliberate and which cases still need work.
Do not assume a pointer for touch
On a phone, check the spacing between the delete button, the add button and the links beside them. A finger has no pixel precision, and when targets touch each other a mis-tap gets blamed on the user. One short test with a real hand exposes this faster than staring at an emulator.
Do not assume a pointer for touch
On a phone, check the spacing between the delete button, the add button and the links beside them. A finger has no fixed pixel precision, and when targets touch each other a mis-tap gets blamed on the user. One short test with a real hand exposes this faster than staring at an emulator.
Sources
- https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
- https://www.w3.org/WAI/tips/designing/
Omid Bodagh
I am an SEO specialist who likes helping businesses get seen on Google. From WordPress to SEO, whatever an online business needs to grow, I can help with it.