How Top Design Systems Handle Typography

The most widely used design systems in the industry have each made distinct typographic decisions — choices about typefaces, scales, weight conventions, and the rules that govern how text behaves in components. Studying these systems reveals the reasoning behind their choices and the trade-offs they navigate. For teams building their own design systems, this comparison offers a practical reference for decisions you will face.

Apple HIG: San Francisco and New York

Apple's Human Interface Guidelines define the most opinionated system typography in the industry. Unlike open design systems that suggest you bring your own fonts, Apple's system is built entirely around proprietary typefaces optimized for Apple hardware.

San Francisco (SF) is the primary system font for all Apple platforms: macOS, iOS, iPadOS, watchOS, and tvOS. It exists in two optical sizes — SF Pro Display (for text above 20pt) and SF Pro Text (for text 20pt and below) — and switches automatically based on point size when used via the system font stack. This auto-switching is invisible to developers using system APIs but meaningful: the optical corrections for text at small sizes differ from those optimized for display.

New York is Apple's serif companion, designed to pair with San Francisco. It appears in Reading mode in Safari, some marketing contexts, and anywhere the system calls for a warmer, more editorial character. New York was specifically designed for long-form reading on high-resolution displays.

Apple's type scale uses named text styles rather than explicit pixel sizes: Large Title, Title 1 through Title 3, Headline, Body, Callout, Subhead, Footnote, Caption 1, and Caption 2. On iOS, these sizes are not fixed — they scale with Dynamic Type, the accessibility feature that allows users to adjust system text size globally. Every properly implemented app on iOS respects Dynamic Type, which means Apple's type system is inherently fluid by design.

The consequences for design systems built for Apple platforms are significant:

1. Font size is always specified in points, and those points are rendered at different pixel densities depending on the device.
2. All text must be Dynamic Type-compatible unless there is a specific reason to opt out.
3. Custom fonts used in iOS apps must declare support for each Dynamic Type scale step if they want to participate in the system.

What to learn from Apple's approach: Building optical size variants into a type system is worth considering for large-scale systems. Having a dedicated small-size variant that is optimized for captions and labels — rather than simply scaling down a display-optimized face — improves readability at the extremes of the scale. Variable fonts with an opsz (optical size) axis make this practical for web-based systems.

Material Design: Roboto and the Type Scale

Google's Material Design has gone through two major typography overhauls: the original Material Design (2014), Material Design 2 (2018), and the current Material Design 3 (2021, also called Material You).

Roboto was commissioned by Google and released alongside the original Android redesign. It is a geometric grotesque with humanist influences — technically neutral enough for UI use but slightly warmer than a pure geometric face like Futura. Roboto comes in 6 weights (100 through 900 in steps) and has companion families: Roboto Condensed, Roboto Mono, and Roboto Flex (the variable font version).

Material Design 3's type scale is one of the most thoroughly documented examples of a role-based type system. It defines five categories with multiple size options:

The use of "sp" (scaleable pixels) rather than px reflects Android's equivalent of iOS's Dynamic Type — text scales with system accessibility settings.

Key insights from Material Design's approach:

Five categories beats numbered scales for role clarity. Display, Headline, Title, Label, Body — each category has a distinct semantic role. A developer reading a spec knows exactly what "Title Large" is for without consulting a dictionary. This is more explicit than --font-size-600 even if both refer to the same raw value.

Weight is part of the scale definition, not separate. In Material Design 3, Title sizes use Medium weight (500) by default. This is not a component-level decision — it is baked into the type scale itself. The token md-sys-typescale-title-medium-weight: 500 is part of the type system, not the button or card component.

Multiple sizes per category enables flexibility without free-form choices. Providing Display Large, Medium, and Small means teams can always find an appropriate size without inventing new ones. The constraint is firm (you pick from the provided options) but flexible enough to handle most real layout needs.

IBM Carbon: IBM Plex and the 4px Grid

IBM Carbon Design System is a textbook example of a design system built for enterprise software at scale. It serves products across IBM's entire portfolio — from cloud infrastructure dashboards to AI research tools — and has been in production since 2018.

IBM Plex is IBM's open-source type family, released in 2017 after years of development. It includes IBM Plex Sans, IBM Plex Serif, IBM Plex Mono, and IBM Plex Condensed, each in 8 weights with italics. The family was designed to reflect IBM's engineering character — precise, rational, functional — while remaining warm enough for long-form reading.

IBM Plex is available on Google Fonts, making it accessible to teams outside the IBM ecosystem who want its qualities.

Carbon's type scale is built on a 4px base unit — the same grid increment used for all spacing in the system. The type scale values are multiples of 4: 12, 14, 16, 18, 20, 24, 28, 32, 36, 42, 48, 54, 60, 68, 76, 84, 92px. This is not a ratio-based scale in the traditional sense; it is a stepped scale that prioritizes alignment to the spatial grid over mathematical harmonic relationships.

The practical benefit: when you set a heading to 32px and a paragraph with a 24px line-height, the text block sits exactly on the 4px grid. Spacing between elements can use multiples of 4 and align naturally with the text. This makes Carbon implementations unusually consistent in their vertical rhythm — a quality that is especially valuable in data-dense enterprise UIs.

Two fluid type scales: Carbon provides two named type scale configurations: Productive (designed for task-based UIs, smaller sizes, high information density) and Expressive (designed for marketing and editorial contexts, larger display sizes). This is an underappreciated pattern: rather than forcing all surfaces to use the same scale, the system acknowledges that different product contexts have genuinely different typographic needs.

