Design system
A design system is the shared kit that several products or teams build with: styles, reusable interface parts in design files and in code, guidance on using them, and rules for how they change. In UX terms, repeated parts look and behave the same way across screens, so people learn them once.
- Foundations
- Reusable components
- Patterns
- Operating model
Design system components: what a design system includes
Teams most often need the term when they must work out what is shared and what stays local to one product.
That line between shared and local is the hard part. Component count is easy to measure and says little.
A component library is one part of a design system. A shared status choice, for example, has to carry the same meaning in the design files, the code, the documentation and every product that uses it. A system also needs owners, a way to contribute and a way to migrate.
Design system governance explains how shared choices change. Design system adoption asks whether teams use them. Design system drift names the unintended gaps that open between them.
Explore Design Systems.
Most systems hold the same six layers. Smaller teams may start with two or three and add the rest as more products share them.
| Layer | What it holds |
|---|---|
Foundations | Design tokens: the named colour, spacing, type and motion values every screen uses |
Components | Buttons, fields, tables, menus and the rest, each with its states such as loading, empty, error and disabled |
Patterns | Repeated answers to whole tasks, such as filtering a list, confirming a risky action or showing an empty page |
Design files and code | The Figma library and the coded components, kept in step so designers and engineers use the same parts |
Guidance | When to use each part, how to write its labels and what it needs for accessibility |
Rules for change | Who owns the system, how teams contribute and how products move to a new version |
Why use a design system? An example from Auxentios
A design system pays off when several products or teams keep making the same interface choice. The shared layer carries what needs one answer, and product-specific behaviour can stay local.
In the Auxentios case, Tcules developed components, design tokens and layout guidance from the product model. Design tokens are the shared colour, spacing and type settings. The library followed the product work.
Auxentios expected its product to need more than 200 screens. Designing each one alone would have meant hundreds of separate choices to maintain. Repeated needs became shared components once the core experiences were worked through. That is the usual reason to use a design system: solve a repeated problem once and reuse the answer.
Matter is a free Figma design system Tcules made and published. It shows how Tcules names design tokens and structures components.
Design system vs component library and style guide
People use the three terms loosely. Each one usually contains the one before it.
| Style guide | Component library | Design system |
|---|---|---|
Visual rules such as colour, type, logo use and tone of voice | Reusable interface components | Foundations, components, patterns, design files, code, guidance and rules for change |
Answers how the product should look and sound | Answers how a shared element looks and works | Also answers what belongs in the shared layer, how it changes and how products adopt it |
Often a document or a page of examples | Can exist without a way to contribute or migrate | Needs ownership and a route from change to the products that use it |
Design system questions teams ask
What does a design system mean in UX?
In UX, a design system is what keeps the experience consistent as a product grows. The same action looks and behaves the same way on every screen, so people learn it once. Designers then spend their time on new problems instead of redrawing solved ones.
Is a Figma library the same as a design system?
A Figma library is one part of a design system: the design assets. A full system also has matching coded components, guidance on when to use each part, and owners who decide how it changes. A library that has drifted away from the code is a common sign that those other parts are missing.
When does a product team need a design system?
A team needs one when several products, squads or designers keep solving the same interface problem in different ways. Familiar signs are three versions of the same table and review comments about spacing. A single small product can start with a shared component library and grow from there.
Can a design system be added to a product that already exists?
Yes. Many systems start inside a live product: the team finds the repeated parts and pulls them into shared components, one area at a time. In the Gold Image Printing modernisation, Tcules designed components and a style guide, then used them across the online store and the internal ERP.
Where Tcules plans, builds and repairs design systems
What the shared system should own, and what should stay local to a product, is the choice behind the definition. Design systems are also becoming something software reads: some teams now write their rules so AI tools can build from them, and a clear, well-described system helps keep generated screens consistent. Two more terms sit close by: design to code, which keeps the build matching the design, and design engineering, the practice of designing directly in code.
Tcules plans, builds and repairs design systems through Design Systems. Design System Implementation puts the system into Figma and code, and Figma and Storybook Alignment brings an existing library and its code back in step.