Typography in App Design: Build a Readable Type System

Choose app typography by what people must read and do, then give the brand room within that system. A distinctive heading is useful only if amounts, instructions, errors and controls remain readable in the conditions where the app is used.

Key Takeaways

• Test real content, including ambiguous characters and long translations.
• Define type by role rather than choosing a new size on every screen.
• WCAG does not prescribe a universal 16px minimum.
• Verify enlargement, reflow and contrast separately.

Start with the difficult text

Use the candidate fonts in a payment amount, a dense list, a form error and a long button label. Compare I, l, 1, O and 0; check the punctuation and symbols your product needs. Include every supported writing system before committing to a family.

A font that looks good in an English headline may have a different fallback in another script. That affects line breaks, control height and visual tone. Confirm licensing for the actual app/web distribution rather than assuming a font download covers every use.

Give each text role a job

This is an illustrative web-app starting scale, not a standard or a native-platform specification:

Role	Starting treatment	What to test
Page heading	2rem, strong weight	Long titles at narrow width
Section heading	1.5rem	Clear distinction from body
Body/instructions	1rem, comfortable line spacing	Reading at enlarged text size
Control label	1rem, clear weight	Long translation and focus state
Supporting text	0.875rem where appropriate	Legibility, contrast and importance
Numeric result	Task-dependent size	Alignment, units and sign

Do not shrink necessary information to fit a fixed component. Let the component adapt. Native apps should use their platform's scalable text mechanisms and test the supported accessibility sizes; CSS values are not interchangeable with native points or scaled units.

The design-system guide explains how to encode those roles so changes remain consistent.

Understand the actual accessibility rules

WCAG Contrast Minimum specifies 4.5:1 for normal text and 3:1 for large text under its definitions and exceptions. Large text has a technical definition; a design token called “large” does not establish that it qualifies.

Resize Text addresses enlargement up to 200% without lost content or functionality, subject to exceptions. Reflow addresses adaptation at small effective widths.

The earlier version of this article incorrectly described 16px body text and 18pt headings as WCAG minimum sizes. Those are not universal WCAG requirements. A chosen default still needs real readability and layout testing.

Use brand expression where it helps

PaceCalc provides a concrete example: large serif numerals give the pace result its character, while the surrounding controls remain restrained. The result is the thing the person came to read; the type emphasizes that task.

A custom face does not need to occupy every label. You might reserve it for headings or results and use a robust text family elsewhere. Make that choice from the actual product rather than a rule that all financial apps must look one way.

Test a screen in its least convenient state

Use a checklist with real content:

• A long name and a long translated heading.
• A negative amount, a large amount and a missing value.
• Increased text size and a narrow viewport.
• Loading, validation, disabled and error states.
• Slow font loading or a fallback font.
• Light and dark surfaces with measured contrast.

Record clipping, ambiguous units, truncation that hides meaning and buttons pushed out of reach. Responsive design essentials covers the layout checks; the palette examples show why foreground/background pairing matters.

Choose the family after testing these conditions. A type system earns its place when the difficult screen still reads clearly.