"We need a design system."
In 2026, this sentence appears in product team conversations with a frequency that suggests universal understanding of what it means. It doesn't. I've heard "we need a design system" mean five different things from five different teams in the same week.
Sometimes it means: we want a Figma component library.
Sometimes it means: we need consistent UI across our products.
Sometimes it means: we want a CSS framework.
Sometimes it means: our developer and designer are arguing about button specs and we need someone to write them down.
Sometimes it means: we saw that Stripe has a design system and we want to be like Stripe.
All of these are legitimate starting points. None of them are the same thing.
This guide explains what a design system actually is — at every level of sophistication — so you can have informed conversations about what your team actually needs, and choose appropriately between building, buying, and adapting.
What a Design System Actually Is
A design system is a collection of reusable decisions — encoded in tools, files, and documentation — that enables a team to build a consistent product experience at scale.
That definition has three important parts:
Reusable decisions: A design system captures decisions that would otherwise be made repeatedly and inconsistently. "What shade of blue is our primary button?" is a decision that will be made hundreds of times across hundreds of screens and dozens of developers. A design system makes it once and distributes the answer everywhere.
Encoded in tools, files, and documentation: Decisions written on a whiteboard are not a design system. Decisions encoded in Figma components, CSS variables, code components, and documented guidelines are a design system — because they're accessible, usable, and enforceable.
At scale: A design system is valuable in proportion to the scale at which it operates. One designer building one product doesn't need a design system — the designer is the system. Ten designers building one product need a design system. One designer building one product for ten developers needs a design system.
The Layers of a Design System
Design systems have layers, and most conversations conflate them. Understanding the layers helps you understand what you actually need to build.
Layer 1: Design Tokens
Design tokens are the atomic building blocks of a design system — the specific values that all other elements are built from.
Color tokens: --color-primary-600: #2563EB — your brand blue, as a semantic name rather than a raw hex value.
Spacing tokens: --space-4: 1rem — your spacing unit, not a pixel value that gets repeated 500 times.
Typography tokens: --font-size-body: 0.9375rem — your body text size, named semantically.
Radius tokens: --radius-card: 10px — your card border radius, named so it can change globally.
The value of tokens is the semantic naming. When you say background: var(--color-surface) instead of background: #ffffff, changing the design to support dark mode becomes changing the value of --color-surface in one place rather than finding and replacing every instance of #ffffff across thousands of CSS files.
In Figma: tokens are implemented as Variables (since Figma's 2023 Variables feature). In code: as CSS custom properties, JavaScript constants, or design token JSON files processed by tools like Style Dictionary.
Layer 2: Component Library
Components are reusable UI elements built from tokens. A button component encodes: the background color (from the primary color token), the text style (from the typography tokens), the padding (from the spacing tokens), the border radius (from the radius tokens), and the hover/active/disabled states.
In Figma: this is your Figma component library — the frames with master components that you detach and customize.
In code: this is your React/Vue/Svelte component library — the JavaScript files that render UI elements based on props.
The connection between these two is the design-code gap. A design system where the Figma components and the code components don't correspond to the same things is a design system that will produce inconsistency. Bridging this gap — through naming conventions, documentation, or shared token files — is some of the hardest and most valuable work in design systems.
Layer 3: Patterns
Patterns are repeating solutions to common design problems. How do you handle empty states? What does a loading skeleton look like? How do you structure a data table with filtering? How do you handle error states on forms?
These aren't components — they're compositions of components. But they're repeating compositions that benefit from documentation and standardization.
Layer 4: Documentation
Documentation explains why decisions were made, not just what they are. A button style guide that says "primary buttons are blue" is a style guide. A design system that says "primary buttons are blue because blue is our interactive color, and we use it exclusively for primary calls to action to maintain the association between blue and 'do something'" is a design system.
The reasoning matters because it helps future designers make correct decisions in situations the documentation didn't anticipate.
Build vs. Buy vs. Adapt
Most teams have three realistic options when they need a design system. Choosing between them incorrectly is expensive.
Build From Scratch
When it makes sense:
- Your product has very specific visual requirements that no existing system can accommodate
- You have dedicated design systems resources (at least 1 full-time person)
- Your team is large enough (10+ designers, 50+ developers) that the investment is proportionate
When it doesn't make sense:
- You're a small team with other priorities
- You don't have the timeline (building a quality design system takes 6-12 months minimum)
- Your requirements can be met by adapting an existing system
Adapt an Existing System
The right choice for: Most teams. Take Untitled UI, Material Design 3, or another high-quality base system and adapt it — change the brand colors, adjust the typography, modify components to match your specific requirements.
What "adapt" means: You're not building from scratch. You're making a series of decisions about what to change, what to keep, and what to add. This is 80% less work than building from scratch and produces a result that most teams can't distinguish from a custom system.
Use a System As-Is
When it makes sense: Internal tools, early-stage products, MVPs, anything where consistency matters more than distinctiveness. Using Untitled UI, shadcn/ui, or Material Design 3 without modification is a completely valid choice if the default aesthetic matches your needs.
The honest trade-off: Your product will look like it uses that system, which will be recognizable to designers who know the system. This matters less to users than designers think.
The Design Systems That Save You 6 Months
Rather than building from scratch, these are the foundation systems worth starting from:
For SaaS products: Untitled UI provides the most complete free foundation — 1,000+ components, full Variables implementation, comprehensive token structure.
For React applications: shadcn/ui provides design-code alignment that no Figma kit achieves — because the code components and design components are designed together.
For Google ecosystem products: Material Design 3 provides the most sophisticated theming system available in any free design system.
For enterprise B2B: Carbon Design System (IBM) or Primer (GitHub) provide battle-tested patterns for complex information-dense interfaces.
Browse All Design System Resources on Mantlr →
The Design System Mistakes That Cost the Most
Building for the wrong audience: A design system serves the team that uses it, not the team that built it. If your developers don't know how to use it, it fails, regardless of its quality. Involve developers from day one.
Prioritizing completeness over adoption: A design system with 20 components that every designer and developer uses is more valuable than a system with 200 components that nobody uses. Start small. Ship something usable. Expand based on actual usage patterns.
Skipping the tokens: Teams that build a component library without first establishing design tokens create a system that's hard to theme, hard to maintain, and impossible to scale. Tokens first, always.
Treating it as finished: A design system is a living product, not a deliverable. It needs ongoing maintenance, governance decisions, and updates as the product evolves. Teams that treat it as "done" end up with an outdated system that designers route around rather than use.
Where to Learn More About Design Systems
The field of design systems is well-documented by practitioners who've built real systems at real companies.
Nathan Curtis's Medium posts cover design systems at the level of detail that only years of practice produces. Required reading for anyone building seriously.
The Design Systems podcast interviews practitioners from Airbnb, Shopify, Google, and others. Real problems, real solutions.
Supernova.io's resource library documents design token workflows and design-to-code pipelines specifically.
Mantlr is where you'll find the best free design systems resources — UI kits, component libraries, and design tools — curated and organized by category.