Design System Frameworks — the named systems & their rules

Design System Frameworks — the named systems & their rules

A design system framework is a position, not a component grab-bag. Every named system below is opinionated about something — Material about physics and motion, HIG about deference, Carbon about enterprise density, Polaris about merchant content. When you adopt one you inherit its opinions; the friction teams feel is almost always the gap between the system's worldview and theirs. This skill is the field guide: what each system actually believes, the concrete rules that fall out of that belief, and the decision of whether to adopt it, adapt it, or build your own on a headless layer.

The single most important framing: a design system is a set of constraints you're agreeing to. Adopting Material and then re-skinning every component to fight its elevation model costs more than building from scratch. The win comes from picking a system whose opinions you mostly agree with, then theming the parts that are pure brand (color, type, radius, motion personality) while leaving the parts that are pure UX (touch targets, focus order, state layers, a11y semantics) alone.

Platform systems — the OS-backed canon

Material Design 3 / Material You (Google, current: M3 + Material 3 Expressive, 2024–2025)

Philosophy: UI as tactile physical material — surfaces have thickness, cast light, and move with believable motion. M3 dropped literal drop-shadows-as-status for tonal elevation (higher surfaces get a lighter tint of the primary color) and made dynamic color the headline: a single seed (the user's wallpaper on Android, or a brand color) generates a full tonal palette via HCT (Hue-Chroma-Tone) color space. Material 3 Expressive (2025) pushes louder color, larger shapes, springier motion, and emphasized type.

The actual rules:

• 8dp grid (4dp for icons/fine detail). dp = density-independent pixels; sp = scalable pixels for text (respects user font scale — never use dp for type).
• Dynamic color: 5 tonal palettes (primary, secondary, tertiary, neutral, neutral-variant) × 13 tones (0–100) → semantic color roles (primary, onPrimary, surface, surfaceContainerHighest, outline…). You theme by seed + scheme, not by hand-picking hex.
• Tonal elevation + state layers: elevation = surface tint level, not a shadow. Interaction states (hover/focus/press/drag) render as a translucent state layer (8%/10%/10%/16% opacity of onSurface) over the component — every interactive component must implement them.
• Type: Roboto (or Roboto Flex variable) default; 15 type-scale roles (Display/Headline/Title/Body/Label × L/M/S). Brand font allowed.
• Components: FAB (and the new FAB menu), navigation bar (bottom, 3–5), navigation rail (tablet), navigation drawer, snackbar, bottom sheet, extended/filled/tonal/outlined/text buttons, chips, segmented buttons.
• Shape: corner-radius is a token scale (none→full); M3 Expressive adds a full shape library (squircles, cookie shapes) and morphing.

Best for: Android-first or Android-heavy products; teams that want a complete, opinionated, well-documented system with first-party Compose/Flutter/Web implementations. Worst for: strongly-branded products that will fight the elevation/state-layer model, or iOS apps (Material on iOS reads as a non-native port).

Apple Human Interface Guidelines (Apple, current: iOS 18 / macOS 15 / visionOS 2, 2024–2025)

Philosophy: three pillars — clarity (legible at every size, precise, content-first), deference (the UI yields to content; chrome is minimal, translucent, out of the way), depth (layered translucency and motion convey hierarchy and place). HIG is a guideline, not a code library — it tells you how to behave native, and you implement with UIKit/SwiftUI/AppKit.

The actual rules:

• Type: SF Pro (SF Pro Text < 20pt, SF Pro Display ≥ 20pt; New York serif; SF Mono). Dynamic Type mandatory — use the 11 text styles, never hardcode point sizes for content.
• Touch: 44×44pt minimum tap target (hard floor). 8pt grid (4pt fine). Pin to safe areas, never the raw screen rect.
• Platform fidelity is the law: iOS gets tab bars + sheets with detents + edge-swipe-back + the system share sheet; macOS gets a menu bar + toolbar + sidebar + window chrome; never cross-pollinate (no hamburger drawer or FAB on iOS).
• Materials: vibrancy/blur (.ultraThinMaterial→.thickMaterial), semantic colors (.label, .systemBackground), light/dark via semantic tokens.
• visionOS: content on glass material in 3D space; ≥60pt eye+pinch targets; toolbars in ornaments, not screen-edge chrome; default window 1280×720pt at 1m.

Best for: any app that ships natively on Apple platforms and wants App Store goodwill + free accessibility. Worst for: as a cross-platform web system — there is no official web component library; you'd be reimplementing the feel without the engine.

Microsoft Fluent 2 (Microsoft, current, 2023→ongoing)

Philosophy: one coherent language spanning Windows, web, mobile, and the whole Microsoft 365 surface — warm, light, and material-aware. Fluent 2 unified the previously-fragmented Fluent UI React + Windows design into a shared token system.