07
Consistency
One off type choices feel fine in isolation. Across a page, inconsistency reads as carelessness, before the user reads a single word.
5 min read
Every typography decision you've made in this series (measure, contrast, scale, leading, weight, spacing) only works if it repeats. A type system is not a set of good values. It's the same good values, applied the same way, every time.
Compare
Dashboard
Welcome back. Here's what changed since yesterday.
Recent activity
3 new notifications
Dashboard
Welcome back. Here's what changed since yesterday.
Recent activity
3 new notifications
Same content. Same layout. The left version was built component by component. Each developer picked sizes that looked right in isolation. The right version uses a scale. You trust it before you read it.
Type System
Product overview
Every size was picked by hand. Nothing matches.
Key features
Two headings. Two sizes. Two weights.
Slide through four stages, from ad hoc sizes to a full token system. The inconsistent version isn't ugly. That's what makes it dangerous. Each choice is defensible alone. Together they signal that no one owns the typography.
Consistency compounds. A user who sees the same heading size in three sections stops parsing size and starts parsing content. A user who sees three different "heading" sizes stays in low level visual processing, comparing, doubting, tiring, which raises cognitive load.
The left panel above shows it: Dashboard at one size and weight, Recent activity at another, caption at a third. Same page, three hierarchy levels, no shared scale. This ships on production apps every day.
The Rule
Define type tokens once: sizes, weights, line heights, spacing. Never hardcode values in components.
Inconsistent typography increases cognitive load because the reader cannot build a predictive model of the page. Consistent typography disappears, which is the goal. The type should carry structure silently so content carries meaning.
:root {
--text-body: 1rem;
--text-h3: 1.333rem;
--text-h2: 1.777rem;
--text-h1: 2.368rem;
--line-body: 1.6;
--weight-body: 400;
--weight-heading: 600;
}
h1 { font-size: var(--text-h1); font-weight: var(--weight-heading); }
h2 { font-size: var(--text-h2); font-weight: var(--weight-heading); }
h3 { font-size: var(--text-h3); font-weight: var(--weight-heading); }
p { font-size: var(--text-body); font-weight: var(--weight-body); line-height: var(--line-body); }:root {
--text-body: 1rem;
--text-h3: 1.333rem;
--text-h2: 1.777rem;
--text-h1: 2.368rem;
--line-body: 1.6;
--weight-body: 400;
--weight-heading: 600;
}
h1 { font-size: var(--text-h1); font-weight: var(--weight-heading); }
h2 { font-size: var(--text-h2); font-weight: var(--weight-heading); }
h3 { font-size: var(--text-h3); font-weight: var(--weight-heading); }
p { font-size: var(--text-body); font-weight: var(--weight-body); line-height: var(--line-body); }Common Mistake
Defining a type scale in Figma or a design doc but hardcoding font-size: 22px in components because "this one needed to be slightly bigger."