Typography for Data

Michael Yom
Sep 7 · 6 min read

How to Systematize Internal Products: Part 2

Various data in graphs and charts
All the data | Photo by Anna N

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

Core Typography set

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.

Smilling Baby in an Oversize Denim Jacket
Smilling Baby in an Oversize Denim Jacket
That… fits well! | Photo by Katie E

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.

Pruning type styles

Purpose-driven typography

As a designer placing this piece of text on the interface, what purpose or functional role does it play in the experience?

Audit table for current type usage

Perusing these use cases across the key screens, we saw that designers needed clarity and guidance on styling text within:

  1. Section headings — text headings for sections or groups of UI
  2. Label:Value pairs — the text combination for displaying data
  3. Interactive elements — any actions or controls that include text
  4. Visual indicators — any other UI that includes text and provides information rather than interaction
  5. 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.

Documenting the current problem with type usage for data content

Data text styles

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.

Different forms of data text

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.

New Data Typography set

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.

Label:Value pairs in action
Value Monospace to align tabular data
A monospaced system font to represent Code text

Supporting smaller sizes

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.

Headlines vs. Titles

When less is 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)

Tap to Dismiss

Sweating the details so you don’t have to