System & logic
Responsive breakpoint strategy
Design for 3 breakpoints max: mobile (<640px), tablet (640-1024px), desktop (>1024px). Don't design for every screen size.
3 tiers: 640px / 1024px / 1280px
8 breakpoints for every device model
How to apply it
- 1
Declare two steps, 640px and 1024px, so the base state plus those two give you three tiers, and stop the widest one widening near 1280px.
- 2
Change column count and density at those steps only; leave the widths between them fluid.
- 3
Never add a breakpoint for a specific device, aspect ratio, or screen model.
- 4
Test by dragging the window through each step and watching for one clean reflow, not several.
Why it works
A breakpoint should mark a width where the layout genuinely has to reflow, where a column count or a density changes, not a width where some particular phone happens to exist. Three tiers cover that, and three tiers need only two queries: the base state carries mobile up to 640px, one query opens the tablet tier from there, a second opens desktop at 1024px, and the layout stops widening around 1280px. Every extra breakpoint past those two multiplies the states you have to design, review, and regression-test, for differences nobody outside the team will ever see.
What breaks
Chasing device widths instead of reflow points leaves eight near-identical rules — 320, 375, 414, 480 and up — and the phone that ships at 393px falls into the 375px rule and renders cramped, with no single place to fix it because the width it needed sits between two rules that already exist.
Review questions
- 1
Does this layout reflow only at the declared steps, plus the base state below the first one?
- 2
Does dragging the window through a step produce one clean change rather than a sequence of small shifts?
- 3
Is there any media query targeting a specific device or screen model?