What Is a Design System? A Plain-English Guide for Founders

A design system is the shared set of decisions, reusable parts and rules a team uses to design and build a product: design tokens for colour, type and spacing, components such as buttons and forms, patterns for common tasks, and the documentation that says when to use what. It is what lets five people, or fifty, ship screens that look and behave like one product.

This guide is for founders and product teams who have to decide what to do with that definition: how a design system differs from a UI kit or a style guide, what design tokens are and why the new DTCG format matters, when a startup needs one, what it costs in effort, how to start small and how to make it readable by AI tools. At the end, six public design systems and the lesson each one teaches.

A word on bias: I design products and design systems for SaaS and AI teams, and I think most startups need a small system earlier than they think, and a big one much later than they fear.

What is a design system?

A definition you can repeat in a meeting

Nielsen Norman Group defines a design system as a set of standards for managing design at scale, reducing redundancy and creating a shared language and visual consistency across channels. Figma puts it more simply: building blocks and standards that keep the look and feel of products consistent.

The version I give founders: a design system answers "how do we do this here?" once, so nobody has to answer it again on every screen. It is a product that serves other products, and its users are your designers, engineers, product managers and, more and more, the AI tools that generate code and screens for them.

What a design system includes

Most design systems have five layers:

• Foundations and design tokens. Colour, typography, spacing, radius, elevation and motion, stored as named values that both design files and code use.
• Components. Buttons, inputs, selects, modals, tables and navigation, each with its variants and states (hover, focus, disabled, error, loading), designed in Figma and implemented in code.
• Patterns. Combinations of components that solve recurring problems: a form with validation, an empty state, an onboarding step, filtering a list, confirming a destructive action.
• Guidelines and documentation. When to use each piece and when not to, accessibility rules, content and tone guidance, examples of what to do and what to avoid.
• Ownership and process. Who decides, how changes are proposed and how new versions are released.

The last two layers separate a system from a library of parts: components with no rules and no owner form a UI kit, and they drift.

Design system vs UI kit vs style guide vs component library

These terms get mixed up all the time, even by designers:

In short, a design system contains a style guide, a component library and patterns, plus the rules and people that keep design and code in sync. A "design system" that only exists in Figma is a branded UI kit: useful, but the code will drift away from it.

Design tokens: the part that makes it a system

What a design token is

A design token is a named design decision: a name paired with a value. Material Design 3 calls tokens the building blocks of all UI elements, used in designs, tools and code alike. Atlassian describes them as name and value pairings that represent small, repeatable design decisions.

Instead of a hex value copied into every file, a danger button uses a token such as color.background.danger. Change the value once and both the Figma library and the product follow. The same mechanism powers dark mode: a theme is another set of values for the same token names, which is how Atlassian handles light, dark and high-contrast modes.

Primitive, semantic and component tokens

Most mature systems organise tokens in three tiers:

• Primitive tokens hold raw values with no meaning attached: a blue from your palette, a spacing step, a font family.
• Semantic tokens say what a value is for, such as default text colour, danger background or card padding. They point to primitives.
• Component tokens apply to one component, such as the background of a primary button. They point to semantic tokens.

Material Design 3 calls these tiers reference, system and component tokens, and prefixes them md.ref, md.sys and md.comp. Its token md.ref.palette.secondary90 holds #E8DEF8, while md.comp.fab.primary.container.color sets the container colour of a floating action button. Atlassian names its tokens by foundation, property and modifier (color.icon.success) and gives a rule worth printing: do not pick a token just because the colour appears to match, because it can break in another theme.

For a startup, primitives plus semantic tokens are enough to begin with. Component tokens earn their place when you support several themes, brands or platforms. I cover tiers and naming in more depth in my practical guide to design tokens.

The DTCG format: one token file every tool can read

Tools used to store tokens in their own formats. The Design Tokens Community Group (DTCG), a W3C community group of design system teams and tool makers, now publishes a shared file format. Its Design Tokens Format Module 2025.10, published on 28 October 2025, is marked stable and intended for implementation. To be precise, the specification states that it is not a W3C Standard and is not on the W3C Standards Track: it is a community group report. As of October 2026, the group lists Adobe, Figma, Framer, Penpot, Sketch, Style Dictionary, Tokens Studio, Supernova, Terrazzo and zeroheight among its adopters and participants.

