Foundations: type scale, line-height, and rhythm

Typography foundations are less about finding the perfect scale and more about making repeated decisions easier. A product team needs type that can survive dashboards, settings screens, marketing fragments, empty states, tables, mobile forms, and the occasional long article without becoming a pile of one-off sizes.

I start with use cases, not ratios. What does the product actually need to say? A commerce admin needs dense tables, form labels, revenue numbers, and help text. A publishing tool needs long-form reading, headings, captions, and editor chrome. A portfolio needs case-study prose and project metadata. Those needs should shape the scale.

Choose a scale by job

A type scale is a small set of named sizes. The names matter because they turn visual choices into product language. I would rather see a modest scale with clear jobs than a mathematically elegant scale nobody remembers.

A useful starting set for an interface might be:

• display: rare, high-emphasis page moments.
• title: page and major section headings.
• heading: panel and card headings.
• body: default reading and form text.
• small: secondary text, metadata, helper copy.
• label: controls, tabs, and compact UI.
• mono: code, IDs, and tabular data.

The exact values depend on the typeface, but the relationships should be obvious. If title and heading are too close, designers will use them interchangeably. If body and small are too far apart, secondary text becomes hard to read. If display is available everywhere, it will eventually appear inside a card where it does not belong.

I do not mind modular scales, but I do not worship them. A ratio can provide a useful starting curve. It cannot tell you whether a table cell, a mobile checkout label, and a case-study heading all feel right in the same product.

Line-height is a reading decision

Line-height controls how easily the eye moves from one line to the next. It also controls density, component height, and how much air a screen appears to have.

My default rules are simple:

• Body copy needs enough line-height for reading, often around 1.45 to 1.65 depending on the face and measure.
• Large headings usually need tighter line-height because their letters already create visual space.
• Small labels often need a little more line-height than expected so they do not feel cramped.
• Single-line controls should use stable component heights instead of relying on line-height alone.

Line-height should be part of the token, not an afterthought. A 16px body size with a 24px line-height is a different typographic object than 16px with 20px. If a team stores only font sizes, every component has to rediscover rhythm locally.

I like paired tokens: font size, line-height, weight, and sometimes letter spacing when the typeface needs it. Most products need fewer pairings than they think.

Measure is the hidden variable

Measure is the length of a line of text. It is why the same body style can feel elegant in one layout and exhausting in another. Long lines slow reading because the eye has to travel too far. Very short lines create choppy rhythm.

For long-form prose, I usually constrain line length aggressively. For product UI, the answer is more contextual. A settings description can be narrow. A table cell may need to truncate. A help panel may need a comfortable reading width even inside a dense app.

Do not solve measure with font size alone. If a paragraph feels hard to read because the container is too wide, making the text bigger may damage the rest of the hierarchy. Constrain the text block. Use grid columns. Let prose have a different max width than operational UI.

Density is a product choice

Dense typography is not automatically bad. Sparse typography is not automatically premium. Density should match the task.

A pricing comparison page can afford generous rhythm because the user is evaluating. An inventory table needs compact rows because the user is scanning many records. A checkout form needs enough spacing for touch and error recovery. A settings page needs calm grouping more than dramatic scale.

The foundation should support at least two density modes in spirit, even if they are not formal modes in code: reading surfaces and working surfaces. Reading surfaces need measure and vertical rhythm. Working surfaces need predictable rows, compact labels, and strong alignment.

Problems appear when a team uses one typographic mood everywhere. Marketing-scale headings inside admin cards feel loud. Tiny operational labels in editorial pages feel under-designed. The product needs a range, but the range should be named and limited.

Responsive type without viewport scaling

I avoid tying type directly to viewport width. Viewport-based scaling can produce awkward in-between sizes, unpredictable wrapping, and text that changes because the window moved rather than because the layout needed a new hierarchy.

Instead, I prefer discrete responsive decisions. At small breakpoints, reduce the number of heading levels in use, tighten display sizes, and simplify layouts so text has room. At larger breakpoints, increase container width only when measure remains readable. Use component or page context to choose the type token.

For example, a page title might use title on mobile and display on desktop. Body stays body. Labels stay labels. The system changes hierarchy at known layout moments instead of continuously stretching every word.

This is also easier to review. A designer and engineer can look at a breakpoint and decide whether the hierarchy still works. Continuous viewport math is harder to reason about.

Rhythm is alignment plus repetition

People sometimes talk about vertical rhythm as if every line must sit on a perfect baseline grid. That can be useful in editorial design. In product interfaces, I care more about repeated spacing relationships.

Headings should have a consistent relationship to the content they introduce. Form labels should sit predictably above fields. Card titles should align across a grid. Help text should not float randomly between controls. Error text should add space without pushing the page into chaos.

The type system and spacing system have to cooperate. If body line-height is 24px, spacing tokens around prose should respect that rhythm. If compact labels use 16px line-height, component padding should make them feel centered without custom nudges.

The test is whether new screens can be composed without inventing local margins. If every heading needs a custom bottom value, the foundation is not finished.

Exercises

The fastest way to improve a type foundation is to test it against real surfaces.

Exercise one: build a settings page with one page title, two sections, three form fields, helper text, an error, and a destructive action. If the scale cannot express that hierarchy calmly, adjust it.

Exercise two: typeset a 900-word article with headings, lists, captions, and inline code. If reading feels tiring, inspect measure and line-height before changing the typeface.

Exercise three: build a dense table with toolbar filters, column labels, values, status chips, and pagination. If the product feels cramped or noisy, check whether small and label styles are doing too many jobs.

Exercise four: put the same component on mobile and desktop. Do not use viewport scaling. Choose explicit type tokens at explicit layout changes and see whether the hierarchy still makes sense.

The goal is not a perfect scale. The goal is a type system that makes ordinary product work feel composed, readable, and repeatable.