5 min read

Fluent Flex · Chapter 02

Typography

V9 used a single font family for every surface. Then Copilot arrived with a different typographic personality. The answer wasn't a parallel system — it was a mathematical scale flexible enough to hold both, with shipped response components across Word, Excel, PowerPoint, Teams, and Outlook.

Type tokens before — 3 font families, 10 sizes, 4 weights, 10 line heights, 17 named styles

Named text styles after — 14 Functional + 18 Content

4px

Modular scale base — every size step a clean 4px increment

Microsoft 365 apps shipping the new Copilot response components

Background

The Type System Before Flex

V9 typography was built on a single font family — fontFamilyBase (Segoe UI) — for every surface. 44 tokens total: 3 font families (base, monospace, numeric), 10 font sizes, 4 weights, 10 line heights, and 17 named composed styles.

Every named style — from caption2 through display — used the same Segoe UI base with no distinction between reading content, UI labels, or expressive moments. The values were hand-picked, not derived from a scale, which meant updating the ramp required touching every value individually.

The arrival of Copilot as a surface introduced a new typographic personality — conversational and warm, built on Aptos — that needed to coexist with Fluent's precision-productivity tone. V9's single-font architecture couldn't accommodate this without a parallel type system. Teams building Copilot response components in Word, Excel, PowerPoint, Teams, and Outlook were improvising independently.

Impact

Before & After

V9 — Before

44 tokens, one font

17 named styles (caption2 through display) all using Segoe UI. Hand-picked values — no mathematical relationship between steps. No distinction between reading content, UI labels, or expressive moments.

Single font family for every surface and context
No type strategy for the Copilot sidecar
Values required individual edits to update the ramp
Cross-surface consistency brittle — Teams looked different from Word

Fluent Flex — After

32 named text styles, dual-font

14 Functional + 18 Content styles across two distinct ramps. Four font families replace the single V9 base. Fluid sizing via CSS clamp(). Web + iOS coverage (Android TBD).

Functional: Segoe Sans for UI chrome and labels
Content: Segoe Sans for reading, Georgia Pro for editorial, Consolas for code
4px modular scale — every step a clean increment of the base
System ramps for mobile (Apple HIG / Google Material)

Foundation

The 4px Modular Scale

The entire type system is built on a 4px modular scale starting at 16px (1rem). Every size step is a clean 4px increment — keeping type mathematically aligned with grids, icons, and spacing. This removes the micro-adjustments designers had to make with the old hand-picked values and makes responsive scaling straightforward.

Line heights are percentage modifiers that respond proportionally to font size, not hardcoded values riding alongside. Fluid sizing uses CSS clamp() to scale between viewport breakpoints — the type size adapts to its container rather than jumping at fixed breakpoints.

Variable font weights

Regular420

Medium550

Semibold600

Bold625

These are variable-axis values, not traditional static weights. The font's optical size axis handles size-appropriate rendering automatically across the fluid range.

Line height multipliers

Functional headings1.2×

Functional body1.4×

Content paragraphs1.7×

Fractional results snap to the nearest 2px via CSS round(), keeping text baselines on the 4px grid.

On web, sizes use CSS clamp() with container query inline units (cqi) to scale smoothly between a floor and ceiling based on container width — not viewport width:

font-size: clamp(floor, intercept + slope·cqi, ceiling)

The slope and intercept derive from the floor, ceiling, and the 1440px maximum breakpoint. Mobile platforms use fixed platform-native sizes and do not scale fluidly — iOS follows Apple's Dynamic Type, Android follows Material.

4px modular scale diagram showing font size steps from 10px through 40px, each step labeled with its relationship to the 16px base unit, with line height multipliers shown alongside — Every step is a clean 4px increment — the math is auditable, the relationships are visible, and the system holds at any viewport size.

Architecture

Two Ramps, One Scale

Two distinct ramps derived from the same 4px scale foundation:

Functional — UI chrome and labels

Segoe Sans for buttons, labels, inputs, navigation, and other UI controls. Tight, efficient, built for scanning rather than reading. The type that the interface speaks in.

Content — reading, editorial, and code

Three sub-ramps within Content, each with a distinct role:

Content (Segoe Sans) — for reading and long-form text. The Copilot response type.
Content Editorial (Georgia Pro) — for expressive headlines and editorial moments. Warmth and distinctiveness where the interface earns it.
Content Code (Consolas) — for code and monospaced content.

Side-by-side comparison of Functional (Segoe Sans) and Content (Segoe Sans, Georgia Pro, Consolas) ramps at matching scale steps, showing how each font family expresses the same size differently — One scale, two ramps. The size steps are shared — the font families express them differently for their distinct contexts.

Application

The Copilot Sidecar Strategy

The Copilot sidecar across Microsoft 365 apps needed a typographic spec that worked across five very different contexts — a spreadsheet, a document, a presentation, a chat application, and an email client — while feeling like one consistent system.

The dual-font ramp provided the answer: Copilot response text uses the Content ramp (Segoe Sans for reading) with relaxed line heights optimized for longer-form AI output. UI labels and controls within the sidecar use the Functional ramp. Two different type registers, both from the same scale, both feeling like Fluent.

New response components — shipped in Word, Excel, PowerPoint, Teams, and Outlook — use this spec as their foundation. The System Shaper Award recognized the dual-font type ramp specifically as foundational work.

Copilot sidecar shown in three Microsoft 365 apps — Word, Teams, and Outlook — with the Content type ramp rendering AI response text consistently across all three contexts — The same Content type ramp, rendering across three very different host applications. Consistent Copilot typographic experience across M365.

Cross-platform

Mobile: System Ramps Over Custom

Mobile typography follows Apple HIG (Dynamic Type) and Google Material — system ramps rather than custom ones. This is a deliberate choice: system ramps ensure text scales with user accessibility preferences while preserving hierarchy. It also means the Fluent type system doesn't fight the platform.

Where the Fluent type system contributes on mobile is role assignment: the same Functional/Content distinction maps to mobile type roles, keeping the semantic structure consistent even when the underlying font and size decisions follow the platform.

"The dual-font type ramp, and the representation challenges between AI and system components — she has continued to impress. It's been genuinely inspiring to watch her bring clarity and structure to such nuanced problems, organizing everything in a way that feels intuitive and deeply usable."

Looking ahead

What's Next

Type tokens as input to AI-generated layout — token names encode enough semantic context that a model can derive correct type hierarchy (heading, body, label, code) without a lookup table.
Android type coverage is currently TBD — the same Functional/Content distinction will map to Material type roles when complete.
As the Copilot surface evolves, the editorial type register (Georgia Pro) creates room for more expressive AI output moments where the interface warrants them.

Password required