What the format standardises:

• JSON files with the .tokens or .tokens.json extension, and their own media type (application/design-tokens+json).
• Token properties: each token has a $value, and usually a $type and a $description.
• Types: color, dimension (a number with px or rem), fontFamily, fontWeight, duration, cubicBezier and number, plus composite types such as typography, shadow, border, transition and gradient.
• Aliases: a token can reference another token by its path in curly braces, which is how a semantic token points to a primitive.
• Colours described by a colour space (sRGB, OKLCH and others), components and an optional hex fallback, in a separate Color Module.

Here is a small token set as it would be structured in a DTCG file:

Why should a founder care? Tokens in a standard format are portable: change design tool or front-end framework, and your decisions travel with you. They are also machine-readable, which matters for AI (see below).

Good to know: Nobody on your team has to write token JSON by hand. Designers usually manage tokens as variables in Figma, with modes for light and dark themes, and export them through a plugin or Figma's Variables REST API. Engineers then turn them into CSS variables or platform code with a translation tool such as Style Dictionary or Terrazzo.

Does your startup need a design system?

The real question is how much system, and when.

Signs you need one now

• More than one person designs or builds UI, or engineers ship screens without a designer in the loop.
• The same component exists in several versions: three button styles, two date pickers, four shades of grey for borders.
• Dark mode, white-label, a second brand or a second platform is on the roadmap. Without tokens, each one multiplies the work.
• Your marketing site and your product look like two companies. The same tokens can drive both. If your site runs on a builder, I compare how each platform holds a design system in Webflow vs Framer.
• AI coding tools generate UI that ignores your style: they have nothing to follow.

When it is too early

• Before product-market fit, when the product changes shape every few weeks. A full system would freeze decisions you will throw away: start with a token file and a few components, or adopt an existing library.
• One designer and one front-end engineer who sit together. A shared Figma library and a tokens file are enough for now.
• An old product that will not change. Material Design's own guidance says tokens help less when an app with hard-coded values is unlikely to change in the next year or two.

Nielsen Norman Group sums it up well: design systems pay off when a company foresees years of future, repeatable design work.

What a design system costs in effort

The honest answer: the first version is the cheap part. Keeping it alive is the real cost.

Nielsen Norman Group describes three routes, and notes that using an existing design system is the lowest-cost and fastest approach:

At enterprise scale, NN/g recommends a dedicated team of at least an interaction designer, a visual designer and a developer. A startup needs one design owner, one engineering champion, and a little time in every sprint for upkeep: reviewing requests, fixing drift, updating documentation.

A useful first version for a SaaS product usually covers:

• Tokens for colour (light and dark if you need both), type scale, spacing, radius and elevation.
• The components behind your most-used screens: buttons, inputs, selects, checkboxes, modals, toasts, tables, navigation and empty states, with all their states.
• One short documentation page per component, and a changelog.

The hidden costs are migrating existing screens, getting the team to use the system rather than work around it, and saying no to one-off components. If you want a sense of budget for a design system sprint with me, see my price ranges.

How to create a design system: a startup-sized plan

You do not need a dedicated team to start. This is the order I follow:

1. Audit what you already have. Screenshot every button, input, colour and text style in production. The duplicates are your backlog, and your business case.
2. Decide to adopt, adapt or build. Be honest about your brand needs and your engineering time.
3. Define the foundations as tokens. Colour primitives, semantic roles (text, background, border, action, feedback), a type scale, a spacing scale, radius and elevation. Name them by purpose, and store them in the DTCG format so design and code share one source.
4. Design the components behind your core flow first. Not the full catalogue: whatever your most-used screens need, with every state, including empty, loading, error, disabled and focus. The atomic design method gives the team a shared vocabulary for how small parts combine into screens.
5. Build accessibility in at the source. Check contrast at token level, make focus states visible and design components for keyboard use. A fix in the system fixes every screen.
6. Connect design and code. Use the same names in Figma and in the codebase, transform tokens automatically, and map each design component to its coded counterpart.
7. Write the minimum documentation. For each component: what it is for, when not to use it, and a do and a don't. Short beats complete. I cover structure and tools in how to document a design system.
8. Set ownership and a release rhythm. Who approves new components, how requests come in, and a version number with a changelog.
9. Migrate gradually. New screens use the system from day one; old screens move when someone touches them.

