Somewhere in most products there are two buttons that should match and don’t. One has a 6px radius, the other 4px, and nobody remembers which one was intended.
Settling that kind of argument is the job of a design system, a governed set of reusable components and design tokens, plus the usage guidelines that explain both. It gives design and engineering teams one source of truth for building an interface.
Product teams at IBM and Shopify publish theirs, and Atlassian does too, with the code and design assets in one place and the written rules right beside them.
Most definitions skip upkeep, which is odd, because upkeep decides whether the system stays usable. In zeroheight’s Design Systems Report 2026, a single person maintains 16% of the systems surveyed. The shared source stays accurate only while someone owns it.
What Is a Design System?
In practice it means nobody rebuilds the same button, form field, or modal twice. Teams pull the approved version, follow the usage rules, and ship.
GOV.UK is a good case. Before its June 2018 launch, patterns and code lived in the Service Manual, GOV.UK Elements, the Prototype Kit, GOV.UK Template, the Frontend Toolkit, and Dropbox Paper (Government Digital Service blog, 2018).
The system that replaced them put everything in one place and added a community backlog where teams can propose changes.
People mix it up with things that look similar but aren’t the same. A UI kit holds visual elements but no usage rules, and a style guide documents appearance without any reusable code. A Figma library with no matching code behind it is just a library.
Designers work from the shared library and frontend developers install the matching code. Content designers get the same voice and tone rules.
That keeps the user interface consistent across products, and nobody needs a review meeting to approve a button.
What Does a Design System Include?
Foundations and design tokens sit at the bottom. Components get built from them, patterns combine components, and documentation explains everything above.
Foundations and Principles
Every component inherits its color, typography, spacing, grid, iconography, and motion from the foundations.
Principles sit above them and record why a decision was made, so a new designer can settle an edge case without asking anyone.
Accessibility belongs at this level, not in a late audit. The U.S. Web Design System aims for WCAG 2.1 AA even though WCAG 2.0 AA is the legal baseline, and it works toward WCAG 2.2 criteria, released in October 2023 (USWDS accessibility documentation).
Components and Patterns
Buttons, form inputs, modals, navigation, and tables all count as components, and every one needs its states defined, from default and hover to focus, disabled, and error. States are the part people forget. Hover gets designed, focus often doesn’t.
A separate guide to the components inside a design system goes deeper on each type.
Patterns combine components to solve a task. GOV.UK ships patterns for asking users for an address and for checking whether a service suits them, per its launch post.
Brad Frost’s method gives the component layer a hierarchy, and a primer on atomic design covers it in full.
At the bottom are atoms, such as a label, an input, or a button. Put a few together and you get a molecule like a search form, and molecules combine into an organism like a site header.
Organisms then go into a template, which turns into a page once real content is filled in.
The hierarchy organizes the library. It does not set a build order, and Frost’s own write-up has teams looping back from pages to adjust the layers beneath them.
Documentation and Usage Guidelines
A set of components only becomes usable once someone documents it.
Each component page should show its anatomy, do and don’t rules, and accessibility notes. Code examples belong there too, along with guidance on when to pick it over a similar component.
Thin documentation is how teams end up rebuilding components the system already has.
Design Tokens as the Layer Between Design and Code
Color, type, spacing, and elevation values get a name once in a design system, then get referenced by that name everywhere, in design files and in code. Those named values are design tokens.
Google’s Material 3 documentation says the same tokens drive designs, tools, and code.
Atlassian ships its tokens as CSS custom properties, such as var(–ds-surface-raised) and var(–ds-space-100) (Atlassian developer documentation, 2024). Change a value once and every product picks it up, with no find and replace across hard-coded values.
Systems layer tokens by how specific they are. Material 3 calls the tiers reference, system, and component, while other teams say global, alias, and component.
The global tier holds the raw value, one specific blue for instance. Alias tokens point to a purpose, like color-text-primary, and component tokens tie a value to a single element, as in button-background-hover.
The Design Tokens Community Group published the first stable version of its specification, 2025.10, on October 28, 2025 (W3C Design Tokens Community Group).
JSON is the syntax. The specification supplies the semantics, with fields such as $value, $type, and $description.
On the module side, the Format Module covers how tokens are written, and the Color Module handles Display P3, Oklch, and the CSS Color Module 4 spaces. Theming goes through the Resolver Module.
Style Dictionary, Amazon’s open source build system, turns one set of token files into CSS, SCSS, iOS, and Android output. Version 4 onward reads the DTCG format and detects it automatically (Style Dictionary documentation).
Atlassian also retires tokens on a schedule. A token moves from active to deprecated and then deleted, and the cut-off dates are announced in advance.
Naming is the dull part of tokens, and it’s where most of the trouble starts. Tokens exported without a shared naming convention drift apart across platforms, and a designer’s color-primary can turn into a developer’s brandBlue. At that point the single source of truth is gone.
Design System vs Style Guide, Pattern Library, and Component Library
The other three are all parts of a design system, and each one covers a single slice of it.
| Asset | What it holds | Main audience | Ships code |
|---|---|---|---|
| Design system | Principles, tokens, components, patterns, documentation, governance | Whole organization | Yes |
| Style guide | Colors, type, spacing, iconography, brand voice | Designers, marketers, content writers | No |
| Pattern library | Layouts, page templates, interaction patterns | Designers, developers | Sometimes |
| Component library | Coded buttons, inputs, modals, cards | Developers, designers | Yes |
| UI kit | Visual elements in a design tool | Designers | No |
If the style guide is the asset your team already has, this breakdown of how a design system differs from a style guide covers the gap in detail.
Standalone libraries such as MUI and React-Bootstrap supply coded components. Unless a team adds principles and governance of its own, along with usage rules, they stay component libraries, not design systems.
With only a style guide, consistency depends on people actually reading it. Teams that own just a component library have code but no rules for using it, which tends to go badly.
UXPin’s 2026 comparison notes that many small teams start with a component library and a style guide, then grow into a full design system as the organization scales.
Design System Examples: Carbon, Polaris, GOV.UK, and More
The public systems worth studying ship components and code alongside the guidance, and all of it gets updated together.
IBM funds and builds Carbon, which is open source and based on the IBM Design Language. It comes with working code, design tools and resources, human interface guidelines, and a community of contributors (Carbon Design System).
Shopify’s developer documentation describes Polaris as design guidance on accessibility, color, typography, spacing, naming, and action language, plus components packaged through code and tokens exposed as named CSS values.
The code layer has a lifecycle too. As of October 2026, Polaris React is marked deprecated on its own site, which points developers to Polaris Web Components.
Atlassian’s system exposes tokens and primitives alongside React components, plus a Figma plugin that applies tokens in design files (Atlassian Design System documentation).
The two government systems have different owners. A team at the Government Digital Service maintains the GOV.UK Design System, which covers styles, components, and patterns. The U.S. Web Design System was created in 2015 by 18F and the U.S. Digital Service, and it’s now a product of the General Services Administration.
Google’s Material 3 organizes its guidance into foundations, styles, and components, and publishes it under Apache 2.0 or CC BY 4.0 licenses (Material Design).
Plenty of others are worth a look, and a longer list of the best design systems covers more of them.
Design System Governance: Centralized, Federated, and Hybrid Models
Who builds the components, who approves changes, and how long product teams wait all come down to the team model, whether centralized, federated, or hybrid.
Among in-house respondents in Sparkbox’s 2021 Design Systems Survey, 46% ran a centralized team, 26% were solitary, and 24% were federated.
The labels are not settled. Nathan Curtis, who named the models in 2015, lists solitary, centralized, and federated, while zeroheight’s governance guide drops solitary and adds hybrid.
In a hybrid model, a federated committee sets direction and a central team builds the libraries and keeps the documentation current.
| Model | Strengths | Weak points |
|---|---|---|
| Centralized | One owner, consistent decisions, no bias toward a single product | Product teams wait for new parts, scales poorly across very large portfolios |
| Federated | Contributors know real product needs, work is shared | Uneven time commitment, slower decisions, blurred design direction |
| Hybrid | Committee steers, core team ships | Needs a written contribution process and clear decision rights |
Strengths and weak points follow Curtis’s 2015 write-up and zeroheight’s guide.
Salesforce blends the first two for its Lightning Design System. A small central team acts as librarian, distributor, and facilitator, while federated contributors across product teams keep the system accurate and current, according to lead designer Jina Bolton’s 2015 account.
Per zeroheight, centralized suits newer organizations and smaller product portfolios. Once the central team becomes the wait line, it’s time to move toward federated.
Whichever model wins, name one owner for releases and deprecations. Without that, the system has contributors and no maintainer.
What Do Published Figures Say About Design System Returns?
The published studies put task completion 34% to 47% faster with a design system. Every one of those figures measures task time, though, not what it costs to build and maintain the system.
Sparkbox had eight developers code a Figma-designed contact form from scratch, then again with Carbon. A simple form came together 47% faster with IBM’s Carbon than from scratch. Across the 8 developers, the median time was 4.2 hours from scratch and 2 hours with Carbon, and the Carbon timings included the time developers spent learning the system.
The agency itself calls it a small study of a handful of developers.
Figma’s data science team reported designers finishing tasks 34% faster when they had a design system on the task. Those designers completed two tasks and had design system access on only one of them, and they chose their own stopping point on each.
Read together, the two studies put the per-task gain between roughly a third and a half. They test different people on different tasks, so the numbers cannot be averaged into one organization-wide return.
Some compilations, Netguru’s among them, credit the 34% figure to “Slack (2019).” That’s the surname of Clancy Slack, the Figma data scientist who wrote the December 2019 post, not the messaging company. Figma’s blog reports it from its own data science team, so cite the primary page.
Smashing Magazine’s 2022 ROI formula weighs what a system gains over time against what building and maintaining it costs.
Skip any ROI percentage that shows no cost side. Headline figures in the hundreds of percent circulate in agency posts without a retrievable primary study, so none appear here.
When Does a Design System Not Pay Off?
Small teams that already communicate well often don’t need one. Sparkbox’s Bryan Braun argues many have no consistency or communication problem to solve, and a dedicated system team is more cost center than profit center.
Products still proving fit are a poor match too, since components that change every sprint cost more to keep current than they save.
Then there’s staffing. zeroheight’s Design Systems Report 2026 found 61% of teams have five or fewer people, and only 23% agree they have adequate resources. A system the organization can’t staff after launch goes stale no matter how good the first release was.
Sparkbox’s “Design Systems That Get Used,” by Rob Harr, states the sizing risk plainly. A system built to be supported by a team of six overwhelms a team of two.
Advice on startups splits. A Design Systems Collective essay says build from day one, while Sparkbox says many small teams do not need one.
Thoughtworks and Rangle land in between. Both recommend a small start, and Rangle puts tokens first.
Rangle, a software consultancy, reports seeing adoption as the most common hurdle. Teams rebuild components when the system fits badly or is poorly documented.
If the answer is not yet, a short set of design system best practices still applies. Share color and type values, and settle on one naming convention.
How to Build a Design System, Step by Step
Work from what the product already has, not from a blank canvas.
- Audit the interface: count the button styles, shades of blue, and card layouts that already ship
- Rank components by reuse and build the most repeated first: buttons, form inputs, navigation
- Define tokens for color, type, and spacing before any component binds to a value
- Build each component in code and in the design library, with all its states
- Document every component with anatomy, usage rules, and code examples
- Release in small increments and open a contribution path
Rangle recommends an end-to-end MVP that runs from design to code the simplest way possible. Tokens go first, then the next highest-value component.
For the code layer, pick the framework your products already run on. Web Components, built from custom elements, shadow DOM, and HTML templates (MDN), are the framework-neutral option.
Smashing Magazine’s 2025 comparison notes integration can need extra configuration or polyfills, and some developers dispute the framework-agnostic claim.
Storybook, a frontend workshop for building UI components and pages in isolation, covers development, testing, and documentation (Storybook documentation). Its a11y addon checks components for accessibility inside the same interface.
The design library mirrors the code. Variables map best to tokens because each holds a single raw value or references another variable, per GitHub’s Primer documentation, and a walkthrough on creating a design system in Figma covers variants and component properties.
Documentation needs a home of its own. zeroheight is a dedicated documentation platform that connects to Figma and Storybook, and a guide to design system documentation covers what each component page should hold.
Importing every variant the audit found, instead of consolidating to a few, is an easy way to go wrong. So is finishing every component first and shipping the batch after months of silence, which removes feedback loops and leads to low adoption (Rangle).
Design System FAQ
Is system design the same as a design system?
No. System design deals with the architecture of software, hardware, networks, and data management, while a design system governs the interface itself, meaning components, tokens, and usage rules.
Who works on a design system team?
Mostly designers and developers. Sparkbox’s 2021 Design Systems Survey found design on 94% of teams and development on 87%, with user experience on 71% and management on 41%.
Federated teams draw members from product teams, so their time is split.
How often should a design system release a new version?
The sources set no standard cadence. They agree on small, numbered releases with written release notes, and on publishing deprecation dates before a breaking change ships.
Does a design system have to be open source?
No. IBM’s Carbon is open source, while the Polaris source on GitHub carries a custom license that limits use to applications that integrate or interoperate with Shopify.
How do you measure design system adoption?
Track the share of each product’s interface that comes from the system. Figma’s library analytics report adoption of components, variables, and styles, and Sparkbox’s 2021 survey linked a larger sourced share with higher perceived success.
Keeping a Design System Current After Launch
A design system stays current only while a funded team owns its releases, so the upkeep budget comes before the first component ships.
zeroheight’s Design Systems Report 2026 found that 56% of teams name staffing as their biggest challenge, ahead of buy-in and tooling.
The task-time studies measure savings in the product teams that consume the system, while that staffing gap sits in the team that maintains it. The upkeep budget should therefore draw on the product teams that collect the savings.
Name one owner for releases and publish a release and deprecation schedule. Fund maintenance before adding components.
Ownership comes first because a schedule with no owner lapses. New components added to an unfunded system only raise the maintenance load.
For the build itself, a Figma design system tutorial shows the library setup in practice.
Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.
- Figma Keyboard Shortcuts That Will 10x Your Speed - October 25, 2026
- What is Backend in Web Development? - September 13, 2026
- What is Frontend Development? - September 11, 2026
