PushBackLog

Responsive Design

Soft enforcement Stub by PushBackLog team
Topic: design Topic: frontend Topic: layout Skillset: design Skillset: frontend Technology: generic Technology: css Stage: execution

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:

NameRangeTypical use
sm< 640pxSingle column, full-width elements
md640–1024pxTwo-column layouts, condensed nav
lg1024–1440pxMulti-column layouts, sidebar patterns
xl> 1440pxWide-screen refinements, max-width containment

Fluid layouts

Prefer fluid units over fixed pixel widths:

  • %, vw, fr for widths
  • rem and em for 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 srcset and sizes
  • Prefer system fonts or variable fonts to reduce font loading overhead
  • Use prefers-reduced-motion media query to disable animations for users who have opted out
  • Respect prefers-color-scheme for 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

FailureDescription
Desktop-first CSSBase styles assume large viewports; mobile requires heavy overrides
Fixed pixel widthsElements overflow or clip on small screens
Untested breakpointsDesign only reviewed at one size; layout breaks elsewhere
Hover-only interactionsFeatures inaccessible on touch devices
Ignoring user preferencesAnimations play regardless of prefers-reduced-motion; dark mode ignored

Part of the PushBackLog Best Practices Library