Strong typography in your design system is more than specifying fonts and sizes. It helps your team make repeatable decisions about how text should work.

That distinction matters. Text does different jobs:

• A product heading directs attention.
• Body copy supports sustained reading.
• A label identifies a control.
• A data value needs to be scanned and compared quickly.

Each job creates different typographic needs. Robust typography in your design system gives those needs a shared structure. Tokens store decisions. Styles assemble those decisions into useful typographic roles. Usage rules explain when and why to use them.

The result should not be a rigid mathematical machine. It should be a practical system that gives designers and developers enough consistency to work together while leaving room for good judgment.

Type tokens vs. type styles

Typography tokens are named values that represent individual typographic decisions. Depending on the design system, these may include font family, weight, size, line height, letter spacing, or other properties.

A simplified set of typography tokens might describe concepts such as:

• font-family-body
• font-weight-emphasis
• font-size-large

These names give raw values a shared meaning. If a value changes, the token can carry that change through the system rather than requiring teams to find and replace individual settings.

Typography is often more complicated than color or spacing because several properties work together at once. A useful typographic result depends on relationships among the typeface, size, line height, width of the text area, and surrounding space. Changing one value can change the way the whole passage feels and reads.

That is where type styles become useful. A type style combines typographic decisions for a particular job:

• A style such as heading-section might reference a family, weight, size, line height, and letter spacing value.
• A body-default style might combine a different set of values intended for comfortable reading.

The difference is purpose. Tokens describe decisions. Styles describe typographic roles.

This separation can make a design system easier to maintain. A token can change without renaming every role that uses it. Meanwhile, a style can remain understandable to designers because its name describes what the text is doing.

When creating typographic design tokens, avoid reducing typography to isolated numbers. The relationships among those numbers are the system.

Real-world example: Ivy Foundry and Nonpareil Type

The websites for Ivy Foundry and Nonpareil Type show how tokens and styles can work together. Both sites use the same basic set of typographic token names, specified as CSS custom properties:

Which can apply to their respective classes or style blocks:

body {

  font-family: var(--text-font);

}

.heading {

  font-family: var(--heading-font);

}

.button {

  font-family: var(--ui-font);

}

The values assigned to the tokens differ between the two sites. Ivy Foundry uses IvyOra for text and IvyStyle Sans for headings and interface elements. Nonpareil Type uses Emerson Book for text and headings, and Kelly Sans for interface elements.

This comparison shows why the separation is useful. On Ivy Foundry, headings use IvyStyle Sans Bold. On Nonpareil Type, they use Emerson Book at a heavier designated weight. The structure remains consistent while each site retains its own typographic voice.

Naming conventions that survive handoff

A naming convention works when someone who did not invent it can understand it.

Names such as text-16-medium may describe implementation details, but they do not necessarily explain the job of the text. If the size changes later, the name can become misleading. If a second type family enters the system, “medium” may refer to a different visual weight.

Names based on purpose tend to survive change more gracefully. Consider names such as:

• body-default
• body-small
• heading-page
• heading-section
• label
• caption

These identify the role of the text before describing its appearance. The exact vocabulary will depend on the product:

• An editorial platform may need deck, byline, pull quote, and footnote styles.
• A financial product may need data labels, tabular values, and status text.
• An ecommerce system may need product titles, prices, promotional messages, and supporting details.

Start by looking at the content and interface. What jobs does text repeatedly perform? Then name those jobs.

Keep token names and style names distinct enough that designers and developers know which layer of the system they are discussing. A raw size token is not a heading. A weight token is not emphasis. Those values only become meaningful when they are used in context.

Clear names reduce translation work during handoff. Designers can discuss a role, developers can implement that role, and documentation can explain the same role in the same language.

Scale, rhythm, and responsive rules

A type scale can bring order to a design system, but a scale is a tool rather than a law.

Mathematical relationships help narrow an infinite number of possible values into a manageable set. They can clarify decisions and create consistency. But there is no perfect ratio that guarantees good typography. Look at the system with your eyes as well as your calculator.

A useful type scale should create meaningful differences among typographic roles. If two heading levels look almost identical, the system may be technically orderly but visually unclear. If every step in the scale creates a dramatic jump, the hierarchy may feel fragmented.

Rhythm matters too. Study the shapes of paragraphs and groups of text. Look at the space within lines, between lines, and around text elements. A design that contains text is typographic, so surrounding shapes and spaces need to relate to the typographic system.

Line height should respond to the actual type and the job it is doing. Comfortable reading text may need a different rhythm from a short display heading or compact interface label. Letter spacing should also be treated as a typographic decision rather than a decorative adjustment applied by habit.

Responsive typography adds another layer of context. Do not assume every type style should simply shrink at a smaller breakpoint. Ask whether the text is still doing the same job under different conditions:

• A large display heading may need a more compact treatment when space becomes limited.
• Body text may remain relatively stable while its measure changes.
• Navigation or interface text may need different spacing because the interaction context has changed.

