Open any well-designed magazine — Monocle, Bloomberg Businessweek, The New Yorker — and you'll see something that most product interfaces completely lack: a considered typographic hierarchy. Not just "big text for headers and small text for body," but a system where every piece of text has a clear role, a consistent rhythm, and a relationship to the text around it. This isn't aesthetic indulgence. It's information architecture expressed through type.
Product interfaces handle more text than most designers realize. A typical SaaS dashboard has headings, subheadings, body copy, labels, captions, data cells, tooltips, error messages, and status badges — ten or more distinct text roles. Most design systems define these as "h1 through h6 plus body and caption" and call it done. That's not a type system. It's a list of font sizes.
§ 01What magazines do better
Magazine designers have solved the multi-hierarchy problem for over a century. The tools they use — contrast, scale, weight, spacing, and typeface mixing — translate directly to product UI. Here's what they do that product designers often skip:
They use contrast aggressively. A magazine headline might be 72pt bold condensed. The deck (subtitle) might be 18pt light. The body is 10pt regular. The ratio between these isn't arbitrary — it's calibrated so the reader's eye knows exactly where to go first, second, and third. Most product UIs use ratios that are too timid. The heading is 24px and the body is 16px — a 1.5x ratio that doesn't create enough visual separation to guide the eye effectively.
They mix typefaces with purpose. A serif for body text. A sans-serif for captions and labels. A slab serif for pull quotes. Each typeface signals a different kind of content. Product designers tend to use one typeface for everything, relying solely on size and weight for differentiation. That works up to a point. Beyond five text roles, it starts to blur.
They treat whitespace as a typographic element. The space between a heading and the first paragraph, the space between paragraphs, the margins around a pull quote — these are not empty gaps. They're active design decisions that control reading rhythm. In product UI, spacing is often handled by a fixed 8px grid applied uniformly, which is consistent but rhythmically flat.
The ratio between heading and body text should be aggressive enough that the reader's eye knows where to go without thinking.
§ 02Building a type hierarchy that works
We use a modular scale for type sizing, but we don't follow it slavishly. The scale gives us a starting point; the final sizes are adjusted by eye. Here's the scale we start with on most projects:
/* Type scale — 1.25 ratio, base 16px */ --text-xs: 11px; /* labels, captions */ --text-sm: 13px; /* secondary body, metadata */ --text-base: 16px; /* body text */ --text-lg: 20px; /* lead paragraphs, large body */ --text-xl: 25px; /* section headings (h3) */ --text-2xl: 31px; /* page headings (h2) */ --text-3xl: 39px; /* hero headings (h1) */ --text-4xl: 49px; /* display text */
The critical decision isn't the scale — it's assigning roles. Every text element in the product should map to exactly one step in the scale, and each step should have a clear semantic purpose. If two different UI elements use the same size but mean different things, one of them is wrong. Either they should be the same, or they should be different sizes.
We also define letter-spacing per step. Larger text gets tighter tracking (negative letter-spacing). Smaller text, especially ALL-CAPS text, gets wider tracking. This isn't decorative — it directly affects readability. A 48px heading with default letter-spacing looks loose and amateurish. The same heading with letter-spacing: -0.02em looks deliberate.
§ 03Serif vs sans in UI — the real tradeoffs
The conventional wisdom is "sans-serif for UI, serif for editorial." This was sound advice in 2010 when screens were 72 DPI and serif details got lost in the pixels. It's less sound in 2026 when most screens are 2x or 3x retina and render serif details crisply.
We use serifs in product UI regularly, and here's when they work:
- Long-form reading. If the interface includes articles, documentation, or any content where users read more than a paragraph, a well-chosen serif (Source Serif, Literata, Charter) improves readability over long stretches. The serifs guide the eye along the baseline, reducing fatigue.
- Brand differentiation. In a sea of Inter, SF Pro, and Geist, a serif immediately signals that the product has been designed with intention. Linear uses serif headings. Stripe uses serif in documentation. It reads as confident and editorial.
- Mixed hierarchies. Using a serif for body text and a geometric sans for UI elements (buttons, labels, nav) creates a natural hierarchy: the serif content sits in the "reading" layer, and the sans UI sits in the "action" layer. Users intuit this distinction without being told.
When serifs don't work: data-dense interfaces (tables, dashboards, admin panels) where text is short and the serif details add visual noise without aiding readability. In these contexts, a clean sans at small sizes is objectively clearer.
Serif for reading. Sans for acting. Users intuit the difference.
— Design system typography guidelines
§ 04Variable fonts and why they matter now
Variable fonts have been technically available since 2016. In 2026, they're finally practical. Browser support is universal. Google Fonts serves variable versions of most popular families. The file size savings are significant: a single variable font file replaces four to eight static weight files.
But the real value of variable fonts isn't file size. It's design precision. With a static font, you choose from a fixed set of weights — 400, 500, 600, 700. With a variable font, you can set the weight to any value: 450 for a subtle semi-bold, 580 for a weight between medium and semi-bold. This sounds like a trivial difference, but it compounds across a type system. The optimal weight for a 13px label is not the same as the optimal weight for a 48px heading, even if both are "bold." Variable fonts let you tune each one independently.
We also use the width axis when available. A condensed heading at display sizes saves space and looks more editorial. The same text at body sizes uses the normal width for readability. One font file, adjusted by CSS, replacing what used to require two separate typeface licenses.
The practical setup is straightforward: load the variable font with @font-face, set font-weight to a range in the declaration, and use specific numeric values in your CSS. Google Fonts handles the @font-face declaration automatically when you request a variable font.
§ 05Line-height rules we actually follow
Line-height is the most impactful and most misunderstood property in typography. Too tight and the text feels cramped; too loose and the lines disconnect from each other. We use three rules:
Rule 1: Line-height decreases as font size increases. Body text at 16px needs a line-height of about 1.5-1.65. A heading at 48px needs about 1.0-1.1. A display headline at 96px needs 0.9-0.95. The relationship is inverse because larger text has more internal whitespace (the counters of letters like "o" and "e" are bigger), so it needs less external whitespace between lines.
Rule 2: Measure (line length) affects optimal line-height. Longer lines need more line-height because the reader's eye has to travel further to find the start of the next line. A 16px body text in a narrow column (40ch) can use 1.5 line-height. The same text in a wide column (75ch) needs 1.65 or more. We set max-width on text containers to keep measures reasonable: 65-75ch for body, 20-30ch for headings.
Rule 3: Use unitless values, not pixels or ems. line-height: 1.5 is not the same as line-height: 24px when the element contains mixed font sizes (like an inline code span). Unitless values scale proportionally with the font size of each element. Pixel values are fixed and create awkward spacing when font sizes vary.
§ 06The typography checklist
Before we ship any project, we run through this list:
# Typography review checklist 01. Every text element maps to one scale step 02. Heading/body ratio is at least 1.5x (preferably 2x+) 03. Letter-spacing tightens as size increases 04. ALL-CAPS text has positive letter-spacing (0.05-0.12em) 05. Line-height decreases as font size increases 06. Body text measure is 55-75 characters 07. Font loading doesn't cause layout shift (preload or optional) 08. Fallback fonts are size-adjusted (size-adjust in @font-face) 09. Text remains readable in dark mode (weight may need adjusting) 10. Paragraph spacing is consistent and uses margin, not line breaks
Ten items. Five minutes to check. The difference between a product that looks polished and one that looks like a developer set the type is usually three or four of these items being wrong. Typography is invisible when it's done well and painfully obvious when it's not. Treat it like infrastructure: set it up correctly once, and everything built on top of it will look better by default.
— End of essay. Want a product that reads as well as it works? Start a project →