A typography stack (or typographic hierarchy) is quite simply a collection of typestyles. Each style specifies values for a shared set of typography-related settings like font size and weight.

With a well-constructed stack, you can rest assured that the content in experiences that consume your design system is aligned and that any patterns composed with the foundations of the system meet your various quality indicators.

There are countless ways to approach establishing a typography stack and there isn’t a one-size-fits-all solution. Instead of proposing one, I’m going to walk you through how my team created a flexible, supportive, and accessible hierarchy.

Baseline against your design system

My advice is to start by looking at the bigger picture. What is your design system trying to achieve? Maybe your goal is to align or to speed up production. Taking a moment to recap on your end goal will allow you to understand exactly what you need from the stack.

These were our goals:

• Align teams — Create a harmonious user experience by standardizing the visual language.
• Future-proof— The design system will mature as more internal teams become adopters. With more adopters, we will discover more use cases to support
• Ease adoption —A good consumer experience is critical to adoption. The design system must act as a supportive colleague, with helpful solutions and practical advice.
• Ecosystem-wide support —Our potential consumer base is a diverse mix of rich interactive experiences and content-led experiences. The design system must provide equal support across the ecosystem.
• Inclusive first design — The design system must enable consumers to engage with holistic capabilities for accessibility and internationalization.

With these goals in mind, we knew we wanted a hierarchy that could:

• Flex and change as we learned more about our consumers
• Support accessibility and internationalization
• Foster a straightforward decision process for designers and engineers

Identify a midpoint

Now it’s time to make some decisions.

Think of the hierarchy as being organized first by size, then by weight, and finally by color. To keep this simple we’ll discard weight and color until we have the initial set.

I find the best way of building a hierarchy is to start in the middle and work out from there. This helps create balance and prevents us from skewing the hierarchy too much in one direction.

Often, a good midpoint is the standard style for body copy. From the engineer's vantage point, this is nearly always the default setting that is applied to content, should they not specify a style.

With body copy in mind, you should look to answer these questions:

• What’s the font? Is this consistent across styles? Are you running two font faces in parallel?
• What size is it? For web experiences, I’d expect to see something between 14px and 18px depending on the type of content you are catering for
• What weight is it? Regular? Medium?
• What are the line height and character spacing settings? Will these settings be common across all styles?
• What color is applied to the body copy? I’d suggest picking a primary and secondary color for your typography. For accessible palettes, you will also need any potential background colors to help you establish a background-to-content ratio.

Our body copy style looked like this:

• What’s the font? Proxima Nova
• What size is it? 16px
• What weight is it? 500, Regular
• What are the line height and character spacing settings? 0rem on character spacing, 1.2 (120%) line height for short-form text, and 1.5 (150%) for long-form
• What color is applied to the body copy? Martinique #242d48, and a secondary color of Comet#575778 against two background colors, #ffffff and #f8f8f

Extrapolate a stack

Now you have the base settings you can begin to extrapolate an initial set of styles. Following the order of size, weight, and color, I suggest starting with size and ignoring weight and color. Size is typically the main indicator of hierarchy and is supported by other visual settings.

A good tip is to make sure that the visual difference between adjacent styles is distinct. This is a good check on the overall size of your hierarchy, if you have a dense cluster of sizes this may be an opportunity to consolidate styles and simplify the selection process for your consumers.

Using a midpoint of 16px, we extrapolated: 13px,14px,16px,18px,24px,32px,40px,48px

Finally, map known use cases to your proposed stack and introduce color and weight to distinguish between different types of content.

If you have a number of configuration options for a size point, simply create more styles.

e.g.
18px, bold18px, Regular

Productionizing the stack

Declaring a typographic hierarchy and shipping one to consumers are two entirely different challenges. Your approach to productionizing the stack will largely depend on:

• Goals you identified in step one
• Maturity of your design system and consumer base
• Tools and technologies leveraged by your consumers

Here’s how we approached the challenge.

You might recall our goals around adoption and consumer experience. My team wanted to establish a simple concept that helped designers and engineers alike to quickly grapple with the stack.

