Auditing a Product's Typography Against a Scale
You inherit a mid-size web app's codebase and audit the CSS for font sizes actually in use. You find: 11px, 12px, 13px, 14px, 15px, 16px, 17px, 18px, 20px, 22px, 24px, 28px, 32px, and 36px — fourteen distinct values, none of them documented anywhere, applied inconsistently (two different components both labeled "card title" use 17px and 18px respectively). Body paragraphs are set at 14px with no explicit line-height (rendering at the browser default of roughly 1.2x), and those paragraphs stretch the full width of the content column, which is unconstrained and often exceeds 120 characters per line on a wide monitor.
- Propose a replacement type scale (a specific set of sizes, with the ratio or logic you used to generate them) and explain why a team should adopt a fixed scale instead of the current fourteen-value sprawl.
- What's wrong with the current body-text setup, specifically — name both problems and the mechanism behind each.
- What would you change about the line-height and the layout to fix it, with concrete values?
- How would you get engineering to actually adopt the new scale rather than the fix living only in a design file?
1. A replacement scale, and why fourteen values is the real problem
Propose an 8-step, 1.25-ratio ("major third") scale from a 16px
base: 12 / 14 / 16 / 20 / 25 / 31 / 39 / 49px, rounded to clean
values in practice (12 / 14 / 16 / 20 / 24 / 32 / 40 / 48). The
current fourteen-value sprawl is the actual bug being fixed here:
with no fixed scale, every designer or developer who touched the
codebase picked a size ad hoc, and near-duplicate values (17px vs.
18px for the same "card title" role in two components) accumulated
with no shared meaning — a reader or a future engineer can't tell if
a size difference is intentional or an accident. Collapsing to eight
deliberate steps means every size on screen becomes a legible
choice, and — critically for handoff — a small named set tokenizes
cleanly (text-xs through text-4xl), where fourteen undocumented
pixel values cannot.
2. What's wrong with the body text — two distinct problems
- Line-height too tight: 14px text at the ~1.2x browser default renders at roughly 17px of line-height, well under the 1.4-1.6x range body text needs. At that tightness, the vertical gap between lines is too small for the eye's saccade back to the start of the next line to land reliably, so lines feel crowded and readers are more likely to lose their place or re-read a line.
- Line-length too long: unconstrained width producing 120+ characters per line is far past the ~50-75 character readable range. The eye's return-sweep from the end of a 120-character line back to the start of the next has to travel much farther, compounding the same saccade problem the tight line-height is already causing — these two issues aren't independent, they stack.
3. Concrete fixes
Set body text to 16px (matching the new scale's base) with a
line-height of 1.5x (24px) — squarely in the 1.4-1.6x range. Add a
max-width to the content column equivalent to roughly 65-75
characters at that size (commonly implemented as a ch-unit
max-width like 65ch, or a fixed pixel max-width tuned to the same
target) so lines never exceed the readable range regardless of
viewport size.
4. Getting engineering to actually adopt it
A scale that lives only in a Figma file gets ignored the first time
a developer needs a size not in the file and reaches for an
arbitrary pixel value instead — the sprawl reappears immediately.
Ship the scale as CSS custom properties or design tokens
(--text-xs through --text-4xl, plus --leading-body: 1.5) in
the actual codebase, replace every hardcoded font-size in existing
components with a reference to a token in the same PR that
introduces them, and add a lint rule or code-review check that flags
raw pixel font-size values going forward — the constraint has to be
enforced by tooling, not by hoping developers remember to check the
design file. This is the same handoff mechanism covered in
design-systems-components-and-dev-handoff.
Share this question