Typography for Data
Text makes up a large majority of the content in internal, operational products. Between the many labels, values, and other helpful information crammed into charts, graphs, column lists, and the like, text serves many functions and takes many forms. So when we updated our spacing and layout system for internal products, we knew we would also have to tackle our typography.
The lay of the land
We have 4 core typography styles in our design system which help our consumer products keep it simple, stupid (K.I.S.S.): Headline, Title, Subtitle, and Body styles.
In most of our consumer-facing contexts (largely mobile), designers only really need to combine a few of these styles per screen to deliver a simple, consistent, and purposeful experience for users.
But when you put together a multi(verse)-zone layout with site-wide navigation, in-page navigation, a data table with pagination, corresponding filters, and a side panel for additional details, you begin to ask yourself if more (Loki) variants would be helpful. We found that to be the case while assessing the (mis)use of our type styles across the 75+ operational products at Lyft.
Designers would find themselves using semantically improper styles simply to get the right size or weight in the right place.
To get a more holistic and detailed understanding of designers’ needs, we looked at responses from a survey with 15 operational/internal tools designers to gather thoughts on what aspects of the typography attribute needed to change in order to support their products:
Operational products need to fit in a more dense space, like tables, charts, and graphs. Need smaller components and text that can be suitable in a limited space.
Size of some fonts is too large to work nicely in all cases.
For typography we want smaller type sets and open-source friendly font families.
Need monospace font for numbers in a table or column list, to enable easy scanning and comparison of digits vertically.
Across the board, we heard that our Core Typography styles and guidelines did not accommodate all the operational typography use cases. Thus sprung forth the TVA (Type Variance Authority) — with the mission to not only prune the biggest offenders but also to find the variants needed to support typography for data content.
Purpose-driven typography
Before jumping straight to new type styles, we partnered with designers from 10 operational products to collect key screens and organize distinct typographic use cases into an audit table. We determined categorical groupings of type properties or patterns (along the y-axis) by asking the question:
As a designer placing this piece of text on the interface, what purpose or functional role does it play in the experience?
Perusing these use cases across the key screens, we saw that designers needed clarity and guidance on styling text within:
- Section headings — text headings for sections or groups of UI
- Label:Value pairs — the text combination for displaying data
- Interactive elements — any actions or controls that include text
- Visual indicators — any other UI that includes text and provides information rather than interaction
- Code — text that represents code content
We also assessed other stylistic and formatting variants such as usage of secondary shades of color, text weights, all caps, monospace numbers, and more.
As we identified these functional roles of type, we documented the overarching problems with the current type styles and uncovered the need for (1) further guidance on using the core type styles and (2) additional styles to support data text.
Data text styles
What kinds of data text do we need to account for?
Looking at two-column layouts, data tables, forms, and other data viz contexts, we found that label text and value text are the most prevalent type of content (pun intended) on a given operational product page. While label text simply acts as a title for data values, value text can take shape as basic text, alphanumeric characters, static vs. dynamic numbers, dates/times, currency, and more. We also need to consider that value text often lives within structured layouts such as tables — that’s where monospace numbers and text alignment for tabular data comes in. Lastly, our products need to display code snippet text in some contexts.
With all these unique use cases and only 4 core type styles to work with, it’s no wonder that we see that every product or even a section of a given page is styled so differently. Size? Weight? All caps? Shades of gray? The permutations are endless.
To address this, we decided to add a new set of data type styles and usage guidelines for Labels, Values, Monospace values, and Code. These aren’t intended to replace the existing core type styles but to add another layer of functional typography to the system, equipping designers to present text data content more purposefully, consistently, and confidently.
Deciding on the sizes/weights was pretty straightforward; the hard part was actually determining that these type styles serve a semantically unique purpose. Rather than arbitrarily dictating (we practice the art of diplomacy!) what we think would work, we identified designers’ most commonly used sizes/weights, stress tested with our key operational product partners, and added to the type ramp accordingly.
Supporting smaller sizes
Another common finding across our operational products was the need for smaller heading sizes for additional levels of information and data. So we added two more!
Our Headline styles play the role of heading up entire sections or groups of content. Not to be confused with our Title styles, Headlines are crucial for users on screen readers to navigate through headings and sections on a given page. Title text usually sits at a level lower in the IA to label primary content.
When less is not more
As systems thinkers, we want our partner teams to create experiences with the right tools for the right time. We all like to say that “less is more,” but when is less not more?
When the lack of choices obscures purpose.
This story is part of Lyft Product Language’s series on How to Systematize Internal Products.
Up next: Russian Nesting Figma Libraries (coming soon)