At the time, I was running the team alongside an incredibly talented engineer who came up with just such a concept. He named it the fruit scale and we refer to the styles as fruit-faces (like font faces, get it?).

The concept is pretty simple. The fruit scale consists of a list of fruits, from Blueberry to Jackfruit. Each fruit represents a point in the scale and is named according to the relative size of the fruit.

e.g. Banana is bigger than Peach, Cranberry is smaller than Pear.

Each style provides values for type settings and consumer guidance on when to use it.

e.g. banana

• Font family: Proxima Nova
• Size: 18pt (1.125rem)
• Weight: Semi-bold (600)
• Letter spacing: 0rem
• Line height: 1.2 (in line with WCAG legibility guidelines)
• Color: Martinique — Neutral stem (mapping to our color stack)
• Usage: Major section titles and headings, typically secondary to the overall page title

Here’s how our stack performed against our goals.

Align teams and create a straightforward consumer experience

We chose fruit as the basis for our scale given that the category is commonplace in everyday life and therefore safe to assume that everyone know’s at least basic fruits and can size them relatively.

The set is small enough to be learned and the fruits commonplace enough to be known, allowing the consumer to immediately predict the relative size of settings.

In terms of settings, color and weight are specified for each style to help drive alignment across the application of the hierarchy to content. I found that this also helped to minimize the natural variance in designer preference to certain weights and colors.

Future flexibility

As a moderately sized, known set of objects, it’s easy to add new fruits to the scale when new use cases arise. Often, you see linear scales used to describe the hierarchy, where styles are sorted and identified by their position in the scale from 1to n . By avoiding a linear scale, new settings don’t require us to reshuffle the existing set.

The typography stack is intentionally restrictive. By offering few customization options, we retain more control over how typography is applied to experiences. This makes it easier to roll out enhancements as we spot new use cases.

I first saw this as content-led platforms that adopted the design system. A line height of 1.2 (120%) worked perfectly well for the short-form text in rich interactive experiences but failed to meet our standards for legibility on long-form articles.

With control over line height, we were able to expose a boolean parameter to consumers for long-form content that adjusted the line height to 1.5 (150%).

Accessibility

To claim that a design system is ‘accessible’ is often a little misleading.

Ultimately, a design system can be built to support and encourage accessibility, but the delivery team creating the resulting experience is responsible for maximizing accessibility.

I’ve found that there are two main ways that a design system can help teams improve the accessibility of their experiences:

• Automate and systemize decisions that enforce accessibility, where appropriate
• Educate through guidance when decisions are delegated to the delivery team

We were fortunate to be able to automate many of the accessibility considerations directly in the fruit scale, shielding our consumers from the complexity. Largely, considerations centered around the perceivability (the P in POUR) of content.

• Color contrast is covered as part of our color stack and conforms with WCAG guidelines for a 4.5:1 contrast ratio against permitted backgrounds, so providing we apply color in line with this stack we’re in the clear.
• Legibility is ensured through type size, line height, and letter spacing and also confirm with WCAG guidelines. Internally we set a minimum font size of 13px and a minimum line height of 120%.

On the engineering side, we considered semantics. Semantics are essentially HTML elements that, when applied to contentm, tell the browser what the content means. You can read about semantics, here.

Given the composable nature of our design system, we wouldn’t always know the semantic intent of the content. A larger typeface could be used for non-essential display content or for the title of the page. Likewise, settings used for body copy on content-led platforms could be used as section headers on data-led platforms.

We decided the best approach would be to create a layer of abstraction between the typography setting and the semantic element:

• Establishing a thorough reset for HTML typographic elements
• Providing a class-based API that would allow any element to take on the visuals of a setting

Conclusion

I hope this article has given you some helpful next steps.

We’ve been developing our typography stack for around four years now. Our future-thinking approach has meant that in this time the stack has grown to meet new use cases and, over time, has helped to align the way content is represented across our design system’s consumer base.

Let me know in the comments how you get on and what methods you’ve found helpful.