Prompting Claude for responsive layouts

Why "make it responsive" is an underspecified request

Asked simply to make a layout responsive, without further detail, Claude has to guess at a large number of decisions that a real responsive design actually depends on: which breakpoints matter, what should happen to a multi-column layout at a narrow width, whether an element should shrink, wrap, hide, or restructure entirely at smaller sizes. Each of those is a genuine design decision, not an implementation detail — and left unspecified, they get filled in by inference, which produces a technically-responsive layout that may not reflect any actual intended behaviour.

Specify behaviour at each breakpoint, not just that breakpoints exist

Rather than asking for "a responsive layout" and trusting the specifics to be inferred correctly, describe what should actually happen at each size that matters for your design — this three-column layout becomes two columns here, then a single column here; this sidebar collapses into a menu at this width; this table becomes a stacked card layout below this width. Specific per-breakpoint behaviour produces a layout that matches what you actually had in mind; a vague general request produces a plausible-looking but essentially improvised set of breakpoint decisions.

Content reflow is harder to get right than pure resizing

A layout that simply scales its existing structure down is easier to generate correctly than one that needs to genuinely restructure at a smaller size — a grid that becomes a stack, a horizontal navigation that becomes a menu. These structural changes are exactly where responsive implementations most often go wrong, because they require actually different markup or component behaviour at different sizes, not just different CSS values applied to the same structure. Flag explicitly wherever a layout needs structural reflow, not just resizing, since that's the case most likely to need extra attention and testing.

Testing across the actual range, not just two endpoints

A layout tested only at its widest and narrowest intended sizes can still break somewhere in between — a specific width where a wrapping decision looks wrong, where two elements collide before either endpoint's layout has fully kicked in. Testing across a genuine range of intermediate sizes, not just the two extremes, catches this category of failure that endpoint-only testing reliably misses, since the space between breakpoints is exactly where an implementation's transition logic gets exercised.

Real content behaves differently from placeholder content at each size

The same content that fits comfortably at a wide viewport can overflow, wrap awkwardly, or get truncated unexpectedly at a narrow one, and this interacts with content length in ways that only show up when testing with realistically varied content at each size — not just the tidy example text a layout was originally built and reviewed against. Test responsive behaviour with the longest and shortest realistic content you expect, not just whatever example content happened to be convenient when the layout was first generated.

Orientation and input method are part of responsive too, not just width

Responsive design is often treated as purely a question of viewport width, but a layout that handles width changes correctly can still fail to account for orientation changes or for the difference between touch and pointer input — a hover-dependent interaction that has no equivalent on a touch device, a layout that assumes landscape when a user is holding a device in portrait. Where these matter for your actual audience, state them as explicit requirements alongside width breakpoints, since they're easy to overlook if "responsive" is treated as synonymous with "handles different screen widths" alone.

See reviewing a Claude-generated UI for real issues for the broader review discipline this fits into, and common CSS mistakes Claude still makes for specific responsive-layout failure patterns worth watching for directly.