Responsive Design: One Layout, Every Screen

UI/UX · ~9 min read

The old way to design responsively was to draw three fixed artboards — phone, tablet, desktop — and hand them over as if they were three separate websites. That approach is dead, and it was never really alive. Real screens come in thousands of widths: a 360px budget phone, a 412px mid-range Android, a 768px tablet held in one hand, a 1024px small laptop, a 1440px display, a 3840px monitor, and a resizable browser window somewhere in between. You cannot draw them all. You have to design a layout that adapts.

This guide covers the mental model and the practical techniques: fluid type, flexible grids, content-driven breakpoints, and why modern CSS lets you think in systems instead of screenshots.

Think in flows, not frames

The single biggest shift is to stop thinking of a design as a fixed image and start thinking of it as a set of rules that respond to available space. A card does not have a width of 380px; it fills its container up to a sensible maximum and then stops. A sidebar does not "exist" on mobile; it collapses into a drawer above a certain width. When you design the rules, the same code produces every screen by itself.

A useful mental test: resize your browser slowly from 320px to 1600px and watch the design. Nothing should ever break, overlap, clip or jump awkwardly. If it does, the rule is wrong — not the screen size.

Mobile-first is about constraints, not phone worship

Mobile-first means you design the narrowest, most constrained version first and then add complexity as space allows. The benefit is not that phones are more important; it is that a small screen forces you to prioritise ruthlessly. If you can make it work at 360px, the desktop version practically designs itself by addition.

In practice, mobile-first styles are your base, and wider screens get layered on top:

1. Base styles target the narrow single-column layout.
2. Wider breakpoints introduce multi-column grids, sidebars and larger type.
3. Spacing scales up with the viewport rather than staying fixed.

Fluid type with clamp()

Fixed type sizes want fixed layouts. When text should scale with the viewport between a floor and a ceiling, use a fluid function rather than a breakpoint jump. A typical pattern sets a minimum size for small screens, a maximum for large ones, and a viewport-relative value in between.

For example, a page heading might scale from around 28px on a phone up to 48px on a wide desktop. Expressed as a fluid rule, it reads: minimum 1.75rem, preferred 1rem plus about 3vw, maximum 3rem. The result is smooth, has no size where the heading looks cramped, and needs no breakpoint at all.

Flexible grids and intrinsic layout

Fixed column widths break. Use flexible units and let content find its own shape. Two techniques cover almost everything:

• Fractional and minimum-based grids: columns that distribute remaining space and wrap automatically once they get too narrow, so a card grid reflows from three columns to two to one with no media query.
• Auto-fitting content: set a minimum sensible card width and let the browser decide how many fit per row. You describe the constraint, the browser does the arithmetic.

This is sometimes called "intrinsic" or "content-driven" layout, and it is the quiet revolution of the last few years. Instead of you deciding that the switch from three columns to two happens at exactly 900px, you say "cards need at least 280px" and the layout adapts to any container, any zoom level, any screen.

Breakpoints driven by content, not devices

Forget the specific widths of popular phones. Add a breakpoint only when your content starts to look wrong — when a line of text gets too long to read comfortably, when a card grid gets awkward, when a navigation bar runs out of room. The breakpoint is a response to an observation, not a guess about hardware.

Reading comfort gives you a concrete anchor: aim for roughly 45–75 characters per line. If a paragraph is stretching to 120 characters on a wide screen, cap the measure — a maximum width of around 65–70 characters (often implemented as a max-width in the region of 60–70ch) is a reliable default.

Breakpoints that usually earn their place

Treat those numbers as starting suggestions, not scripture. Your content will tell you where it actually breaks.

Container queries: the component-level answer

Traditional media queries respond to the viewport, which is a problem for reusable components. A card sitting in a wide sidebar and the same card in a narrow main column get identical viewport-based styling even though their containers are wildly different. Container queries fix this: a component can respond to the width of its own container rather than the window. Design your cards, list items and widgets to look right based on their own space, and they become genuinely portable across the whole product.

Images, media and density

Images deserve the same flexibility as layout. Serve appropriately sized images for the screen, offer a few resolutions so high-density displays get a crisp version without punishing slow connections, and always reserve space so the layout does not jump as images load. A hero image that is 3000px wide on a phone wastes the user's data and slows the page; the same asset chosen well loads in a fraction of the time.

The testing habit

Responsive design is verified by resizing, not by admiring a mock-up. Build a short checklist and run it every time:

• Resize slowly from 320px to 1600px — no breakage, no overlap.
• Test a real narrow phone, ideally around 360px.
• Zoom the browser to 200% and check nothing is clipped.
• Rotate to landscape — horizontal layouts are often forgotten.
• Check touch targets are still at least 44×44 px once everything shrinks.

Do this often and responsive design stops being a phase at the end of a project and becomes how you work the whole way through. One layout, every screen — because the rules do the adapting.