Typography in Design Systems
![Typography in Design Systems](/presta/v6_chrono_91/modules/tvcmsblog/views/img/large-blog-1.jpg)
Everyday digital interfaces include a rich variety of images, visualizations, and other pictures. However, more than anything else, they are made of words. Oh so many words. As we equip teams to design and code usable, consistent, beautiful interfaces using systems, it’s essential that words depend on a strong foundation of typography. I’ll admit, I am not a typography expert. I lack a graphic design degree. I’m never the person choosing a font, scaling type, or finessing letter spacing. As a result, I’ve always been reluctant to write about typography.
Typography starts by setting a foundation of font families and weights along with fallbacks. It then explores how to build hierarchy using size, color, additional details like line-height, and layering responsiveness. Those models are then applied to components in a system’s library (like Article and Header) as well as custom components made by other teams.
Fonts
Before you dig into details, you have to settle on basics: font(s). Through exploration, comparison, research, and often — for large companies — making a font themselves, every display cascades from and depends on this choice.
Families, Weights, and Fallbacks
While systems can vary fonts based on theming, most ground themselves initially by identifying primary serif and/or sans-serif font family. Each font is augmented with a cascade of fallbacks (Hello, Arial and Times), and many systems throw in a monospace font for code displays (even if only their own).
Some systems can get away with as few as two or three weights of their primary typeface, seeking to balance variety and flexibility with governance and download weight.
Takeaway: Getting to a primary font isn’t always hard, but choosing what weights to include carries long term consequences. Adding fonts and weights is easy. Managing download size and changing them is hard.
Getting the Fonts, Whether by Download, Link, or CDN
Whether or not a design system program owns the fonts, users of a design system expect a system to provide the instructions necessary to use the fonts.
From a designer’s perspective, it’s all about downloads. Some fonts are tightly held intellectual property with very intentionally limited sharing. So, at a minimum, a Typography page must provide direct download or instructions on how to get approval to obtain them. Most teams provide a downloadable ZIP that includes all the files you need to install and use fonts locally.
For developers, it depends on approach, providing options like:
- Direct font download to serve the fonts themselves
- Instructions for linking to a service like Google Fonts
- CDN references that all products refer to collectively
- An invitation to contact a technical architect, since a license for the font is required. Organizations requires this to control the recurring and often non-trivial cost of hosting and serving the font.
Takeaway: Fonts are needed by different people in different ways. System users expect the system to explain how to use everything easily, even if it’s not the system team’s job to make custom fonts or serve fonts themselves.
Typography Scale & Hierarchy
Most design systems demonstrate a typography scale in documentation as a vertical stack. That’s not enough. A typographic system should also establish constructs like body text, headings, color, responsiveness, color, and other fine-grained details.
Body Text
Systems leverage a type scale to offer core text sizes — often named simply as text or body — that include small, medium, large, and if you need it, xs, xl, and so on. Most systems need three or so (thus, my comfort with using t-shirt sizes). Start with a few and expand as necessary as component designs – and page compositions in the wild.
Body copy may also offer a distinct “Lead” (alternatively, “Lede”) paragraph to open a page, such as in an article (more on that later). Thus, a simple S/M/L scale may also need other variants lead. This is especially relevant in systems offering multiple sizes, since a Lead for larger, lower density displays would be larger than a Lead for smaller, high density alternatives.
Text Color
Color also plays a key role in an interface’s typographic hierarchy, often by established types like:
- Primary, for most interface text whether body or heading.
- Secondary, for diminished contrast (often, the “gray text”) for supplemental information.
- Interactive, not just for links but also flat buttons, tab labels, and more
- Disabled, often resulting is especially lower contrast treatments
- Error, usually red, for the highest contrast with its surroundings
When it comes to naming text colors based on intent, I find the Hudl Uniform names the most intriguing: default, contrast, subtle, and nonessential. Such names balance the tradeoffs of stronger control with greater abstraction (and thus, less self-evident reuse).
These types are typical, encountered during early component designs like button, input and link. As a library grows, they become littered throughout the component catalog via tools like tokens and mixin. Notably, they become necessary as component designs span in light and dark settings.
For example, in the Yoursite.com library (far less rigorously maintained, cobbler’s children and all), we employ a text coloring mixin that iterates through background colors, by type.
weqrgerqwg