This is the plan I run as a freelance product designer for SaaS and AI teams: I design the tokens, components and documentation in Figma and work with your engineers so the coded version matches. My own products, Plume SEO and Bidouille OS, run on the same kind of token-based system.

AI-ready design systems

AI tools now generate interface code and even design files. Without context, they produce generic UI. With your design system as context, they can produce your UI. As of October 2026, several public systems already work this way:

• IBM Carbon offers Carbon MCP, which connects AI applications to its components, tokens, icons, guidance and code.
• Atlassian gives coding agents its design system context (component APIs, guidance, tokens, icons, accessibility rules and lint rules) through an agent skill, an MCP server and a command-line tool, all generated from structured content kept next to the code.
• Figma's MCP server passes design context such as variables, components and layout to AI agents, and Code Connect lets generated code reuse your real components instead of inventing new ones.

You do not need your own MCP server to benefit. What makes a system readable by AI also makes it readable by a new hire:

• Semantic names. color.text.danger tells an agent what it is for; a name like red-500 does not.
• Tokens in a standard format. DTCG JSON is easy for tools and models to parse.
• Short, structured documentation. Rules written as do and don't with a reason, in a predictable structure, rather than a long PDF.
• Rules enforced by code. Lint rules and tests survive longer than guidelines nobody opens.

That is the strongest argument for getting tokens and naming right early: the same work helps your designers, your engineers and their AI tools.

Design system examples worth studying

Galleries such as component.gallery index many public design systems. These six are worth your time, each for a different lesson (all checked in October 2026). For a longer list, see more public design systems to learn from.

Material Design 3 (Google)

Google's design system lists the tokens behind each component in its specs, grouped by state and by element.

What to learn: token architecture. Three classes of tokens and names that run from the most general to the most specific. Even if you never use Material's look, copy its naming logic.

Carbon (IBM)

IBM describes Carbon as its enterprise-ready, open-source design system: foundations, components, patterns, data visualization guidance and Carbon for AI.

What to learn: how to design for dense B2B products. Its patterns (empty states, filtering, status indicators, forms) and its chart guidance are directly useful for SaaS dashboards.

Polaris (Shopify)

As of October 2026, Shopify presents Polaris as its unified UI framework built on web components, used across every surface where apps appear: the admin, checkout, customer accounts and point of sale, each with its own subset of components.

What to learn: a design system can be part of your platform. Third-party developers build apps that feel native because the components are handed to them, which matters if you have integrations or partners.

Atlassian Design System

Atlassian is rolling out shared tokens, components and themes across its apps, and documents how to read its token names.

What to learn: theming done right. Light, dark and high-contrast modes are just different values for the same semantic tokens, which is why you choose tokens by meaning and never by colour.

GOV.UK Design System

The UK government's system offers styles, components and patterns so services stay consistent with GOV.UK and learn from the research of other service teams. Its patterns are organised around user tasks, such as asking users for dates or addresses, or helping them check their answers.

What to learn: task-based patterns and honesty about maturity. Components carry lifecycle statuses: GOV.UK Frontend v6.5.0, released on 27 August 2026, added Feedback and Language navigation components as "Trial" before they reach "Stable".

GC Design System (Government of Canada)

The GC Design System is an official, production-ready design system for the Government of Canada, with code, design assets and documentation in one place, colour, spacing and typography tokens, page templates and regular accessibility testing.

What to learn: bilingualism and accessibility built into the components themselves, down to a language toggle component. If you sell to Canadian public-sector buyers or into Quebec, this is the reference to study.

The bottom line

A design system is not a Figma file or a style guide: it is the shared source of design decisions, in design and in code, with someone responsible for keeping it true. Start with tokens named by purpose and the components behind your core flow, store the tokens in the DTCG format, and grow the system only as fast as your product needs.

If you are deciding how much system your product needs, I help SaaS and AI teams set up tokens, components and documentation, then stay close to engineering until they hold up in production. See how I work as a freelance product designer, or tell me where your product is today and I will tell you whether to adopt, adapt or build.