Nevzat

Writing / CODE

How I check responsive details before shipping

A working checklist for spacing, breakpoints, and the details that drift between design and build.

how-i-check-responsive-details-before-shipping.md

Date

July 2026

Read

3 min

Tags

code

Before a page ships, I resize it slowly from the narrowest width to the widest and compare it against the design at every stop. Most responsive bugs are not broken layouts — they are small drifts in wrapping, alignment, and spacing that make a finished design read as almost right. This is the checklist I run to catch them.

Walk the breakpoints, not the devices.

Device lists age quickly; breakpoints describe intent. I resize slowly from narrow to wide and watch for the moments where a layout stops being deliberate — a heading that wraps awkwardly, a row that loses its alignment, a gap that doubles for no reason.

  • Check every heading at the narrowest width first.
  • Watch what happens exactly at each breakpoint, not just between them.
  • Keep touch targets comfortable before optimizing density.

The narrowest width goes first because it is the least forgiving. A headline that survives 320 pixels without an orphaned word or a broken hyphen will survive everything wider.

Watch the awkward middle widths.

The widths nobody designs for are where layouts drift: the stretch between a tablet layout and a desktop one, where a two-column grid is technically correct but visually starved. Three things fail here more than anywhere else:

  • Line length. Body text that measures comfortably at mobile and desktop can hit fifty-plus words per line in between. If a paragraph feels tiring, it is usually this.
  • Orphaned grid items. A three-item row that becomes two-plus-one right before the breakpoint. Either let it wrap evenly or hold the single column longer.
  • Hero spacing. Vertical padding tuned for desktop leaves a mid-width hero floating in space. Clamp-based spacing helps, but only if you actually look at the widths between the stops.

Compare against the design, not memory.

The last pass is always side-by-side with the mockup. Typography scale, rule weights, and spacing rhythm drift the most, and they are the exact details that make a calm layout read as finished.

Memory is generous. It rounds a 28-pixel gap to the 32 in the design, and it forgets that the border was supposed to be the strong variant. Side-by-side comparison is not about pixel-perfection — it is about catching the drift you have stopped seeing because you have looked at the build too long.

Run the same short list every time.

The pass takes about fifteen minutes on a typical page. Keeping the list short is what makes it actually happen before every release, not just the big ones.

responsive-pass.md
1. 320px first: headings, wrapping, touch targets
2. resize slowly: stop at every breakpoint
3. between stops: line length, orphaned grid items
4. side-by-side with the design: type scale, rules, spacing
5. real content: longest title, missing image, empty state

The last item matters more than it looks. Layouts are tested with the content that exists today; they break with the content that arrives next month. I swap in the longest real title I can find and remove an image on purpose before calling a page done.

What to reuse.

  • Resize slowly and stop at each breakpoint — the exact pixel where rules flip is where bugs live.
  • Give the in-between widths the same attention as the designed ones; check line length and grid orphans there.
  • Finish side-by-side with the design. Drift hides in type scale, rule weight, and spacing rhythm.
  • Test with hostile content: the longest title, the missing image, the empty list.

Get in touch

Have a page, product, or interface that needs a clearer direction?

Send the idea, the rough brief, or the messy first version. I'll help shape the next step.

Start a conversation