Design
Typography Is Most of Your Design System
Audit any digital product and count what is actually on screen. It is text. Ninety percent text, set in containers, with the occasional image and a scattering of controls. Yet when teams build design systems, typography gets a single settings page while buttons get a component with forty variants and a naming debate that outlives the quarter. The priorities are exactly backwards.
We rebuilt the type foundations for Aperture's product suite last fall, and the experience confirmed a long-held belief: typography is not a part of the design system. It nearly is the design system. Here is how we approach it.
A scale you can defend
A type scale is a set of decisions, and decisions need reasons. We use a constrained modular scale, usually six or seven sizes total for product work, each with a defined line height, weight range, and purpose. If a designer cannot say what a size is for, the size gets cut. Every additional "just this once" size is a future inconsistency with a shipping date.
The pairings matter more than the values. A size only means something relative to its neighbors: the jump from body to heading is doing hierarchy work, and if the jump is timid the whole interface goes mushy. We would rather have five sizes with confident contrast between them than twelve sizes an interpolation apart.
Tokens are the contract with engineering
Type decisions die in handoff unless they are encoded. We ship typography as semantic tokens, named for role rather than appearance: text-body, text-caption, heading-page, never font-16-semibold. Role-based names survive a redesign; value-based names are lies waiting to happen. Grace's team consumes the same token file our Figma styles are generated from, which means a type change is a pull request, not a scavenger hunt.
Two implementation rules we hold firmly:
- Line height is unitless and belongs to the token. Pixel line heights break the moment text wraps in a component someone stretched.
- The system owns vertical rhythm. Spacing between text elements is defined by the type styles, not eyeballed per screen. Most "this page feels off" feedback is rhythm, not color.
Choose fewer fonts than you want
Every brand wants a display face, a text face, a mono for numbers, maybe a friendly rounded thing for empty states. Every product needs about two, used with discipline. Web font weight is a performance budget item like anything else, and each additional family is another axis of inconsistency for a growing team. When we cut Aperture's product from four families to two, nobody outside the design team noticed, which was precisely the point. What people noticed was that the product felt calmer, and nobody could say why.
Variable fonts have made the discipline easier: one file, a controlled range of weights, no temptation to install the whole superfamily. Use the technology as a constraint, not a candy store.
The critique test
Here is a diagnostic we run in critiques. Take a screen, blur it until the text is unreadable, and look at the shapes. Can you still tell what matters most on the page? If hierarchy survives blurring, the typography is working. If everything blurs into even gray soup, no button variant is going to save the design, because the design has not decided what it wants you to read first.
Buttons are fun. Color is glamorous. But text is what your product mostly is. Spend your system-building weeks where your pixels actually are, and a surprising amount of the rest falls quietly into place.
Building something this could apply to?
We take on a small number of flagship projects each quarter.
Start a project