Design systems gallery

In one line: the major public design systems each answer the same question differently — how do you make consistent UI at scale without re-deciding it every time? — and each one is worth studying even if you never import a line of it.

What it is

A design system is a shared language for a product team: design tokens (color, spacing, type), components (button, input, modal), patterns (form layout, empty state, error page), and the documentation and governance that hold them together. It is more than a component library — it includes the rules for when and how to use each piece.

Public design systems are built by teams who have solved the consistency problem at real scale. Even if you never import a single component, they are an education in tradeoffs.

Why it matters

Picking or building the wrong system costs months. Choosing a commerce-admin system for a data-analytics product means fighting it on every screen. Choosing a headless primitive library without accessibility investment means rebuilding keyboard navigation from scratch across every component. Choosing no system at all means re-deciding every padding value in every code review, forever.

See it

The demo renders a canonical set — button, input, badge, card — through swappable token presets (no third-party brand assets; the fictional Lumen brand carries every preset). Toggle preset, theme, and density to feel how radius, accent, border weight, and spacing alone separate a dense enterprise system from a soft, expressive one.

How it works

Every system sits on a token foundation, ships components, and makes explicit or implicit tradeoffs across five axes: depth (how many components), accessibility posture (enforced vs. guidance), aesthetic freedom (neutral vs. opinionated), framework support (one vs. many), and governance model (corporate vs. community).

The breakdown below covers what each system actually teaches — even if you use none of them.

Material Design 3 (Google)

Built for: cross-platform product UI — Android, web, Flutter, and beyond.

• Teaches: dynamic color (derive a full palette from one seed via the HCT color space), elevation as a signal rather than decoration, and state layers expressed as tinted overlays rather than separate color tokens.
• Strengths: one of the most comprehensive token systems publicly documented; genuine cross-platform parity; research-backed, perceptually consistent dynamic color.
• Tradeoffs: a heavy "Material" aesthetic that reads as "Google app" even when customized; specs sometimes lag the web implementation; generous whitespace fights information-dense layouts.
• What to steal: the tonal palette approach — deriving a complete, harmonious palette from one seed applies to any system.

Carbon (IBM)

Built for: enterprise software and data-heavy product UIs.

• Teaches: information density as a first-class constraint (sm/md/lg variants on almost every component), accessibility by enforcement rather than suggestion, and disciplined component APIs forced by multi-framework parity.
• Strengths: the deepest enterprise component catalog of any open-source system; Apache-2.0 with paid maintainers; exhaustive documentation covering usage, code, accessibility, and content.
• Tradeoffs: the IBM aesthetic is intentional and takes real effort to diverge from; bundle size is real (code-split aggressively); the depth can overwhelm a small team.
• What to steal: the density system — building sm/md/lg variants from day one avoids retrofitting compact views later.

Polaris (Shopify)

Built for: the Shopify admin — everything behind the merchant dashboard.

• Teaches: that purpose-scoped systems work best (Polaris is for the admin, not for Shopify.com), and that content guidelines deserve the same rigor as component APIs.
• Strengths: excellent content guidance (voice, error messages, microcopy) worth reading even if you never use a component; clear migration and deprecation signals.
• Tradeoffs: customization is painful; React-first with weaker community ports; forces a "Shopify" feel onto unrelated products.
• What to steal: documenting when to use each component with a structured use-case table.

Fluent 2 (Microsoft)

Built for: Windows, Microsoft 365, and enterprise web products.

• Teaches: adaptive color via a perceptual luminance model (accessible contrast across light, dark, and high-contrast modes without per-mode overrides), and an explicit layer model for elevation.
• Strengths: a sophisticated semantic token system; first-class high-contrast and forced-colors support; strong reach into native desktop (WinUI).
• Tradeoffs: a heavy Microsoft aesthetic; web-component parity with the Figma kit isn't always in lockstep.
• What to steal: forced-colors handling — adding @media (forced-colors: active) to your tokens is a low-effort accessibility win.

Primer (GitHub)

Built for: GitHub's own product surfaces — issues, pull requests, settings.

• Teaches: code-first token design (tokens ship as JSON consumed identically by Figma, CSS, and React, so there is no design→dev handoff gap) and accessibility tooling as infrastructure.
• Strengths: a public deprecation log with migration guides; the Octicons icon set; technical, developer-focused content guidelines.
• Tradeoffs: an unmistakably "developer tool" aesthetic; non-React parity can lag; not built for expressive consumer products.
• What to steal: JSON-first tokens as the single source of truth that generates CSS, Figma Variables, and platform outputs.

Atlassian Design System

Built for: Jira, Confluence, Trello, Bitbucket, and the broader suite.

• Teaches: full Figma Variables parity with the code token system, and primitives as a layout system (Box, Stack, Inline, Text) that constrain spacing to the token scale.
• Strengths: one of the most sophisticated Figma Variables integrations; deep documentation including accessibility and content guidance.
• Tradeoffs: built for Atlassian products — consuming it elsewhere needs genuine philosophical alignment, not just reskinning; the public/internal boundary isn't always clear.
• What to steal: the primitives layout system — routing all layout through token-based primitives prevents ad-hoc margins from fragmenting spacing.

USWDS (U.S. Web Design System)

Built for: U.S. federal government websites — one of the most accessibility-hardened public systems available.

