Shrinking Is Not Designing: Responsive Done Right

Almost every website built in the last eight years is responsive. The layout reflows, nothing spills off the side, the text doesn't need pinching. By the narrow technical definition, the job is done. And yet a very large number of these sites are miserable to use on a phone — the exact device three-quarters of the people visiting them are holding.

The gap between those two facts is the whole subject of this article. Responsive design was never supposed to mean "the desktop page, narrower". It was supposed to mean the page makes different decisions depending on what it can see about the device. Most of the time, nobody made those decisions. The page just shrank, and shrinking is not designing.

What responsive was meant to solve

Before responsive design, the common answer to phones was a separate mobile site — usually on m.yourdomain.com. You maintained two sites. They drifted apart. Content that existed on one didn't exist on the other. Google had to work out which was which.

Responsive design replaced that with one set of pages that adapt. The mechanism is simple enough to explain in a paragraph: the browser tells the page how wide the screen is, and the stylesheet contains rules that say "below 768 pixels wide, stack these three columns into one". That rule is called a breakpoint. Most themes ship with sensible defaults. That's why your site is technically responsive even if nobody thought about it — the theme did the stacking for you.

Stacking is the easy 20%. It stops the horizontal scrollbar. It does not answer any of the questions that actually matter: what should be at the top, what should be cut, what should be tapped instead of hovered, how much should load before something useful appears.

The decisions that actually change on a small screen

Here is the practical difference between a page that was designed for a phone and one that was merely allowed to fit on it.

Order, not just width

On a laptop, a three-column row is read more or less at once. On a phone, those three columns become a queue, and someone has to decide the order. The theme's default is usually left-to-right, which is often exactly wrong. If your homepage hero has a large photo on the left and your actual proposition plus the enquiry button on the right, the phone visitor gets a screen of photograph and has to scroll to find out what you do.

A designed mobile page puts the sentence that explains the business, and the one action you want, above the first scroll. Everything else queues behind it.

Hover has to become tap

Hover does not exist on a phone. Any interaction that depends on a mouse resting over something — dropdown menus, tooltips explaining pricing tiers, image captions that appear on hover, "reveal more" cards — either does nothing on a touchscreen or triggers awkwardly on the first tap and follows the link on the second. Product grids on ecommerce sites are a common casualty: the second image and the quick-add button live behind a hover state that a phone user will never see.

Navigation is a different object

Collapsing eleven menu items into a hamburger icon is not a mobile navigation strategy, it's a place to hide a problem. If a visitor must open a menu, scan eleven items, open a submenu and scan seven more, on a screen showing about eight lines at a time, most will go back to search results instead. The mobile decision is which three or four destinations matter, and whether they should be visible without opening anything at all.

Forms shrink badly

A form that is pleasant on a desktop can be punishing on a phone. Fourteen fields in two columns becomes twenty-eight rows of typing on a keyboard that covers half the screen. Worth checking on your own site right now: does the phone field bring up the numeric keypad? Does the email field bring up the keyboard with the @ symbol? Those are single-attribute changes in the markup that most builds simply never set. Date pickers built for mouse clicks are a particular horror on touch.

Tap targets and thumbs

Apple and Google both publish minimum touch target guidance — Google's Material guidance uses 48×48 density-independent pixels, Apple's human interface guidelines say 44×44 points. Links stacked in a footer at 12px with 4px of gap fail that badly. And the top-left corner of a large phone is the hardest place for a thumb to reach, which is precisely where most themes put the menu.

Weight

The desktop hero image is often a 2400-pixel-wide file. Shrinking it in CSS does not make it a smaller download — the phone still fetches every byte, over a mobile connection, on a mid-range processor. A designed responsive build serves a different file to a small screen, using srcset, so the phone downloads a 700-pixel version instead. This is the single most common reason a "responsive" site fails Core Web Vitals on mobile while passing on desktop.

How it goes wrong in practice

Three patterns account for most of it.

The desktop mock-up that was never redrawn. The design was approved as a set of desktop screens in a PDF. The developer implemented those, and the breakpoints were whatever the framework provided. Nobody ever drew the phone version, so nobody ever made a decision about it. This is extremely common and it is a process failure, not a technical one. Ask for the mobile screens before you approve a design, and approve those with equal attention.

The page builder with three sets of settings. Elementor, Divi and similar tools let you set different padding, font sizes and visibility per device. That's genuinely useful. It also means a page can look correct on the tablet setting and broken on the phone setting, and nobody notices because the person building it was working on a 27-inch monitor. Sections get hidden on mobile to "tidy things up" — and sometimes those hidden sections contain the content that explained the product.

Tables and PDFs. A price list in a wide table, or a brochure served as a PDF, does not respond to anything. On a phone a wide table either scrolls sideways awkwardly or squashes into unreadable columns. Fee structures, specification sheets and schedules need a genuinely different presentation on small screens — usually each row becoming its own labelled block.

What we would not buy

A few things sold in this category that aren't worth your money.

• A separate mobile site in 2025. If anyone proposes building m.yourdomain.com alongside your main site, decline. You will maintain two things, they will diverge, and you'll spend the rest of the site's life reconciling them.
• A "mobile optimisation" package that is font sizes and padding. If the deliverable is a list of CSS tweaks with no discussion of what comes first on the page, what gets cut and what images get served, you're buying tidying, not design.
• AMP, now. Accelerated Mobile Pages was Google's stripped-down mobile format. It was once required for the top news carousel; that requirement was removed in 2021. Building AMP versions today means maintaining a second copy of your content for very little return. A fast normal page beats an AMP page.
• An app, as the fix for a bad mobile site. It's a much larger and more expensive problem with a far smaller audience.
• Device-detection redirects. Serving different URLs based on sniffing the user agent string breaks in ways that are hard to debug and hard to test. Serve one URL and let the layout adapt.

How to check your own site in twenty minutes

You do not need a developer for the first pass. Take your own phone, on mobile data rather than office Wi-Fi, and work through this.

1. Open the homepage. Before scrolling, can you tell what the business sells and what you're meant to do next? If the first screen is a logo and a photograph, that's a finding.
2. Try to make an enquiry using one thumb only. Note anything you have to change grip for.
3. Open the menu. Count the taps to your three most important pages.
4. Find your price list, specification table or fee structure. Read one row of it.
5. Open a product or service page and try to tap the third link in a list of links. If you hit the wrong one, tap targets are too small.
6. Fill in the phone number field on a form. Did the number pad appear?
7. Rotate the phone to landscape. Anything that now overlaps or disappears is a genuine bug.

Then run the page through Google's PageSpeed Insights and read only the mobile tab. If the Largest Contentful Paint — the time until the biggest visible thing has loaded — is above 2.5 seconds, you almost certainly have desktop-sized images being served to phones. Google documents that 2.5-second boundary publicly; it's a threshold you can check rather than a claim anyone has to take on trust.

What you're looking for across all of it is not ugliness. It's evidence of decisions not made.

What to do next

If the twenty-minute check turned up two or three annoyances, that's normal maintenance and a developer can work through it in a defined piece of work. If it turned up that the phone version simply queues your desktop page in an order nobody chose, that's a design question and worth addressing properly at the next redesign, with mobile screens drawn and approved first.

We do this kind of work as part of building and rebuilding websites, and as standalone fixes through ongoing technical support when a full rebuild isn't warranted. If you'd like a second opinion on what you found, send us the URL and tell us which phone you tested on — the device matters, and we'd rather look at the real thing than guess.

Questions we get asked