What breaks when you design only for the two most common screen sizes?

What breaks is everything you never checked: the widths in between your two snapshots and the widths beyond them. Designing to the most common phone and the most common desktop gives you two points of confidence and a long stretch of untested layout in every direction. The page looks finished because the two views you look at are finished, but responsive design is the whole range, not two coordinates, and the range is where the cracks live.

The mechanism the “design for the most common phone and desktop and you’re covered” assumption glosses over is that layouts do not interpolate gracefully on their own between the points you tuned. The space between a 390-pixel phone and a 1440-pixel desktop is full of real devices: large phones, small tablets, big tablets, half-width browser windows, laptops at odd zoom levels. At some width your three-column grid still wants to be three columns but no longer has room, so the columns pinch and the text inside them strands. At another, a headline that fit on two lines wraps to four and shoves the hero off the screen. None of this shows up at your two checkpoints because your two checkpoints were never where it would happen.

A designer meets this the first time a real user opens the site on a small tablet in portrait, the classic forgotten width. The mobile layout was tuned for a phone and looks cramped and oversized stretched across the tablet; the desktop layout was tuned for a wide screen and overflows or collapses awkwardly when squeezed down to it. The site is technically responsive, it does respond, but it responds into a broken middle state nobody designed. The same trap waits at the extremes: a very narrow phone where the padding eats the content, and an ultrawide monitor where a fixed-width block floats in an ocean of empty space or a full-width row stretches lines of text past the point of readability.

The reason this keeps happening is that the two snapshots are seductive. They are the widths you can pull up instantly, the ones in the analytics report, the ones a stakeholder asks to see in a review. Designing to them feels like covering the majority, and in a sense it does, but coverage of the most common widths is not the same as coverage of the widths a given user actually has, and a single visitor on a stranded width has a fully broken experience, not a slightly-less-common one. The long tail is not a rounding error to that person; it is their whole encounter with the product.

One place the rule bends: this is about testing too few widths, not about choosing breakpoints. Good breakpoints come from where your specific content actually breaks, and you only find those by watching the layout flex across the continuum, slowly dragging the window from narrowest to widest and noting every width where something pinches, overflows, or strands. Two well-chosen snapshots are still two snapshots; the long tail of real devices does not cluster politely around them.

Check the layout across the full range, especially the in-between widths and the extremes. Resize continuously rather than jumping between two presets, fix what cracks at the small tablet, the half-width window, the tiny phone, and the ultrawide, and let your breakpoints fall where the content demands rather than where the two most popular devices happen to sit. A design that only works at two widths is a design that works by coincidence.