JM Family Design System

Typography

Typography roles create hierarchy, rhythm, and scannability in product interfaces. Use them to communicate structure, not decoration.

Guidance for adoption

Start here before choosing examples or props. These notes explain where Typography helps, where another pattern is better, and what should stay true in product work.

When to use

  • Page hierarchy
  • Readable body copy
  • Labels and captions
  • Code snippets

When not to use

  • Decorative one-off type styles
  • Viewport-scaled text
  • Negative letter spacing

Accessibility expectations

  • Maintain heading hierarchy.
  • Do not rely on color alone for meaning.
  • Keep line length readable for prose content.

Content guidance

  • Keep headings concise and descriptive so people can scan the page outline quickly.
  • Write body text in plain language that explains context, requirements, or workflow details.
  • Use labels and captions for compact interface text, not for long explanations.
  • Reserve code styling for literal values such as commands, token names, paths, and snippets.

Implementation notes

  • Choose the semantic element first, then apply the visual type role with tokenized CSS when needed.
  • Do not skip heading levels to get a smaller visual style; keep document structure intact.
  • There is no Typography component today, so consumers use semantic HTML plus system type tokens.
  • Truncation, line clamping, and visually hidden text need to be handled in the consuming component.

Usage

<h1> <h2> <h3> <h4> <p> <small> <code>

No import is needed. Use semantic HTML and apply system type roles through tokens and local classes.

Roles

Product typography should map to a purpose. The same visual role should mean the same thing across pages, flows, and generated examples.

Page title

Vendor requests

One primary H1 per page or major view.

Section heading

Request details

Groups related content inside a page.

Body text

Review the vendor information before submitting this request for approval.

Explains context, requirements, and workflow details.

Label

Request status

Names controls, metadata, and compact interface elements.

Caption

Updated 2 hours ago

Supports metadata, helper text, and secondary details.

Code

color.text.primary

Displays token names, paths, commands, and literal values.

Anatomy

Typography decisions should connect semantic structure, visual role, and content purpose. This keeps screens scannable and gives assistive technology a reliable outline.

Vendor management

Request details

Review the vendor information before submitting this request for approval.

  1. Semantic element
  2. Type role token
  3. Content purpose
  4. Hierarchy level
  5. Readable line length
  6. Contrast-safe color

Usage rules

Start with semantic hierarchy

Choose the correct heading level before choosing visual emphasis. Structure comes before styling.

Do not skip heading levels for appearance

If a heading looks too large or too small, adjust the component pattern instead of breaking document order.

Use tokenized type roles

Use the system roles for headings, body, labels, captions, and code instead of one-off font sizes.

Do not scale text with viewport width

Text should stay readable and predictable across breakpoints. Use responsive layout, not fluid type hacks.

Known limitations

What Typography does not do yet, and what consumers need to compose themselves.

  • No Typography component or polymorphic Text/Heading primitives. The system relies on raw semantic HTML plus global token styles, so role-vs-element mismatches require ad-hoc class wiring per consumer.
  • No truncation, line-clamp, or visually-hidden helper. Common typographic needs are solved with one-off CSS in each consuming app today.

Agent guidance

Agents should select typography roles by information architecture and content purpose. They should not invent font sizes to make a panel feel more important.

Generation rules

  • Use semantic heading order before choosing visual size.
  • Use tokenized type roles instead of custom font sizes.
  • Keep dense interface text smaller than hero or page-level headings.
  • Reference type tokens such as var(--type-h3-size) in component CSS; never set font-size in pixels or rems. Inline numbers match the hardcoded-font-sizes anti-pattern.
  • When a visual size does not match the semantic level, keep the correct heading element and apply a token class to restyle it. Do not downgrade h2 to h3 to get smaller text.
  • For truncation or line clamping, add the CSS in the consuming component; there is no truncate prop or visually-hidden helper in the system.
  • For code snippets, wrap with a code or pre element and rely on the global token styles. Do not set monospace font-family inline.

Baseline example

<section aria-labelledby="request-details-heading">
  <h2 id="request-details-heading">Request details</h2>
  <p>Review the vendor information before submitting this request.</p>
</section>
If generated UI needs more emphasis, agents should adjust layout, grouping, or action priority before introducing a new type size.

Decision standard

Typography communicates structure. Use page titles for views, headings for sections, labels for controls, captions for supporting metadata, and code styling only for literal values.