Define acceptable ranges and responsive behavior around typographic roles. Test them with real content at narrow, wide, short, and unexpectedly long states. A system should describe how typography behaves, not just how it looks in one ideal frame.

Usage rules and do/don’t examples

A style guide for typography becomes useful when it helps people make decisions.

Showing a style called “heading-section” is not enough. Explain what counts as a section heading, where the style appears, and what it should not be used for. For each important type style, document its job, typical content, and relationship to nearby text.

• Do use a page heading to identify the primary subject of a screen. Don't use a page heading simply because you want text to look large.
• Do use emphasis to clarify meaning within a passage. Don't use heavier text on every sentence that feels important.
• Do test body styles with realistic paragraphs and content lengths. Don't approve a reading style based on a two-line placeholder.

Good examples make invisible reasoning visible. They also reveal where a system is incomplete. If designers repeatedly misuse a style, the problem may not be designer discipline. The system may be missing a necessary role, or its naming and documentation may be unclear.

Review mistakes as evidence. They can tell you where typography in your design system needs to grow.

Documenting in Figma and in code

The design file and the codebase should tell the same typographic story.

In Figma, text styles can collect multiple typographic properties into reusable styles. Variables and tokens can support the underlying values and relationships. Keep the visible style library focused on roles designers actually need to apply.

Avoid creating a style for every mathematically possible combination of size and weight. That produces a menu of ingredients rather than a typographic system.

Show styles in context. A documentation page can include a style's name, purpose, example content, common neighboring styles, and responsive behavior. Realistic examples are more useful than rows of identical sample sentences.

In code, preserve the same semantic thinking.

A token layer may contain foundational values for family, weight, size, line height, and spacing. A semantic layer can then combine or reference those values for roles such as body text, headings, labels, and captions.

The exact technical architecture will vary. The important part is that names and relationships remain understandable across tools.

Designers should be able to say, “This is section-heading text,” and developers should know what that means without translating it into “the 28-unit semibold one.”

Documentation should also record typeface requirements that tokens cannot fully express, including:

• Language support
• Available styles
• OpenType features, when relevant
• Variable font axes
• Fallback behavior
• Licensing or distribution constraints that affect implementation

Fonts are software. Treat their technical characteristics as part of the design system.

Keeping the style guide from going stale

A typography style guide is a record of decisions, and decisions change. Products gain new features. Content becomes more complex. New languages reveal problems that were invisible in the original system. Teams discover that a style intended for one job is repeatedly being stretched into three.

Plan for maintenance from the beginning. Give ownership over typography: someone or some group should be responsible for reviewing additions, resolving duplicated styles, and checking whether documentation still matches implementation.

When a new style is proposed, ask what job the existing system cannot perform. Test the proposed style with real content and across relevant contexts. If the need is legitimate, add the role and document it. If an existing style can do the job, clarify its guidance instead.

Periodically compare Figma, code, and the published typography style guide. Look for:

• Mismatched names
• Detached values
• Undocumented exceptions
• Styles that are no longer used

Most importantly, keep looking at the typography itself. Tokens can preserve values. Styles can preserve combinations. Documentation can preserve intent. None of them can replace typographic judgment.

A good design system creates a framework for that judgment. It helps teams pay attention to the jobs text is doing, the relationships among shapes and spaces, and the changing contexts in which people read.

That is the real purpose of typography in a design system: not to make every piece of text identical, but to make typographic decisions more thoughtful, consistent, and understandable.

Key takeaways

• Tokens store individual typographic decisions; styles combine tokens into named, reusable roles.
• Name styles by the job text is doing, not by its appearance — role-based names survive change better than descriptive ones.
• Treat type scale, line height, and letter spacing as related decisions, not isolated numbers.
• Usage rules and do/don't examples turn a style library into a decision-making tool.
• Figma and code should describe typography in the same semantic language.
• Assign ownership and review the system regularly so documentation doesn't drift from implementation.

Frequently asked questions

Q: What are typographic tokens?

A: Typographic tokens are named values that store typographic design decisions such as font family, weight, size, line height, and letter spacing. They help designers and developers reference shared values consistently and update those values across a design system.

Q: What's the difference between type tokens and type styles?

A: Type tokens represent individual design values or decisions. Type styles combine typographic properties into reusable roles for text, such as body copy, page headings, labels, or captions. Tokens are the underlying values; styles describe how groups of values are used for specific typographic jobs.

Q: What should a typography style guide include?

A: A typography style guide should document type roles, style names, usage guidance, responsive behavior, and realistic examples. It should also explain do and don't scenarios and record technical requirements such as language support, font features, fallback behavior, and implementation considerations.

Q: How do you document typography in a design system?

A: Document typography using the same semantic language in design tools, code, and written guidance. Show each type style in realistic context, explain the job it performs, describe responsive rules, and connect styles to the underlying typography tokens. Review the documentation regularly so it continues to match the product.