Responsive Design in UX

Responsive design is the practice of building one layout that adapts to the space it's given, instead of several layouts aimed at particular devices. One page, one URL, one codebase, whatever the screen. Ethan Marcotte named the approach in 2010 and defined it with three ingredients that still describe it accurately: a fluid grid, flexible media, and media queries.

This hub covers those ingredients, the build order that makes them tractable, how to decide where a layout should change, and the failures that only appear on real hardware.

The three ingredients

A fluid grid sizes columns in relative units — percentages, fr, ch — so the layout occupies whatever width exists rather than a width you picked. Flexible media means images, video, and embeds are constrained by their container (max-width: 100%) instead of their intrinsic pixel dimensions. Media queries are the mechanism that lets you change the rules at a given width.

Only the third is conditional. The first two are how the layout behaves in the ranges between your breakpoints, which is most of the widths your users actually have. A common failure mode is a page with five carefully chosen breakpoints and a rigid grid between them: it looks correct at exactly five widths and cramped everywhere else.

Mobile-first is a build order

Mobile-first means the narrow layout is your base stylesheet and min-width queries add to it as the viewport grows. It's a sequencing decision, not a statement about which users matter more.

The reason to sequence it that way is that the small screen has less room for error. A single column forces a priority order on your content, and once you've made those calls, wider layouts are additive. Starting from the desktop layout means every breakpoint is a subtraction made under time pressure, and subtractions tend to accumulate overrides that fight each other.

Breakpoints come from your content

A breakpoint is a width where your layout changes. The habit worth breaking is choosing those widths from a chart of device sizes, since the device has no relationship to where your particular design stops working. Resize the window slowly and the layout tells you: the first width where a line of text runs too long, or two elements collide, is a breakpoint.

Container queries extend this to components. Instead of asking how wide the viewport is, a component asks how wide its own container is, which is what you want for anything that appears in both a sidebar and a full-width hero.

For the standard framework values, how many breakpoints a project actually needs, and a workflow for finding them, see Responsive Breakpoints: A Practical Guide.

Responsive is not adaptive

Adaptive design serves one of several fixed layouts, selected by detecting the device or bucketing the viewport. Each layout can be art-directed precisely, which is a real advantage for marketing pages with strong compositions.

The cost is coverage. An adaptive site is correct on the widths someone anticipated and approximate on the rest, and the detection logic ages badly as new hardware ships. A responsive layout has no list of devices to keep current.

Reflow is an accessibility requirement

WCAG 2.2 success criterion 1.4.10 Reflow requires that content be usable at a width equivalent to 320 CSS pixels without forcing scrolling in two dimensions. That number is not only about small phones: it is also what a sighted user on a 1280px desktop gets when they zoom to 400%, which is a common accommodation for low vision.

This is the most useful reason to test at 320px even when your analytics show nobody browsing at that width. The users who need it are arriving zoomed, not on a small device, so they don't appear in your viewport data as narrow screens at all. See accessibility for how this fits with the rest of WCAG.

Where responsive builds usually fail

• Content hidden at narrow widths. display: none on mobile is a decision that small-screen users need less, which is rarely true and never verifiable from a desktop.
• Touch targets sized for a cursor. A control that works at 12px with a mouse is a miss with a thumb; WCAG asks for at least 24×24 CSS pixels.
• Testing in the emulator only. Browser device mode gets you geometry. It does not reproduce sluggish scrolling, real network conditions, on-screen keyboards covering the field you're typing in, or notch and safe-area insets.
• Text that reflows but doesn't scale. Breakpoints set in px ignore a user who raised their default font size. Setting them in em respects it.
• Tables. A data table is the one element with a genuine minimum width. Deciding early between horizontal scroll, a card-per-row transformation, or column priority is cheaper than retrofitting.

When a layout is losing users at particular widths and you need to know which failures actually cost completions, a Full UX Audit scores where the breakage is and how much it matters.