Q22 proof · Responsive UIs across mobile, tablet, laptop and desktop

22. Responsive UIs across viewport sizes

Answer as submitted

“Yes — mobile, tablet, laptop and desktop, validated for behaviour, a11y and speed.”

Technical decision: expand. The submitted line states the viewports but not what changes at each one or how it is proven. This page is the separate, detailed version: it shows the concrete requirements per class and the matrix that verifies them in CI.

Expanded answer

Yes — responsive delivery is a baseline in all my UI work, and I treat it as behaviour rather than only styling. In practice: mobile (320–480 px) single column, tap targets of at least 44 px, bottom-sheet navigation, tables transformed into cards and virtualised lists; tablet (601–1024 px) two columns with navigation that becomes persistent; laptop (1025–1599 px) the full shell with side navigation, real data-table columns and density mode; desktop/wide (1600 px+) a capped measure instead of stretched content, with container queries so components adapt to their slot rather than to the viewport. Everything is verified with a viewport matrix in CI plus accessibility and performance budgets, and touch, hover, orientation and reduced-motion preferences are all handled.

Viewport class	What changes	Why it is done this way
Mobile 320–480 px	1 column, 44 px targets, cards instead of tables	Thumb reach and no horizontal scroll at the smallest supported width.
Tablet 601–1024 px	2 columns, persistent navigation	Uses the extra space without becoming a different application.
Laptop 1025–1599 px	full shell, real table columns, density mode	Information density once the screen can afford it.
Desktop 1600 px+	measure capped, container queries	Long lines hurt reading; components adapt to their slot, not the window.
Input & preference	touch, pointer, orientation, reduced motion	The same UI behaves correctly for every way it is used.
Verification	viewport matrix in CI, axe, Lighthouse budgets	Layout regressions are caught by the pipeline, not by a user report.

Live responsive workflow proof

The running component below changes its viewport/result view through real event binding. Select a viewport class to see the requirement, the reasoning behind it, and the measurement taken at that size.

RESPONSIVE WORKFLOWRUNNING

Choose a viewport class

Select a class to inspect the requirement, the reasoning and the measured result.

$ @media (max-width: 600px) { 1 column · 44 px tap targets · base 16 px }

Phone first: one column, tap targets of at least 44×44 px, no hover-only affordance, and no horizontal scroll even at 320 px.

375×812  ·  scrollWidth 375 (no overflow)
tap target 44 px  ·  base font 16 px

How responsive work is kept honest

Rules I apply. Design mobile-first and let the layout grow; use a named breakpoint scale instead of magic numbers; cap the measure on wide screens rather than stretching text; make components adapt to their container with container queries; never force a horizontal scroll on a table; keep 44 px touch targets everywhere; and verify the whole matrix in CI with accessibility and performance budgets rather than checking one device by hand.

Boundary for Q22: this page covers responsive layout and behaviour. Design-system governance, brand-level visual redesign and device-lab hardware matrices are separate topics.

Source files

Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the other two are the production shapes of the same decisions.

Acceptance criteria

Names each viewport class and what changes at it.
Keeps touch targets at 44 px and avoids horizontal scroll on small screens.
Shows an interactive proof of choosing a viewport class and reading its measurement.
Caps the measure on wide screens and adapts components by container, not viewport.
Defers design-system governance, brand redesign and device-lab matrices to a later topic.