/* Carbon's productive body tokens (approximate CSS representation) */
:root {
  --cds-body-compact-01-font-size: 0.875rem;  /* 14px */
  --cds-body-compact-01-font-weight: 400;
  --cds-body-compact-01-line-height: 1.28572;

  --cds-body-01-font-size: 0.875rem;           /* 14px */
  --cds-body-01-font-weight: 400;
  --cds-body-01-line-height: 1.42857;

  --cds-heading-01-font-size: 0.875rem;        /* 14px */
  --cds-heading-01-font-weight: 600;
  --cds-heading-01-line-height: 1.28572;

  --cds-heading-02-font-size: 1rem;            /* 16px */
  --cds-heading-02-font-weight: 600;
  --cds-heading-02-line-height: 1.375;
}

Shopify Polaris: Inter and Practical Commerce

Shopify Polaris is one of the most pragmatically designed systems in the industry. Its priorities are explicit: help merchants build successful stores. Every design decision is evaluated against that commercial objective.

Inter is Polaris's primary typeface. Designed by Rasmus Andersson specifically for screen use, Inter is a near-ideal choice for a commerce platform: neutral enough not to impose a brand character on the merchants using it, highly legible at small sizes, and available in a variable font format with extensive OpenType feature support. Inter is available on Google Fonts and is free for commercial use.

Polaris's type scale was significantly revised in Polaris v12 (2023) and is defined with merchant-facing readability as the primary criterion. The scale includes:

/* Polaris type scale (approximate CSS custom property representation) */
:root {
  --p-font-size-75:  0.6875rem;  /* 11px */
  --p-font-size-100: 0.8125rem;  /* 13px */
  --p-font-size-200: 0.875rem;   /* 14px */
  --p-font-size-300: 1rem;       /* 16px */
  --p-font-size-400: 1.25rem;    /* 20px */
  --p-font-size-500: 1.5rem;     /* 24px */
  --p-font-size-600: 2rem;       /* 32px */
  --p-font-size-700: 2.625rem;   /* 42px */
  --p-font-size-750: 3rem;       /* 48px */
}

Polaris's naming uses a numeric system (75, 100, 200) that allows values to be inserted between existing steps — --p-font-size-75 sits below 100, providing room for smaller label text without renaming the entire scale.

Notable Polaris decisions:

14px as the primary body size. Polaris uses 14px (0.875rem) rather than the more common 16px for much of its UI text. At the typical viewing distances and screen resolutions of the Shopify admin, 14px is legible and allows more content density — a pragmatic choice for a product where merchants need to see as much information as possible.

Semantic type roles exposed directly. Polaris exposes type roles that map directly to merchant-facing product patterns: display, heading, subheading, body, caption. These align with how Shopify's product designers think about the hierarchy of a page, not with abstract scale steps.

Atlassian Design System

Atlassian's design system serves a product portfolio with some of the most complex UI requirements in enterprise software: Jira (dense project management grids), Confluence (long-form document editing), Bitbucket (code review with monospace text requirements), and numerous other tools.

The font choice: Atlassian uses a system font stack as its primary typography — -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Noto Sans", Ubuntu, "Droid Sans", "Helvetica Neue", sans-serif. This is not a single typeface choice but a prioritized list that renders San Francisco on Apple devices, Segoe UI on Windows, Roboto on Android, and falls back through several options. The system font stack approach means near-instant rendering (no font download), perfect platform integration, and zero licensing concerns.

The trade-off is less control over the appearance. System font stacks look different on different operating systems, which is acceptable for Atlassian's enterprise context where users primarily access products on managed corporate devices.

Code typography: For developer-facing surfaces, Atlassian uses a monospace stack. This is a reminder that design systems for developer tools must solve typography for code display, not just prose and UI — a challenge that exploring the monospace font options requires its own decisions.

Spacing integration: Like Carbon, Atlassian's type system integrates tightly with a spatial grid (an 8px base unit). Font sizes and line heights are chosen to align with the grid, ensuring that text blocks compose naturally with component spacing.

Key Takeaways for Your System

After studying these five systems, several principles emerge that apply regardless of which typeface or scale you choose.

1. Choose a typeface before defining the scale. The typeface's x-height, weight range, and available OpenType features all affect how the scale feels in practice. Inter and IBM Plex Sans have high x-heights that make them feel larger at the same nominal size than a typeface like Garamond. The scale you define must account for the typeface's optical characteristics.

2. Name your type roles for your context. Material Design's Display/Headline/Title/Label/Body names work for Google's product suite. Polaris's names work for commerce. Your system should use names that match the vocabulary your design and engineering teams use when describing the interface.

3. Build two scales if your products span different density requirements. IBM Carbon's Productive/Expressive split is worth emulating. A type system that serves both a data-dense dashboard and a marketing landing page will make compromises serving both contexts equally — separating them into distinct configurations is honest about those different needs.

4. Define weight as part of the type style, not as a separate decision. Material Design's approach — baking font weight into each named type style — reduces the number of decisions a component author must make. "Use Title Medium" is more explicit than "use heading-md and remember to set font-weight: 500."

5. Document the line-height alongside the size. Every type scale example above specifies line-height as part of the type style definition, not as a component-level concern. Line-height is not optional styling; it is part of the type scale itself.

6. Test at the extremes of your scale. Display sizes that look stunning on a 27-inch monitor need testing on 375px viewports. Caption sizes that are readable on a Retina display need testing on lower-DPI screens. The type scale that ships from a design system should have been validated at every viewport and resolution the products it serves will encounter.

The systems reviewed here represent years of refinement under real product pressure. They are not perfect — each has documented limitations and ongoing evolution. But they offer concrete, battle-tested answers to the typographic questions every design system eventually faces.