Responsive Design
Status: Stub Category: Design Default enforcement: Soft Author: PushBackLog team
Tags
- Topic: design, frontend, layout
- Skillset: design, frontend
- Technology: generic, css
- Stage: execution
Summary
Responsive design is the practice of building interfaces that adapt their layout, typography, and interaction patterns to the viewport, device capability, and user preference in which they are rendered. A responsive interface is not a separate mobile version — it is a single implementation that is correct at any size.
Rationale
As of 2024, mobile devices account for more than half of all global web traffic. An interface that is only designed for a desktop viewport is an interface that is degraded or unusable for the majority of users who encounter it.
Beyond screen size, responsive design encompasses:
- Input method — touch vs. pointer vs. keyboard
- Network conditions — reduced asset loading on constrained connections
- User preferences — reduced motion, high contrast, font scale
Responsive design is not a mobile afterthought. It is the default expectation of a quality product.
Guidance
Mobile-first thinking
Design for the smallest, most constrained viewport first. Constraints force clarity. If content and navigation make sense on a small screen, they will work at every size. The reverse is not true — desktop-first designs frequently produce mobile layouts where content is either hidden, awkwardly stacked, or requires the user to zoom.
Mobile-first applies to both design and CSS: write base styles for small viewports and override with min-width breakpoints as the viewport grows.
Breakpoints
Breakpoints should be defined in the design system and shared between design tooling and code. Derive breakpoints from content, not device names — “at what width does this layout break?” rather than “where are iPhone widths?”
A minimal breakpoint scale:
| Name | Range | Typical use |
|---|---|---|
sm | < 640px | Single column, full-width elements |
md | 640–1024px | Two-column layouts, condensed nav |
lg | 1024–1440px | Multi-column layouts, sidebar patterns |
xl | > 1440px | Wide-screen refinements, max-width containment |
Fluid layouts
Prefer fluid units over fixed pixel widths:
%,vw,frfor widthsremandemfor typography (respects user font preferences)- CSS Grid and Flexbox for layout rather than fixed absolute positioning
min(),max(),clamp()for fluid typography and spacing that scales between constraints
Touch targets
Interactive elements must meet minimum touch target sizes:
- WCAG 2.1 AA requires 44×44px touch targets
- Spacing between adjacent targets should be at least 8px
- Hover-only interactions (tooltips, dropdown reveals on hover) require alternative touch patterns
Adaptive loading
Beyond layout, responsive design includes adapting asset delivery to device capability and network conditions:
- Serve appropriately sized images using
srcsetandsizes - Prefer system fonts or variable fonts to reduce font loading overhead
- Use
prefers-reduced-motionmedia query to disable animations for users who have opted out - Respect
prefers-color-schemefor dark mode support
Testing
Responsive design must be tested across real breakpoints, not just browser resizing:
- Test on physical devices where possible — emulators do not replicate touch precision or scroll inertia
- Test with keyboard navigation at each breakpoint
- Test with browser font size scaled up (simulate user accessibility preferences)
- Include responsive behaviour in acceptance criteria for all UI stories
Common failure modes
| Failure | Description |
|---|---|
| Desktop-first CSS | Base styles assume large viewports; mobile requires heavy overrides |
| Fixed pixel widths | Elements overflow or clip on small screens |
| Untested breakpoints | Design only reviewed at one size; layout breaks elsewhere |
| Hover-only interactions | Features inaccessible on touch devices |
| Ignoring user preferences | Animations play regardless of prefers-reduced-motion; dark mode ignored |