Responsive layout, explained without the jargon

Teams tend to reach for this after something has already gone wrong. Here is responsive layout without the vocabulary that usually surrounds it.

The measurable part of design is whether people can find what they came for and act on it without hesitating. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The short version

Design for the smallest screen first and let the layout grow. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The cost of getting this wrong is rarely visible on the day it happens.

Breakpoints should follow your content, not device names. The teams that handle this well are rarely the ones with the biggest budgets. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Making it stick

Test on a real phone, not just a resized browser window. It is worth being explicit about, because assumptions differ quietly. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The short version

Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. Three things worth confirming about responsive layout before you move on:

• Someone can say what the current setup is without going to look
• Breakpoints should follow your content, not device names — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.