Learn
What Is a Design System?
A design system is a collection of reusable components, patterns, guidelines, and standards that help a team build consistent products and communications. It is more than a style guide, which documents visual standards, and more than a component library, which provides reusable interface elements. A design system encompasses both of those things and adds the principles, documentation, and governance that make them work together coherently over time.
The idea behind a design system is that most of what a team builds is not new. A settings page, a login form, a data table, a notification banner: these are recurring problems with known solutions. Rather than redesigning each one from scratch every time, a design system captures the agreed-upon solution and makes it available for reuse. The result is faster development, greater consistency, and more time spent on the problems that are unique to the product rather than on reinventing common interface elements.
Design systems are sometimes perceived as something only large organisations need, the province of Google, Apple, and Salesforce. In practice, any team where more than one person creates interfaces or content benefits from at least a lightweight system. The scale can vary enormously, from a simple set of colour variables and a few documented components to a comprehensive multi-platform framework, but the underlying principle is the same: make shared decisions once, document them clearly, and make them easy to reuse.
The building blocks
A design system is built from several layers, each more complex than the last. Understanding these layers helps when deciding where to start and how much to build.
Design tokens are the smallest, most fundamental decisions in a design system. A design token is a named value for a visual property: a colour, a spacing increment, a font size, a border radius, a shadow, an animation duration. Rather than hard-coding these values throughout a product (using "#1a73e8" wherever the primary blue appears, for instance), a design system assigns them to named variables ("colour-primary" or "spacing-medium"). This abstraction has practical benefits. If the brand's primary blue changes, updating the token updates every instance across the product. Tokens also create a shared vocabulary between designers and developers; both can refer to "spacing-large" and mean the same thing.
Tokens are typically stored as variables in code (CSS custom properties, JSON files consumed by a build tool, or platform-specific formats) and mirrored in the design tool as shared styles. Tools like Style Dictionary help manage tokens across platforms, generating the appropriate format for web, iOS, and Android from a single source. Understanding colour space is relevant here, since colour tokens may need to be specified differently for screen and print contexts.
Components are reusable interface elements built from tokens. A button component, for example, uses the system's colour tokens for its background and text, spacing tokens for its padding, and typography tokens for its label. Components are designed and documented as self-contained units with defined properties (variants, sizes, states) and clear guidelines for when and how to use them.
Common components include buttons, input fields, dropdowns, cards, navigation bars, modals, tooltips, tabs, badges, and avatar displays. Each component should be defined in both the design tool (as a reusable Figma or Sketch component) and in code (as a reusable React, Vue, or other framework component). Keeping these two representations in sync is one of the ongoing challenges of maintaining a design system.
Patterns sit above components in the hierarchy. A pattern is a common arrangement of components that solves a recurring design problem. A search-results pattern might combine a search input component, filter components, result card components, and a pagination component into a cohesive layout. An onboarding pattern might sequence a progress indicator, form fields, illustration, and call-to-action button into a guided flow. Patterns are more contextual than components; they describe how components work together to achieve a specific goal rather than defining individual elements in isolation.
Documentation ties everything together. Every token, component, and pattern needs documentation that explains what it is, when to use it, when not to use it, how to implement it, and why it was designed this way. Good documentation includes live examples, code snippets, and rationale for design decisions. The rationale is particularly important because it helps people make consistent decisions in new situations that the system has not explicitly anticipated. If the documentation explains why a certain button style was chosen, someone facing a related but novel situation can apply the same reasoning rather than guessing.
Design system vs style guide vs brand guidelines
These three concepts are related but distinct, and the differences matter.
Brand guidelines define the brand's visual and verbal identity: logos, colours, fonts, tone of voice, photography style, and rules for their use. Brand guidelines are about the brand as a whole, across every medium and touchpoint. They are typically created by a branding agency or an in-house brand team, documented in a PDF or a dedicated section of the brand kit, and aimed at anyone who creates content for the brand. Brand guidelines say "this is who we are and how we present ourselves."
A style guide documents visual standards for a specific context, usually a product or a website. It specifies which colours, fonts, and spacing values to use, and often includes examples of correct and incorrect usage. A style guide sits between brand guidelines (broader) and a design system (deeper). It tells you what things should look like, but it does not provide the building blocks to construct them.
A design system provides the building blocks themselves. It takes the standards defined in the brand guidelines and style guide and implements them as reusable tokens, components, and patterns. A design system is not a document to be read and followed; it is a toolkit to be used. Designers drag components from the system's library in Figma; developers import components from the system's code package. The system enforces consistency through reuse rather than through rules.
In practice, the boundaries blur. A mature design system often includes its own style guide and references the brand guidelines. A small team might have a single document that serves as brand guidelines, style guide, and design system all at once. The important thing is not the label but the function: are the people building your product able to create consistent, well-designed interfaces efficiently?
Who needs a design system
The pragmatic answer is: any team where inconsistency has become a problem or where speed has become a bottleneck.
If designers on the same team are designing the same component differently, or if developers are implementing the same pattern with different spacing and colours in different parts of the product, a design system addresses that drift. If new features take longer than they should because every screen is designed from a blank canvas, a design system accelerates the process by providing a starting point.
Small teams sometimes assume design systems are overkill for their size. The opposite is often true. A small team has less capacity to absorb the cost of inconsistency and rework. A lightweight design system, even just a set of colour and spacing tokens plus a few core components, can save a two-person team meaningful time. The key is scaling the system to the team: a three-person startup does not need what Google has, but it does need shared standards that prevent the product from looking like it was designed by three people who never spoke to each other.
For designers working with developers, a design system provides a shared language. Instead of redlining every screen with pixel measurements, a designer can reference components and tokens that the developer already has access to. This shared vocabulary reduces handoff friction and the misunderstandings that arise when design intent is communicated through static images rather than structured specifications.
Teams working with external collaborators, whether agencies, freelancers, or contractors, benefit particularly from documented design systems. An external designer working within a well-documented system can produce work that looks and feels native to the product, whereas an external designer working without a system will inevitably produce work that requires extensive revision to bring it in line.
Well-known examples
Several large organisations have published their design systems, and studying these examples helps illustrate what a comprehensive system looks like.
Material Design by Google is perhaps the most widely known design system. It defines a comprehensive set of components, patterns, and principles for building digital products, with implementations for Android, iOS, Flutter, and the web. Material Design is notable for its strong opinions on motion, elevation (the use of shadows to suggest layered surfaces), and responsive layout. It is used across Google's products and by thousands of third-party applications.
Human Interface Guidelines by Apple provide detailed guidance for designing apps on iOS, macOS, watchOS, and other Apple platforms. Apple's guidelines emphasise platform conventions, encouraging developers to use native components and interaction patterns so that apps feel consistent with the rest of the operating system. The guidelines are less prescriptive about visual style than Material Design, focusing instead on usability principles and platform-specific behaviours.
Lightning Design System by Salesforce is a comprehensive design system for building applications on the Salesforce platform. It includes detailed component specifications, accessibility guidelines, design tokens, and implementation guidance. Lightning is notable for its enterprise focus and its attention to the complex, data-dense interfaces that business applications require.
Carbon by IBM is another enterprise-focused design system. Carbon provides a component library, design tokens, iconography, and extensive documentation, with implementations in React, Angular, and Vue. It is particularly thorough in its accessibility guidelines, reflecting IBM's commitment to inclusive design.
These examples share common traits: they define tokens, provide reusable components, include thorough documentation, and are maintained as ongoing projects rather than one-time deliverables. They also demonstrate that design systems are not static artefacts; they evolve alongside the products and platforms they serve.
How to start small
Building a design system does not require a dedicated team, a six-month project, or comprehensive coverage from day one. The most successful approach for most teams is to start small and grow organically from real needs.
Begin with tokens. Audit your existing product and identify the colours, spacing values, font sizes, and other visual properties currently in use. You will likely find inconsistencies: slightly different shades of grey, spacing values that vary by a few pixels, font sizes that do not follow a clear scale. Consolidate these into a defined set of tokens. This step alone improves consistency and makes future changes easier.
Next, identify your most-used components. Buttons, form inputs, and cards are common starting points. Document the existing variants (primary button, secondary button, disabled state, loading state) and establish a single agreed-upon version. Build or formalise this component in both the design tool and in code. Resist the urge to redesign everything at this stage; capture what exists, clean it up, and make it reusable.
Document decisions as you make them. When a question arises about whether to use a modal or a drawer, or how to handle form validation errors, or what the empty state of a list should look like, write down the decision and the reasoning behind it. Over time, these individual decisions accumulate into a pattern library. This organic approach produces a design system that reflects the product's real needs rather than an abstract ideal.
Storing the documentation, asset files, and reference materials that make up a design system in a searchable, well-organised workspace helps the system stay accessible as it grows. When a developer needs to check whether a component exists for a particular use case, or when a designer wants to review the rationale behind a pattern, being able to search across the system's documentation and assets saves time.
Tools for design systems
Several tools support different aspects of building and maintaining a design system.
Figma is currently the most popular tool for design system component libraries. Its component system supports variants, auto-layout, and shared styles, making it well-suited to defining and maintaining a library of reusable components. Figma's collaborative model means the whole team works from a single source of truth, and changes to a component propagate instantly to every file that uses it. Understanding design file formats helps when exporting from Figma or integrating with other tools.
Storybook is an open-source tool for developing, testing, and documenting UI components in isolation. It supports React, Vue, Angular, and other frameworks. Storybook provides a visual catalogue of every component in the system, rendered in the browser with all its variants and states. It serves as both a development environment and living documentation, since the components displayed are the real code components rather than static images.
Design token tools like Style Dictionary (by Amazon) and Theo (by Salesforce) help manage tokens across platforms. They take token definitions in a neutral format (typically JSON or YAML) and generate platform-specific outputs: CSS custom properties for the web, XML for Android, Swift for iOS, and so on. This ensures tokens stay consistent across platforms without manual translation.
Documentation platforms like Zeroheight, Supernova, and Notion are used by some teams to create browsable, shareable design system documentation. These platforms pull content from Figma and code repositories to create a unified reference that both designers and developers can use. For teams that want their design system documentation alongside their other creative assets and project files, a general-purpose workspace with good collaboration features can serve the same purpose.
Maintaining a design system over time
A design system is a product, not a project. It requires ongoing investment to remain useful.
Maintenance involves updating components when product needs change, adding new components and patterns as the product grows, fixing bugs in component implementations, keeping documentation current, and communicating changes to the team. Without maintenance, a design system gradually falls out of step with the product, and people stop using it because it no longer reflects how things are built.
Governance is the process of deciding what goes into the system, what changes, and how decisions are made. Some teams appoint a design system team or a design system lead; others distribute responsibility across the product team with a rotating curator. The important thing is that someone is responsible. A design system without an owner drifts into irrelevance in the same way that a brand kit without maintenance becomes a historical document rather than a working resource.
Versioning the design system helps teams manage change. When a component is updated, teams using the old version need time to migrate. Semantic versioning (major.minor.patch) communicates the nature of changes: a patch fixes a bug, a minor version adds a feature, a major version introduces breaking changes. This practice, borrowed from software development, applies equally well to design system components.
Feedback from the team is essential for keeping the system relevant. If designers consistently override a component's styling, that is a signal that the component does not meet their needs. If developers find the documentation unclear, the documentation needs improvement. A design system that is imposed from above without regard for the team's real workflows will be resisted or ignored. One that grows from the team's needs and incorporates their feedback becomes a shared tool that everyone values.
Keeping design system assets, from component source files to guideline documents and visual references, together in one location makes them easier to maintain and easier for team members to find. Content creators and marketing teams who need to use the design system for campaigns and communications benefit from having access to the same source of truth that the product team uses, ensuring that marketing materials and product interfaces remain visually aligned.
The value of shared standards
A design system is, at its core, a way of encoding shared decisions so that they do not need to be remade. Every token, component, and pattern in the system represents a decision that has been made once, tested, documented, and made available for reuse. This frees up time and mental energy for the decisions that are new and hard, the ones that require creativity, judgement, and deep understanding of the problem at hand.
The investment required to build and maintain a design system is real, but so is the cost of not having one: inconsistent interfaces, redundant work, slow onboarding, and the constant overhead of answering "how should this look?" and "has someone built this before?" for every feature and every screen. For teams that have felt that overhead, a design system, even a modest one, changes the way they work.
Frequently asked questions
How big does a team need to be to benefit from a design system?
There is no minimum size. A team of two people working on a single product can benefit from a shared set of tokens and a few documented components. The value of a design system is proportional not to team size but to the number of decisions being made about how things look and behave. Even a solo designer benefits from formalising recurring decisions so they do not revisit them on every screen.
What is the difference between a component library and a design system?
A component library is a collection of reusable interface elements: buttons, forms, cards, and so on. A design system includes a component library but also encompasses design tokens, patterns, documentation, principles, and governance. A component library tells you what the pieces look like; a design system tells you why they look that way and how to use them together. The component library is the toolkit; the design system is the toolkit plus the instruction manual and the workshop rules.
How long does it take to build a design system?
A lightweight design system (tokens, a few core components, basic documentation) can be assembled in a few weeks. A comprehensive system with dozens of components, multi-platform support, thorough documentation, and accessibility testing is an ongoing effort that unfolds over months and years. The key is not to delay starting because the full system feels too large. Start with what you need now and build from there.
Do design systems stifle creativity?
This is a common concern, and the answer is: not if the system is well-designed. A design system handles the routine decisions (what shade of grey for borders, how much padding inside a card, what the hover state of a button looks like) so that creative energy is available for the problems where creativity matters. No one benefits from an original take on a checkbox. Creativity is better directed at information architecture, user flows, data visualisation, and the novel interactions that distinguish a product from its competitors.
Should our design system be public or private?
Most design systems are internal to the organisation. Publishing a design system externally, as Google and IBM have done, makes sense when the system is used by third-party developers building on your platform. For most teams, a private system shared with everyone who builds for the product is the right approach. The important thing is accessibility within the organisation, not publicity outside it.
How do we keep our Figma library and code components in sync?
This is one of the persistent challenges of design systems. Some teams use tools that generate code from Figma components (or vice versa). Others maintain them manually with regular audits to catch drift. The most common practical approach is to treat the design component and the code component as two expressions of the same specification, updating both when the specification changes, and to document the specification clearly enough that discrepancies can be identified and resolved. Establishing a process for design feedback helps catch inconsistencies early.
What are design tokens in plain language?
Design tokens are named values for visual properties. Instead of using the colour "#1a73e8" directly in your product, you assign it the name "colour-primary" and use that name everywhere. If the colour changes, you update the token once and the change propagates throughout the product. Tokens exist for colours, spacing, font sizes, border radii, shadows, and any other visual property that should be consistent across the product. They are the smallest, most atomic decisions in a design system.
Can we use an existing design system instead of building our own?
Yes, and for many teams this is the most practical approach. Material Design, Ant Design, Chakra UI, and other open-source design systems provide comprehensive component libraries that can be customised to fit your brand. Using an existing system as a foundation saves significant time, especially for teams without dedicated design system resources. The trade-off is that your product will share visual DNA with others using the same system, though theming and customisation can mitigate this.
How do we get the team to adopt the design system?
Adoption succeeds when the design system makes people's work easier rather than adding overhead. Solve real problems the team faces (inconsistent components, slow handoff, redundant design work) and the system sells itself. Involve the team in building the system so they feel ownership. Make the system easy to find and use: components that require a five-step process to access will not be used. And accept that adoption is gradual; not every screen needs to be migrated to the system on day one.
What happens when a component in the system does not fit our needs?
This is normal and expected. A design system cannot anticipate every situation. When a component does not fit, the team should decide whether to extend the component (adding a new variant), compose a new pattern from existing components, or create a new component entirely. Document the decision and the reasoning. If the same gap arises repeatedly, that is a signal to add a new component to the system. Good design systems grow from exactly this kind of real-world feedback.