• Teaches: accessibility as a legal and ethical requirement (WCAG 2.1 AA and Section 508 as non-negotiable gates), color grounded in perceptual contrast research, and package-level imports so projects include only what they need.
• Strengths: public domain (no license restrictions); tested with real assistive technology on real users; strong internationalization.
• Tradeoffs: a conservative release cadence; a Sass-based architecture that feels dated next to CSS-custom-property-native systems; an intentionally utilitarian aesthetic.
• What to steal: the enforcement model — treating accessibility violations as CI failures.

shadcn/ui + Radix UI

Built for: a community React collection using an ownership model, on top of Radix accessibility primitives.

• Teaches: the ownership model (you copy component source into your project — no external package to drift), headless primitives that cleanly separate behavior from styling, and utility classes as a token-delivery mechanism.
• Strengths: you own the code (no version lock); Radix primitives are production-hardened across thousands of teams; a registry model for adding components in the same style.
• Tradeoffs: upstream fixes don't auto-apply (you own the upgrade burden); the default aesthetic is heavily cloned and needs intentional differentiation; system-wide changes are harder once code is pasted everywhere.
• What to steal: Radix's keyboard and ARIA patterns — among the best public implementations of WCAG-compliant interactive components.

SAP Fiori

Built for: SAP enterprise software — ERP, CRM, SCM, and the rest.

• Teaches: role-based UX (the interface adapts to the authenticated user's role), five codified design principles enforced as a review gate, and floorplans (page-level layout templates that constrain information architecture, not just components).
• Strengths: unmatched depth for complex enterprise workflows; coordinated cross-platform release (web, iOS, Android).
• Tradeoffs: practically only useful inside the SAP ecosystem; SAP-specific terminology creates a steep learning curve.
• What to steal: floorplans — page-level templates that constrain information architecture benefit any system.

Build it

The most useful exercise is not importing any of these — it's implementing one component using each system's token philosophy with your own values. Here is the three-tier architecture (primitive → semantic → component) that Carbon, Primer, and Atlassian all use, applied to the fictional Lumen brand.

/* Tier 1: Primitive tokens — raw values, no semantic meaning */
:root {
  --lumen-blue-10: #eff6ff;
  --lumen-blue-50: #3b82f6;
  --lumen-blue-80: #1d4ed8;
  --lumen-gray-10: #f9fafb;
  --lumen-gray-50: #6b7280;
  --lumen-gray-90: #111827;
  --lumen-space-2: 0.5rem;
  --lumen-space-4: 1rem;
  --lumen-radius-md: 8px;
  --lumen-font-base: 1rem;
}
 
/* Tier 2: Semantic tokens — intent, not appearance */
:root {
  --color-action: var(--lumen-blue-50);
  --color-action-hover: var(--lumen-blue-80);
  --color-surface: var(--lumen-gray-10);
  --color-text-primary: var(--lumen-gray-90);
  --space-component-padding: var(--lumen-space-2) var(--lumen-space-4);
  --radius-component: var(--lumen-radius-md);
}
 
/* Tier 3: Component tokens — specific to one component */
:root {
  --button-primary-bg: var(--color-action);
  --button-primary-bg-hover: var(--color-action-hover);
  --button-primary-text: #fff;
  --button-padding: var(--space-component-padding);
  --button-radius: var(--radius-component);
}
 
/* Dark mode: swap semantic tokens only — the component layer never changes */
@media (prefers-color-scheme: dark) {
  :root {
    --color-surface: #111827;
    --color-text-primary: #f9fafb;
    /* Action color stays the same — blue works on dark backgrounds */
  }
}
 
/* The component uses only its own component tokens, never primitives directly */
.btn-primary {
  background: var(--button-primary-bg);
  color: var(--button-primary-text);
  padding: var(--button-padding);
  border-radius: var(--button-radius);
  border: none;
  cursor: pointer;
  font-size: var(--lumen-font-base);
  transition: background 150ms ease;
}
.btn-primary:hover {
  background: var(--button-primary-bg-hover);
}
.btn-primary:focus-visible {
  outline: 2px solid var(--color-action);
  outline-offset: 2px;
}
 
@media (prefers-reduced-motion: reduce) {
  .btn-primary {
    transition: none;
  }
}

interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  variant?: "primary" | "secondary" | "ghost";
  size?: "sm" | "md" | "lg";
  children: React.ReactNode;
}
 
export function Button({ variant = "primary", size = "md", children, ...rest }: ButtonProps) {
  // Styling comes entirely from component tokens in CSS (.btn--primary etc.),
  // so the component file never references a primitive or semantic token.
  return (
    <button className={`btn btn--${variant} btn--${size}`} {...rest}>
      {children}
    </button>
  );
}

Make it yours

• Before adopting a system, answer three questions: do we need dark mode? (If yes, a three-tier token architecture is non-negotiable.) Do we need multi-platform? (If yes, JSON-first tokens are worth the setup cost.) How strict is our accessibility requirement? (If WCAG AA is a hard requirement, choose a system that enforces it in CI.)
• Run a "token audit" on any system you are considering: count primitive, semantic, and component tokens. A high component-to-semantic ratio suggests under-investment in the semantic layer.
• Name semantic tokens by role (what something is for), never by appearance (--color-action, not --color-blue). Appearance-named semantic tokens break dark mode.

Reproduce it with an LLM

Pitfalls & accessibility

• Aesthetic connotations travel with the component. A Fluent button "looks like Microsoft"; a Polaris button "looks like Shopify." If that association conflicts with your brand, you aren't choosing components — you're choosing someone else's identity.

Further reading

• Carbon Design System
• Material Design 3
• Shopify Polaris
• GitHub Primer
• Atlassian Design System
• U.S. Web Design System
• Radix UI · shadcn/ui
• W3C Design Tokens Community Group