Front End Engineering
Design Systems
Learn how design systems work as living infrastructure — the shared visual and behavioural language that keeps large products consistent, fast to build, and possible to maintain across multiple teams.
The $50 Million Button Problem
In 2016, Salesforce counted 67 different shades of blue used across their product. Not 67 intentional blues for 67 intentional purposes — 67 accidents. Each one was an engineer who needed a blue and picked one that looked roughly right. Each one was a designer who shipped a mockup with a slightly different hex value. Accumulated over years across dozens of product teams, the result was a product that felt incoherent even when individual screens looked fine.
Their response was the Lightning Design System — one of the first publicly documented enterprise design systems, open-sourced in 2015. It centralised those blues into a handful of intentional semantic tokens. It defined what each color meant — not just its hex value, but its purpose. And it gave every team a shared vocabulary so that "primary action color" meant the same thing in Tokyo as it did in San Francisco.
The button problem is not about buttons. It's about what happens when a product scales beyond the point where any individual can hold the whole thing in their head. Design systems are the answer — not a design trend, not a documentation project, but a piece of engineering infrastructure as consequential as your build pipeline or your API contract.
What a Design System Actually Is — And What It Isn't
Ask ten engineers what a design system is and you'll get ten answers. A component library. A Figma file. A documentation site. A Storybook. Some will say it's the design team's responsibility. Others will say it's an engineering concern. Everyone is partially right and the partial rightness is the problem — because a design system that exists only as a Figma file isn't a design system, it's a design artifact. And a component library without design decisions encoded in it isn't a design system, it's a collection of UI primitives.
A real design system has three inseparable layers. Remove any one of them and the whole thing degrades into something less useful than its parts.
The Three Inseparable Layers
Named, semantic values for every visual decision: color, spacing, typography, elevation, border radius, animation duration. Not
#7c3aed — but --color-action-primary. Not 16px — but --spacing-4. The token name carries intent; the value carries implementation. Swap the value for a dark mode variant, a high-contrast mode, or a white-label theme — and every component that references the token updates automatically.
Reusable, accessible, thoroughly tested UI components: buttons, inputs, modals, tooltips, data tables, navigation patterns. Each component encapsulates its HTML structure, styling, and interactive behaviour. Consumers don't implement a button — they use the
<Button> component and trust that it handles focus management, keyboard navigation, disabled states, loading states, and ARIA attributes correctly.
Not just "here's how to use the Button component," but "here's why we made these choices, when to use a primary vs secondary vs ghost button, and what the error state should communicate." The guidelines encode the reasoning so that future engineers and designers make consistent decisions without consulting the original authors. A design system without this layer is a black box that teams eventually route around.
Storybook — Where Design Systems Live in Practice
Storybook has become the de-facto standard environment for developing and documenting component libraries. Each component is documented as a set of "stories" — isolated renders of the component in every meaningful state (default, hover, disabled, error, loading). Stories serve as living documentation, visual regression test baselines, and interactive playgrounds simultaneously. Airbnb, IBM, GitHub, Shopify, and Atlassian all publish their design systems through Storybook. The PixelForge Design Systems team ships a public Storybook as part of every design system release — product teams can browse, copy usage examples, and flag issues before changes reach their applications.
Design Tokens — Named Intent, Swappable Values
The concept of a design token sounds simple: give your design decisions a name. The depth of the idea only becomes apparent when you trace what that naming unlocks. A token is not a CSS variable that happens to have a readable name. It's a contract — between the design team that defines the value, the engineering team that implements it, and every platform that renders it.
Tokens exist at multiple levels of abstraction, and understanding the levels is what separates teams that get the most out of their design system from those who end up with a glorified colour palette.
Primitive Tokens (Tier 1)
The raw value palette. Every color in the brand palette, every spacing step, every font size. These tokens have no semantic meaning — they just enumerate what exists.
--purple-600: #7c3aed
--space-4: 16px
--text-sm: 14px
Semantic Tokens (Tier 2)
Named by purpose, pointing to primitives. These are what components consume. They can be swapped for themes without changing the components themselves.
--color-action-primary: var(--purple-600)
--space-component-gap: var(--space-4)
--text-body: var(--text-sm)
Component Tokens (Tier 3)
Scoped to a specific component. Override semantic tokens for component-specific contexts. Allows fine-grained customisation without polluting the global token namespace.
--button-bg: var(--color-action-primary)
--button-radius: var(--radius-md)
--button-font: var(--text-body)
Theme Override (Tier 4)
A theme is a set of token overrides. Dark mode, high-contrast mode, a white-label client theme — all implemented by swapping semantic token values. No component code changes. No duplication. Just different values for the same names.
[data-theme="dark"]
--purple-600: #a78bfa
--color-action-primary: var(--purple-600)
The PixelForge Design Systems team ships dark mode — across all 340 components simultaneously — by overriding 31 semantic tokens in a [data-theme="dark"] CSS block. No component file contains a dark mode conditional. No if (isDarkMode) in any component logic. The token layer handles it entirely. When a new component is built using the semantic tokens, it gets dark mode support automatically — without any additional work from its author.
The industry has standardised token management through Style Dictionary — an open-source tool from Amazon that takes token definitions in JSON or YAML and transforms them into platform-specific outputs: CSS custom properties for web, Swift constants for iOS, XML resources for Android. One token definition, three platform implementations, zero manual synchronisation. Figma's Variables feature now integrates directly with Style Dictionary workflows, which means the design team can update a token value in their design tool and the change propagates to code through an automated pipeline.
Building the Component Library — What Good Looks Like
A component library that ships broken keyboard navigation is not a design system — it's a visual shortcut that ships accessibility debt with every use. A component library where every button variant requires a different prop shape is not a design system — it's an inconsistent API that teams learn to avoid. The quality of a component library is measured not by how many components it has, but by how far you can trust each one.
Shopify's Polaris design system publicly documents what their team calls the "component contract" — the set of guarantees every Polaris component makes to its consumers. Keyboard accessibility. Screen reader announcement. Loading states. Error states. Responsive behaviour. Every component either makes the full contract or it isn't released. This is a higher bar than most teams set, and it's what makes Polaris genuinely useful at Shopify's scale across thousands of internal and third-party developers.
One decision that dramatically affects component library quality is the choice between building from scratch and building on top of a headless component library. Libraries like Radix UI, React Aria, and Headless UI provide fully accessible, unstyled component primitives — they handle every keyboard interaction, every ARIA attribute, every focus trap — and give you complete visual control. The PixelForge Design Systems team uses Radix UI as the foundation for their interactive components (dropdowns, dialogs, tooltips, popovers) and applies their own token-based styles on top. They get WAI-ARIA compliance for free and spend their engineering budget on product-specific behaviour rather than focus management algorithms.
Versioning and Governance — Where Most Design Systems Fail
Building version 1.0 of a design system is the easy part. Every team is aligned, everything is new, and the component library is smaller than the ambitions for it. The hard part begins at version 1.1 — when a product team needs to change a component behaviour that would break three other teams' implementations, and everyone is looking at the design systems team to decide what to do.
Atlassian's design system Atlaskit went through a painful public migration when they needed to change their Button component's prop API in a breaking way. Their solution — which they documented openly — was semantic versioning with a structured deprecation process: deprecation warnings in version N, breaking change in version N+1, automatic codemod to update call sites, and a migration guide with before/after examples. The migration took four months. Without that structure, it would have been indefinitely deferred or silently broken.
Centralised Model
A single design systems team owns all components. Product teams consume but do not contribute. Every change goes through a central review. Quality is high and consistent. But the team becomes a bottleneck — product teams wait days or weeks for new components or variants.
Works well for: early-stage design systems, teams under 50 engineers, organisations where consistency is the primary concern.
Examples: Stripe's internal design system, early Polaris
Federated Model
Product teams can contribute components back to the system through a defined process. The design systems team acts as reviewers and stewards rather than sole authors. Speed increases dramatically — teams ship their own components and the best ones get uplifted into the shared library.
Risk: quality variance. Teams contributing components at different skill levels means the review process must be rigorous to prevent regressions into the shared library.
Examples: Google Material, IBM Carbon, mature Polaris
The PixelForge Design Systems team runs a federated model with a tiered component classification. Tier 1 — Core: owned exclusively by the Design Systems team, changes require RFC and migration plan. Tier 2 — Extended: contributed by product teams through pull request review, Design Systems team signs off on accessibility and token compliance. Tier 3 — Experimental: any team can ship a component under the experimental namespace without full review — but it carries no stability guarantee and can be deprecated without notice.
Semantic Versioning for Design Systems
Design system packages follow semver — MAJOR.MINOR.PATCH. A PATCH release fixes a bug without changing the component API. A MINOR release adds new components or props without breaking existing usage. A MAJOR release contains breaking changes — removed components, changed prop names, redesigned token structures. Product teams should pin to a minor version range (^2.4.0) and treat major version upgrades as planned migration work, not routine dependency bumps. PixelForge publishes a CHANGELOG with a dedicated migration section for every major release.
When the Design System Has to Cross Platforms
Most design system discussions assume a web-only context. But many product organisations ship iOS, Android, and web from the same design system — and this is where the token model proves its real value. A React component cannot run on iOS. But a design token absolutely can. The same semantic token definition that generates CSS custom properties for the web can generate Swift UIColor extensions for iOS and Kotlin Color resources for Android.
Spotify runs a design system — Encore — that spans web, iOS, Android, and their desktop app. Their token pipeline is the connective tissue. When the brand team updated Spotify's green from #1DB954 to #1ED760, the change propagated through Style Dictionary and updated all four platforms in a single pipeline run. No iOS engineer manually found every instance. No Android engineer updated an XML file by hand. The token was the source of truth and the tooling handled the rest.
How a Cross-Platform Token Pipeline Works
Token definitions live in a git repository as structured data.
"color-action-primary": { "value": "#7c3aed", "type": "color" }. Changes are tracked, reviewed in pull requests, and tagged with semantic version bumps.
On every merge to main, a CI job runs Style Dictionary. It reads the token JSON, applies platform-specific transforms (color format conversion, naming convention changes, unit conversions), and emits platform files. One token definition becomes
tokens.css, Tokens.swift, and tokens.xml simultaneously.
The output files are packaged and published to the organisation's npm registry (for web) and Swift Package Manager / Maven (for native). Each platform team pins to a token version and upgrades on their own schedule.
The Figma design file connects to the same token source via the Tokens Studio plugin or Figma's native Variables API. When designers update a color in Figma, the change can be committed back to the JSON source via a GitHub Action. Design and code stay in sync through the same source of truth.
Where Design Systems Actually Fail in the Real World
Most design systems fail not because they were built wrong but because they were treated as a destination rather than a practice. A team ships version 1.0, declares victory, and moves on. Product teams, finding that the design system doesn't cover their specific needs, begin making local exceptions. The exceptions accumulate. Eventually the "design system" refers to a collection of base components that nobody actually uses for anything complex — because every team has their own fork of the Button with their own variants that never made it back into the shared library.
The most honest diagnosis came from Nathan Curtis — who has consulted on design systems at dozens of large organisations — who observed that design system adoption drops when product teams feel the system slows them down more than it helps them. That moment usually arrives when the system covers 70% of use cases beautifully and 30% not at all, and product teams find it faster to write their own components than to wait for the design system to support their needs.
The only metric that matters for a design system: adoption rate. Not how many components it has. Not how beautiful the Storybook is. Not how detailed the documentation. If product teams are not using the design system for at least 80% of their UI surface area, it has failed — regardless of how much engineering went into it. The PixelForge Design Systems team tracks adoption weekly: what percentage of UI elements in each product team's last three pull requests used design system components? That number drives their roadmap. When a team's adoption drops below 70%, the Design Systems team schedules a conversation — not to enforce compliance, but to find out what the system is missing.
The "Not Invented Here" Tax
Every bespoke component a product team builds outside the design system is a component they now own indefinitely. It needs its own accessibility audit. Its own dark mode support. Its own responsive behaviour. Its own documentation. Its own tests. The design system's value is not just the components it provides — it's the maintenance burden it removes from every team that adopts it. A product team that builds 20 custom components instead of using 20 design system components has taken on, conservatively, 40–60 hours of additional maintenance work per year per component. At scale, those hours compound into months of engineering time that could have been spent shipping product.
The PixelForge Design Systems team runs a quarterly "component audit" — a systematic review of every bespoke component built outside the system in the last quarter, across all five product squads. Components that appear in two or more teams get nominated for uplift into the shared library. Components with poor accessibility scores get flagged for remediation or replacement. The audit takes two days and consistently surfaces 6–10 components ready for uplift — which means 6–10 things that will be maintained once instead of four times going forward.
Quiz
1. The PixelForge Design Systems team needs to implement dark mode across all 340 components without changing a single component file. Which layer of the token system makes this possible?
2. PixelForge's Design Systems team is building a new Dropdown Menu component. They need full keyboard navigation, correct ARIA roles, and focus trapping. Which approach gets them to compliance fastest without sacrificing visual control?
3. PixelForge's leadership asks the Design Systems team to prove their system is providing value. The team has a beautiful Storybook with 120 documented components. Which metric best indicates whether the system is actually succeeding?