techlist.io
KREN
figma

The Making of the Figma Pattern Library | Figma Blog (opens in new tab)

figmadesign-systemsaccessibilitydesign-tokenscssrest-apiui-componentsdark-mode

Figma rebuilt its internal design system during the UI3 redesign after years of growth had produced inconsistent components, detached instances, and a fragmented workflow. The resulting Figma Pattern Library (FPL) was created through close designer-engineer collaboration and uses variables, APIs, and shared standards to keep design intent aligned with shipped code. Its goal is to provide both a reliable source of truth and a flexible foundation for building consistent, accessible products across Figma’s product suite.

Why Figma rebuilt its design system

  • Figma’s internal system had become increasingly fragmented as the company and product portfolio expanded.
  • Components that were intended to be identical had accumulated subtle but important differences.
  • Detached component instances made consistency difficult to maintain.
  • The upcoming UI3 rollout made these problems impossible to ignore.
  • The team needed a foundation that could support consistent, efficient development across all Figma products.

A paired design-and-engineering approach

  • A five-person team of designers and engineers led the rebuild.
  • The team modeled its workflow on pair programming:
    • One discipline would actively build.
    • The other would review and provide immediate feedback.
  • This collaboration helped bridge the gap between design intent and technical implementation.
  • The system was designed to be both:
    • A source of truth for shared UI decisions.
    • A springboard for future product development.
  • The effort resulted in the new Figma Pattern Library, or FPL.

Using variables as a shared language

  • The previous system relied on Figma styles for designers and a separate Google Sheet for engineers’ color tokens.
  • Because the spreadsheet often lagged behind product changes, designs and production code diverged.
  • FPL replaced this disconnected process with Figma variables and the Figma REST API.
  • Typography variables were introduced and aliased through existing typography styles.
  • Color styles were migrated to color variables as a centralized source of truth.
  • CSS definitions were added to color variables so Dev Mode could display the correct variable names during inspection.

Primitive and semantic color systems

  • FPL organized colors into two main variable collections:
    • Primitive variables: Color ramps organized by hue and numbered from 100 to 1000.
    • Semantic variables: Contextual names based on Figma’s dark-mode schema.
  • Semantic variables support multiple themes and products, including:
    • Light and dark modes.
    • Figma Design.
    • FigJam.
    • Slides.
    • Dev Mode.
  • Semantic variables alias primitive variables, allowing colors to be changed across themes and products without manually updating every component.
  • This structure enables shared components to adapt to different contexts while preserving visual consistency.

The practical lesson is that a scalable design system requires more than a component library: it needs shared ownership, synchronized design and engineering tokens, and variable-based foundations that can support multiple products and themes.