Responsive Design Should Be a Content First Problem
When it comes to responsive design, most developers start from a device-first perspective: who are the biggest users of this site, and what widths do we need to support them? In contrast, some leading UX pundits are shifting to think responsive design content first. Breakpoints should start where the content flow breaks, not where a device performs well or poorly.
On small screens, the source order of a page often determines the reading order, and it must be a sensible order to read. The MDN Web Docs say that the source order of a page is the default basis of its reading order, and should express a sensible reading order. If the content order in the source makes no sense to readers looking at a small screen, then the page won’t work. On a narrow screen, that source order is easier to handle when the reading flow is well defined and the order of other content is clear.
To that end, web.dev recommends a paradigm shift: not starting from device screen widths, but starting from small screen widths first, and adding breakpoints from there. Even bootstrapping the CSS for a small screen may lead to needing few micro-responsive tweaks. “Responsive web design basics” advises this thinking:
Instead of designing for the desktop first and then scaling down the components, we can design for the smallest screen first and then expand it. This approach will minimize the number of breakpoints and optimize them.
But what exactly breaks for a responsive breakpoint? Where’s the minimum threshold? web.dev says to consider a breakpoint whenever “a block of text grows too big (about 10 words) or becomes difficult for users to read.”
That last assessment is key: the important question should be not what phone is reading the page, but more broadly, what content does the user need from a narrow viewport, and does that content break, jump, clutter, or flow awkwardly in its layout? A clearer statement still comes from Stephen Hay, quoted in “Responsive web design tips” at Sparkbox:
It doesn’t matter how many pixels it is or how many ems it is. Where it breaks, that’s your breakpoint. Hence the name “breakpoint”.
That might seem to imply an impractically granular breakpoint heuristic: a new breakpoint naturally at every div edge, ever so slightly changed. Fortunately, Dan Mall has written about a very accessible rule in “Media Query-less design, Content-based Breakpoints & Tweakpoints”: a breakpoint exists when the line length is too short or too long. That feeling quite precisely is, for content designers doing responsive layout, what the breakpoint is: a threshold where the content jumps from feeling readable to feeling not readable.
To that end, openweb deeply emphasizes placing that word-length threshold first in priority, and strategizing visually. In “The Text”, the author suggests the break that corresponds firstly to a single-column view that allows fitting 55 to 75 characters per line. Why then does the single-column rule place first, and make the screen most readable, not just good enough? Because in the narrow screen layout, you must first design what words read first,, allowing for lab work later. The openweb text advises starting the design in a single column, which helps avoid splitting the text into too many side-by-side boxes from the outset.
Meanwhile, Sparkbox elaborates on how that pivot happens: you can have different breakpoints inside of different breakpoints. This content-order not only flows by priority, varying by dimensions of the canvas, but rearranges as needed. There is a “content priority” map—thinking of the minimum screen sizes, and what content belongs on it, up to screen width. Only then come the box sizes and positions, etc. That and similar rearrangements are captured formally in the CSS properties reading-flow and reading-order discussed on MDN. Formal specifications like this are still experimental (as of 2024, at least).
Finally, this principle—content flow over placement before any media-type consideration—is also captured in detail in Jordan Moore's “content choreography” example, which also models content at smallest screens first, and cycles changes between the views around which sections are visually prioritized, and what must appear first for reading order on large or small screens.
The effect is a less abrupt feel in clever responsive boxes when rearranging items like buttons or menudata from thin-to-wide screens. And the layout still considers the accessibility of forcing the content order in the first place.