In a design system, why give breakpoints names such as compact, medium and expanded rather than pixel values or device labels?
answer
- one vocabulary for design and code
- ranges of window width, not hardware
- change a threshold once, specs follow
- split-screen, resizing and zoom change class
- names outlast this year's screen sizes
basics
~20 sNamed window-width classes give designers, web and native engineers one vocabulary for ranges of available space. They describe the window rather than the hardware, so split-screen, resizing and zoom land in the right layout, and thresholds can change without rewriting specs.
solid answer
~40 sNamed breakpoints, or **window-width classes** such as `compact`, `medium` and `expanded`, turn a few thresholds into a shared vocabulary: designers, web engineers and native engineers all specify "what changes in medium" instead of trading pixel numbers, and the system can tune a threshold once while every spec that uses the name follows. The classes describe the **available window width**, not the hardware, because the device does not decide how much room the app has. A tablet running two apps side by side, a phone turned sideways, an unfolded foldable, a narrow desktop window and a desktop zoomed to 400% (which WCAG 2.2's Reflow criterion expects to work at a 320-pixel-equivalent width) each land in the class their width deserves. Device labels also age as new screen sizes ship; width ranges do not.
go deeper
Recall that breakpoints are named ranges of window width, and use the names in specs and code instead of pixel numbers or device words.
Explain why a name decouples specs from threshold values, and why window width rather than device decides the class, using split-screen and zoom as examples.
Show how you would catch teams drifting into private breakpoints, and how you would test layouts across whole ranges, including zoomed desktop windows.
Weigh aligning the system's classes with each native platform's own window groupings against one system-wide set, and what either choice costs cross-platform teams.
## What a named breakpoint is A **breakpoint** is a width at which a layout changes structure: a navigation bar moves, a single column becomes two panes, a list gains a detail view. A **named breakpoint**, often called a **window-width class**, gives each *range* between two breakpoints a name, such as `compact`, `medium` and `expanded`, and the design system publishes that small set as the widths at which page layouts are allowed to change. In a telecom self-service app, the account area might be specified once per class: in `compact`, usage, bills and add-ons stack in one column under a bottom navigation bar; in `medium`, a side rail replaces the bar and the usage meter sits beside the balance; in `expanded`, the bill list and the selected bill's detail share the screen as two panes. ## Why names instead of pixel values - **One vocabulary for three audiences.** A designer's frame in a design editor, a web engineer's stylesheet and a native engineer's layout code can all say "medium" and mean the same range, even though each platform measures width in its own unit. - **One place to change a threshold.** When testing shows the two-pane bill layout needs more room, the system moves the `expanded` threshold once, usually as a token, and every spec that says "expanded" follows. Specs that hard-coded a number each have to be found and edited. - **Fewer accidental breakpoints.** When teams write raw numbers, each picks slightly different ones, and the product ends up with a dozen near-identical widths where layouts flip. A short list of names makes an off-list width visible in review. - **Specs describe intent.** "In compact, the add-ons list opens as a sheet" says what the layout is for; "below 599 pixels" says only where it happens. ## Why window width instead of device Device labels (phone, tablet, desktop) look friendlier, but the device does not decide how much room the app has. The **window** does. | Situation | Device label says | Window-width class says | |---|---|---| | Tablet running two apps side by side | tablet | compact or medium, depending on the split | | Large phone turned sideways | phone | often medium | | Foldable phone, unfolded | phone | medium or expanded | | Desktop window dragged narrow | desktop | compact | | Desktop window zoomed to 400% | desktop | compact | The last row is also an accessibility requirement. **WCAG 2.2 success criterion 1.4.10 Reflow (Level AA)** requires content to be usable without scrolling in two dimensions at a width equivalent to 320 pixels, and the criterion notes that this is what a 1280-pixel-wide window becomes at 400% zoom. A desktop user who zooms in therefore gets the compact layout, and it must carry the same information and functions, not a cut-down subset. A system that keyed its layouts to "desktop devices" would hand that user a layout that no longer fits. Device-named breakpoints also age badly: each year brings new screen sizes, and a list keyed to today's hardware needs revisiting, while a range of available width stays meaningful. ## How teams use the names day to day 1. The designer frames each screen at a representative width inside each class the product supports, and notes what changes when the class changes. 2. The engineer implements the layout switch against the system's named thresholds, never a local number. 3. Reviewers and visual tests exercise each class, including widths near the edges of a range, not only one "phone" and one "desktop" size. 4. When a layout genuinely fails between two classes, the problem is raised with the system team rather than patched with a private breakpoint. ## Pitfalls - **A class as a device in disguise.** Calling `compact` "mobile" in specs quietly reintroduces the device assumption, and the team stops testing narrow desktop windows. - **Designing only at the thresholds.** A class is a range; the layout has to hold at every width inside it, which is why most systems combine named classes with fluid behaviour between them. - **Treating values as frozen.** Names are meant to be stable; their values are not. Keeping the names while tuning the values is exactly what naming buys. - **Two dialects across platforms.** If web says "tablet" and native says something else, the shared vocabulary is lost. Native platforms already group windows into width classes of their own, so aligning the system's names with those groupings, or publishing an explicit mapping, keeps one language.
- Should a design system's breakpoint names be identical on web and native?Ideally the same names and roughly the same ranges, so one spec reads the same on every platform. Native platforms already group windows into width classes of their own, so many systems align with those groupings or publish an explicit mapping. What matters is that a designer's 'medium' means one range to every team, even though each platform measures width in its own unit.
- What happens to a named-breakpoint layout when a desktop user zooms to 400%?Zoom shrinks the effective window width: a 1280-pixel window behaves like a 320-pixel-equivalent one, so the compact layout takes over. WCAG 2.2's Reflow criterion, Level AA, expects content at that width to work without two-dimensional scrolling and without losing information or functionality, so the compact layout must be complete, not a trimmed phone version.
saying these in an interview costs you the question
- Breakpoints should be named after devices such as phone, tablet and desktop.
- A phone always gets the compact layout, whatever its window is doing.
- Once breakpoints are named, their threshold values can never be adjusted.
- Named breakpoints mean each screen only needs designing at the exact threshold widths.
- Breakpoint names are an engineering detail; designers can keep specifying raw pixel widths.