skip to content

In a design system, when should type sizes step at breakpoints rather than scale fluidly between them, and what does each approach cost?

level: middleimportance: should knowfreq 40%

answer

  1. jumps versus smooth interpolation
  2. static frames in the design editor
  3. every fluid size needs bounds
  4. display type moves, body stays put
  5. zoom must still enlarge it

basics

~20 s

Stepped type swaps fixed sizes at breakpoints: predictable and easy to specify, but it jumps. Fluid type interpolates between a minimum and a maximum across widths: smooth, fewer overrides, harder to specify and test. Many systems make only display sizes fluid.

solid answer

~50 s

**Stepped** type gives each text style a fixed size per breakpoint range, so a headline might be one size on phones and a larger one from tablet width up. It is predictable, maps cleanly onto static design frames and tokens, and matches how native apps usually adapt, but sizes jump at each breakpoint and every style-and-breakpoint pair is a value to maintain. **Fluid** type interpolates a size between a minimum and a maximum across a width range, so it changes smoothly and needs fewer overrides, but the in-between sizes are computed, hard to show in a design editor and hard to test exhaustively. A common hybrid makes large display and headline sizes fluid, where the phone-to-desktop range is widest, while body text stays at the size the reader's text setting produces. Either way, sizes must still grow when the reader zooms or raises their text-size setting.

go deeper

for a junior

Recall the two models: stepped sizes change only at breakpoints, fluid sizes interpolate between a minimum and a maximum, and many systems make only headlines fluid.

for a middle

Explain the costs on each side: jumps and many values for stepped, computed sizes and harder hand-off and testing for fluid, and why every fluid size needs bounds.

for a senior

Show how you would choose per text style, keep hierarchy intact at the narrowest width, and make sure fluid sizes still respond to zoom and the reader's text setting.

for a principal

Weigh web and native parity, design hand-off and test cost when setting a system-wide policy on fluid type, and decide who may add a fluid style and on what evidence.

## Two ways to adapt type to the screen A design system has to decide how text sizes respond to the width of the screen or window. There are two basic models, and most mature systems mix them: - **Stepped** (also called static or breakpoint-based): each text style has a fixed size inside a range of widths, and the size changes only when the layout crosses a breakpoint. - **Fluid**: each text style has a minimum size at a small width and a maximum size at a large width, and between the two the size is interpolated continuously. The decision is a design-system decision rather than an implementation detail, because it changes what designers specify, what tokens hold and what has to be tested. ## Comparing the two | Concern | Stepped | Fluid | |---|---|---| | Predictability | Exact size known at every width | Size is computed; exact value varies | | Design hand-off | Maps onto a few static frames | Frames show only sample points on a curve | | Values to maintain | One per style per breakpoint | A minimum, a maximum and a range per style | | Transitions | Visible jumps at breakpoints | Smooth; no jumps | | Awkward widths | Just below a breakpoint can look cramped | Handled by interpolation | | Testing | A handful of widths covers it | Needs sampling across the range | | Native apps | Matches how native layouts usually adapt | Rarely how native text is sized | Neither is wrong. Stepped type suits systems whose designers and native teams think in fixed frames and want exact values in the specification. Fluid type suits marketing and editorial surfaces where the same page is seen from small phones to very wide monitors and the jumps would be noticeable. ## The common hybrid Many systems land on a split that keeps the benefits of both: 1. **Body and interface text are not width-driven.** They stay at the size the reader's text-size setting produces, perhaps with a single step on the smallest screens. Body text is what people read for long stretches, and making it shrink on a narrow window makes reading harder exactly where the screen is already small. 2. **Headlines and display text scale** fluidly, or in more steps than body text, because their size range between phone and desktop is the widest. A campaign headline that is comfortable on a desktop can be three lines too long on a phone. 3. **Every fluid size is bounded** by a minimum and a maximum, so it never gets unreadably small on a narrow phone or absurdly large on an ultra-wide monitor. 4. **The hierarchy survives the squeeze**: at the smallest width, the largest heading must still be clearly bigger than body text, so the minimum of each fluid size is chosen with its neighbours in mind. ## Where fluid type can hurt accessibility - **Size tied only to the window width.** Page zoom works by making the layout think the window is narrower. A size computed purely from width can then stay visually the same while the reader zooms, which works against WCAG 2.2 SC 1.4.4 Resize Text (text resizable to 200 percent). Fluid formulas therefore include a part that follows the reader's base text size; the exact formula belongs to the platform layer. - **A maximum that blocks enlargement.** A bound that stops a headline growing on wide screens is fine; a bound that also stops it growing when the reader raises their text size is not. - **Untested in-between widths.** Clipping and overlap can appear at a width nobody checked, so a fluid system samples the whole range in its visual tests. ## A charity donation site as an example A charity's campaign page has a large appeal headline, a short standfirst, body copy telling the story, and a donation panel. A sensible system choice: - The appeal headline is fluid, bounded between a phone size and a desktop size, so it fills the hero on every screen without a jump at the tablet breakpoint. - The standfirst takes one step at the tablet breakpoint. - Body copy and the donation panel's labels are not width-driven at all; they follow the reader's text-size setting. - The native app, which lays out by window size, uses the same stepped values the website uses at matching widths, so the two platforms agree. The decision record should state which styles are fluid, their bounds, and why, so the next designer does not make every style fluid by default.

  • Why do many systems keep body text out of fluid scaling?
    Body text is read for long stretches, and its comfortable size depends on the reader and their text setting, not on the window width. Shrinking it on narrow windows makes reading harder where the screen is already small, and it gains little on wide screens, where the reading column is capped anyway. Headlines have the widest phone-to-desktop range, so they benefit most from fluid scaling.
  • How do you hand off fluid type when the design editor only shows fixed frames?
    Specify each fluid style as a minimum size at a named small width and a maximum size at a named large width, and show both frames plus one in between. The tokens carry the bounds, not a single size. Reviewers then check the extremes and a sample in the middle instead of expecting a pixel-exact match at every width.

saying these in an interview costs you the question

  • Fluid type is always better because it removes every breakpoint override.
  • Body text should shrink on narrow windows so more of the story fits.
  • A fluid size tied only to window width still grows when readers zoom.
  • Stepped type cannot follow the reader's text-size setting at all.
  • Fluid sizes need no minimum or maximum, since interpolation keeps them sensible.