Implementing Design Tokens: Typography
A practical guide to implementing typography tokens in sizable products
Design token concepts have become real within various design systems. As an essential tool for many design systems, including Google’s Material Design 3 and MUI, tokens ease UI elements implementations, management, and updates.
Design tokens store important UI data such as colors, fonts, spacing, animations, and assets, which are helpful in creating and styling cross-platform user interfaces. Like chemical chains form DNA, tokens form the visual voice of the Design System. Rather than inputting fixed values for each platform, a design token includes various formats that enable front-end developers to employ a single variable for building iOS, Android, or web applications.
In this article, I aim to delve deeper into the topic we started in the previous piece of this series dedicated to color tokens.
We focus on implementing a Design System in big digital products with a lengthy development history. If you’re interested in building your Design System but feel overwhelmed by the work involved, this article is here to help.
Why is our experience relevant? The Captiv8 platform is a multiple-awarded platform for connecting brands with influencers with over eight years of story and the most powerful tool in the industry. The price for rapid growth is an enormous number of styles, duplicated elements, and endless patterns. I want to show my design team experience about how we overcome these problems with incremental updates.
Preparation
Collecting Inventory
When embarking on the task of constructing a Design System, it is crucial to begin by gathering inventory. This includes all styles of typography utilized across the platform. We manually collected this information to ensure accuracy and identify the most prominent usage cases.
We revealed two main problems:
- Two different type families are used on the platform simultaneously.
- Over 40 typography styles were used without a transparent system behind them.
These issues were less severe than we previously had with color variety. Additionally, we did not encounter many problems with font usability, such as selecting the wrong font size or line length.
After investigating all font styles, we reduced them to 18, sufficient for 99% of cases. All font sizes have a ratio of 1.2, known as the major third type scale. This means that each size is multiplied or divided by 1.2 from the previous size, starting with the base size, and rounded to a multiple of 4px.
We have two categories for our type styles: heading and body. Each category comes with a default set of variants and options to offer flexibility and suit a diverse range of applications in the user interface. They use a single scale that allows easy application on any screen size.
Implementation Strategy
First, I must add a few words about our font tokens and mixins. Let’s start with the first one.
The tokens are divided into four groups:
- Font family. We use two related families: Roboto and Roboto Mono. The first is for general cases, and the second is when we must represent code usage in the interface.
- Size. Simply font size. We have eight options here.
- Height. Also, eight options work together with size to build a typography system.
- Weight. We use just three options here: regular, medium, and bold.
When organizing your font tokens, rely on which parameters you must vary. We have a few styles with underlined text, but we don’t have unique tokens for that because of redundancy.
All these basic font style properties in SASS syntax are combined to create a mixin. In terms of Figma, a mixin is similar to a text style. For instance, according to SASS, one of the heading styles in our system looks like this:
@mixin heading-xl {
font-family: $font-family-sans;
font-size: $font-size-400;
font-weight: $font-weight-medium;
line-height: $font-line-height-4;
}After analyzing the platform’s current state, we decided not to implement mixins in the first stage. Instead, we will implement them with refactored elements and patterns following our principle of making small incremental improvements with low resource expenditure.
Implementation
We began by mapping font tokens to existing styles, assigning only a subset of tokens to each style rather than the entire style due to our refusal to implement mixins with font tokens.
But why? The line height is the main issue. Adjusting it may disrupt the entire page layout. It is also risky for the elements like text fields and buttons. We aim to minimize post-implementation changes. How have we handled this situation? It’s pretty straightforward. Whenever we change a style, we locate the nearest tokens to the font family, size, and weight parameters. However, if we can’t locate an exact token for the line height parameter, we leave it unaltered. Therefore, there’s no need for any extra modifications.
Here is an example. We have a font style with the following style:
h4 {
font-family: Source Sans Pro;
font-size: 24px;
line-height: 30px;
font-weight: semibold;
}In this case, the replacement will be the following:
h4 {
font-family: var(--font-family-sans); /* Roboto */
font-size: var(--font-size-400); /* 24px */
line-height: 30px;
font-weight: var(--font-weight-medium); /* Medium */
}We succeeded with our previous approach and decided to take it further. In this iteration, we updated the typography system by reducing the base font size from 16px to 14px. Although there was a potential risk of visual disruption, we could stay ahead of our implementation plan by a week.
Of course, we had some issues, but thanking the previous step, we got enough control over typography, it was easy. After a week of fixing miserable bugs and making minor visual improvements, we successfully implemented font tokens into the platform.
The feedback from the user was positive. Despite the significant changes made, the interface became more rhythmic and predictable. We were initially concerned about reducing the base font size by 2px, but there was no negative feedback. Moreover, it made working with mobile resolutions easier.
Conclusion
We have made progress towards establishing a Design System. Fortunately, we did not face significant challenges with the typography aspect of the platform, so this stage was completed smoothly and without disruption to end users. However, we did reap some benefits for the team. Firstly, creating the Design System encouraged collaboration and communication between developers and designers. Additionally, the benefits were not immediately apparent to us until after implementation. The interface did not undergo significant changes, but we gained greater control over future modifications. This has paved the way for future updates and provided front-end developers with a new perspective for organizing their code base and making refactoring easier.
Arranging letters and text in a visually pleasing and readable manner is the art of typography. It can convey emotions and crucial messages through various fonts, styles, and structures. The impact of typography on user experience cannot be underestimated, as it influences all aspects of the interface and works hand in hand with branding. Our team prioritized font tokens and implemented them soon after color tokens. While the order of implementation is flexible, it’s recommended to prioritize this subset of tokens early on.
