Designing for every screen size, not just mobile and desktop

Mobile-first design solved a real problem: for years, sites were designed for desktop and then awkwardly squeezed onto a phone, breaking constantly. Starting from the smallest screen and working up fixed that. But "mobile-first" as a mental model tends to collapse the whole spectrum of screens into two categories, phone and desktop, when the reality is a much wider, messier range in between.

A tablet in portrait mode is not a small desktop and not a big phone. A folded phone, an unfolded foldable, a small laptop, and a 32-inch ultra-wide monitor are all real, common screen contexts that a two-breakpoint mental model quietly ignores, even though collectively they account for a meaningful share of real visits to any given site.

None of this is a niche concern reserved for edge cases. Tablet ownership is widespread, laptop screens vary enormously in width, and browser windows on desktop are routinely resized, snapped to half the screen, or opened alongside other apps rather than maximized. A layout that was only ever checked at two fixed widths is, in a very literal sense, untested for most of the actual widths a real visitor's browser window might be.

The screens that get forgotten

Most responsive design testing happens at two widths: a common phone width and a common desktop width, because those are the easiest to picture and the two options built into every browser's device toolbar. The sizes that fall between and beyond those two are exactly the ones that don't get checked, and they're more common than they might seem.

• •Tablets in portrait mode, narrower than a laptop but much wider than a phone, often end up with awkward two-column layouts that were really designed for neither width.
• •Tablets in landscape mode are wide enough to look like a small desktop, but still touch-operated, so hover-only interactions simply don't work.
• •Small laptops and split-screen desktop windows: a browser window can be resized to nearly any width on desktop, not just stretched to fill the full screen.
• •Foldable phones, where a folded device is phone-width, but unfolded it becomes closer to a small tablet, and some content needs to adapt in real time as the fold changes.
• •Ultra-wide and large 4K monitors, where content designed only with a max-width in mind can float awkwardly in a sea of empty space, or worse, stretch to unreadable line lengths if no max-width was set at all.

Why the middle sizes break more often

A layout that looks intentional at a phone width and intentional at a desktop width can still look broken at a tablet width, because that width often triggers whichever breakpoint is closest without actually fitting the content well. A three-column feature grid that correctly becomes one column on phone and stays three columns on tablet can end up cramped and illegible. Three narrow columns is often worse than two comfortable ones or one wide one, even though technically the grid "responded" to the smaller width.

Navigation menus are another common casualty. A menu that collapses cleanly into a hamburger icon on phone and spreads out comfortably across a wide desktop header can end up half-collapsed and half-expanded at a tablet width, wrapping onto a second line or crowding against a logo, because nobody specifically checked that particular width during design.

None of this means every intermediate width needs a bespoke, hand-tuned layout of its own. Most of the time the fix is a small adjustment rather than a redesign: shifting a grid from three columns to two a little earlier than the desktop breakpoint, giving a navigation menu a bit more room to breathe before it wraps, or capping a paragraph's width so it doesn't stretch uncomfortably wide. The goal is a layout that degrades gracefully across the whole range, not one that only looks deliberate at two exact points and improvised everywhere else.

How a well-built template already handles this

This is one area where a production-ready template genuinely saves real design work, because handling the messy middle well requires testing across many widths, not just guessing at two. A template built with fluid, relative units and sensible intermediate breakpoints will already reflow reasonably at a tablet width or an unusual window size, rather than jumping straight from a mobile layout to a desktop one with nothing sensible in between.

That said, "the template already handles it" is a starting point, not a guarantee once you start customizing. Adding a new section, lengthening some text, or dropping in a wider image can all reintroduce the exact problems a template's original breakpoints were built to avoid.

1. 1
   Resize the browser window slowly, don't just jump between two widths

   Drag the window narrower gradually and watch for the exact width where something starts to look cramped or break, rather than only checking the two extremes.
2. 2
   Check an actual tablet, not just a phone and a desktop

   Tablet portrait and landscape are common real-world contexts that a two-device test plan skips entirely.
3. 3
   Set a max-width on text-heavy content

   Prevent paragraphs and headings from stretching to uncomfortable line lengths on very wide monitors.
4. 4
   Verify touch works everywhere hover does

   Any interaction that only triggers on mouse hover will silently fail for anyone on a touchscreen tablet or laptop.
5. 5
   Re-test after every content change

   New sections, longer headlines, or added images can all shift where a layout starts to break — recheck the middle widths, not just phone and desktop.

• ✓Mobile-first design handles phone and desktop well but tends to skip the range in between.
• ✓Tablets, foldables, small laptops and ultra-wide monitors are common contexts that a two-device mental model misses.
• ✓A well-built template's breakpoints already handle most of this range, but customization can quietly reintroduce problems.
• ✓Test by resizing the browser window gradually, not just jumping between two fixed widths.
• ✓Re-check the middle widths every time you add or lengthen content, not only when the template first ships.