Vijay Verma | September 10, 2021 | 5 min read
How we defined our typography system

A good typography system has the power to string together every element of a product interface.

Additionally, it helps create a distinction between represented use-cases, and maintains the aesthetic value of a brand at all times. And that’s exactly what we were aiming to achieve with our typography system at Zomato. 

While we were formulating typography guidelines for our very own design system, Sushi, we decided to put down a few tips and tricks that may help you scale your typography across multiple apps and devices. All this, without complicating the handoff between designers and developers.


Defining the typography style

The first step in this process is to define a type system that is extensible enough to cater to one’s dynamic needs and requirements. 

In word processors, design programs, and even HTML/CSS, we’re used to having pre-set typography, including everything from font weight, line height to colour, and even spacing. However, to develop a customised typography system, the following properties need to be defined at the very beginning – 

  • Font family
  • Font weight
  • Font size
  • Line height
  • Letter spacing, paragraph spacing, and indentation
  • Decoration (strikethrough and underline)
  • Transform (uppercase and lowercase)
  • Theme (colour)

And then, the two most important steps need to be followed – 

  1. Selecting a typeface
  2. Deciding on a type scale and hierarchy

1. Selecting a typeface

A typeface is a simple collection of letters. 

Most brands that we know of, have their own default typefaces that need to be used when designing. Apple, for example, uses the typeface San Francisco. Google Material Design on the other hand refers to Roboto, and our own design system utilises the primary typeface, Okra.

Initially, we built our typography system based on Circular Std, which is very popular in the modern geometric typeface category. However, we wanted to ensure that we create a system that is scalable enough to support the unique requirements of our app.

After exploring a few options, we decided on Metropolis – an open-source geometric typeface – as the best font to support our use-case. We simply adopted Metropolis, modified it according to our requirements, and named it Okra.


1.1 Determining the basic terminology

For most people, the terms ‘font’ and ‘typeface’ are often used interchangeably. However, these are completely different. A typeface represents the parent category of a font. A single typeface can have multiple fonts as part of it, with slight differences in the look and feel of each.

  • Typeface: The collection of letters and shapes. Example: Arial
  • Font: The combination of a typeface and its different properties such as size, spacing, weight, etc. Example: We can choose many different fonts within Arial, such as italic or bold.
  • Font Family: A collection of all related fonts.  

1.2 Classifying the typeface

There are many typefaces out there, but all fall under five basic categories – 

  • Serif: Within fonts, Serif refers to the small features that appear at the ends of their strokes.
  • Sans Serifs: Sans is a French word meaning ‘without’. Hence, fonts characterised as ‘Sans Serif’ do not include serifs or features that appear at the ends of their strokes.
  • Hand Lettered (Script): Such fonts have a natural, handwritten feel.
  • Monospace: All characters within such a font have the same width.
  • Display: Such fonts are only suitable for use at large point sizes.

Depending on the requirement of a particular system, typefaces are selected for their legibility, accessibility and readability. A design system may have only one typeface or can be paired with another typeface to make it more extensible. 


2. Deciding on a typescale, and hierarchy

A typographic scale is utilised to simply build a balanced font sizing across one’s design system.


2.1 Visual hierarchy

As part of any design project, the visual hierarchy guides customers and helps them view areas that are of prime importance. The visual weight defines the importance of an element on a page, communicating to a viewer what they should focus on, and in what order.

Type sizes and weights are also defined with the following rules of thumb –  

  • Regular weights are best for the minimum 11–19px range
  • Main headline should be bold, not light

But sometimes, taking a case-by-case decision helps in fitting together elements more aesthetically. 

In order to derive other font size values that are harmonious in nature, we simply need to experiment with values greater than the minimum base font size, which is 11px. During this process, we should gradually test with other font size values from the same set, such as 12px, 13px, and so on. 

One good way to find the required pattern for the next font size is to audit the old UI screens and choose the type of scale accordingly.

Following this rule, we finalised on the font size for our Sushi design system – 11px, 12px, 13px, 15px, 17px, 19px, 21px, 24px, 27px.

2.2 Scaling for device size

All typography systems must include responsive type sizes across different device size breakpoints.


Line height

Line heights across all font sizes must be proportional to one another in order to build a good vertical pattern. To accomplish this, one way is to use the same base line height/base font size ratio for deriving all other line heights. 

Standard line height is 150% of the font size or base font size/base line height.


2.3 Determining the naming convention

Type names can help designers and developers understand when and where to use a certain text style.

  • Preset styling: Heading 1, Heading 2, Heading 3, Body Text, and so on. We must already be familiar with these as word processors or HTML/CSS tend to use these frequently.
  • T-shirt size based scaling: T-Shirt size scaling is very common. Such a convention includes text or body as – small, medium, large, and if one requires, xs, xl and so on. 

Shopify’s Polaris is using this naming convention. Even though this works well as a naming convention for most systems, it is not the most scalable solution for every use-case. If we want to add a new size in between two sizes here, it’s almost impossible.

  • Semantic numbering: This refers to scaling with a sequence number, such as – Display-10, Display-20, Display-30…Display-100, and so on.

Do read our last post on the Sushi design system for more details around the different naming conventions considered during this process.


Typography system on Figma

It’s a good practice to create separate type style libraries for all devices in order to make it easier to access and use.


Key points to consider while building a typography system

  • Make the system extremely flexible. If you decide the number of styles required at the very beginning of the process, and feel you need to include more, or remove some due to redundancy later, you should be able go ahead and make the changes.
  • Ensure there is no ambiguity or confusion around the rules of usage. Designers should clearly know which type of style is to be used for which use-case.
  • Spend time on building a scalable naming convention. A good naming convention helps make the design-developer handoff faster as it helps developers become aware of all the rules of application. Thus, they would no longer require design support.

More than anything, building a good typography system as part of a design system helps save a great amount of time across design and development processes, motivating the teams involved to focus on bigger issues, and opportunities for innovation. 

facebooklinkedintwitter

More for you to read

Technology

introducing-pos-developer-platform-simplifying-integration-with-easy-to-use-tools
Sumit Taneja | September 10, 2024 | 2 min read
Introducing POS Developer Platform: Simplifying integration with easy-to-use tools

Read more about how Zomato is enabling restaurants to deliver best-in-class customer experience by working with POS partners

Technology

migrating-to-victoriametrics-a-complete-overhaul-for-enhanced-observability
SRE Team | August 12, 2024 | 11 min read
Migrating to VictoriaMetrics: A Complete Overhaul for Enhanced Observability

Discover how we migrated our observability metrics platform from Thanos and Prometheus to VictoriaMetrics for cost reduction, enhanced reliability and scalability.

Technology

go-beyond-building-performant-and-reliable-golang-applications
Sakib Malik | July 25, 2024 | 6 min read
Go Beyond: Building Performant and Reliable Golang Applications

Read more about how we used GOMEMLIMIT in 250+ microservices to tackle OOM issues and high CPU usage in Go applications, significantly enhancing performance and reliability.

Technology

zomatos-journey-to-seamless-ios-code-sharing-and-distribution
Inder Deep Singh | June 6, 2024 | 15 min read
Unlocking Innovation: Zomato’s journey to seamless iOS code sharing & distribution with Swift Package Manager

Read more to know about how we migrated Zomato’s 10-year-old iOS codebase to Apple’s Swift Package Manager. The blog highlights the process behind building a central syncing mechanism needed across multiple apps, the challenges encountered, and how we resolved them.