What a design system is, and is not

The phrase design system is used for many things: a Figma library, a component package, a style guide website, a set of brand rules. In this course, a design system means the shared foundations, components, documentation and processes that let several teams build consistent interfaces efficiently. All four parts matter.

The parts of a system

• Foundations: tokens for colour, spacing, type and motion, plus principles such as layout grids and accessibility standards.
• Components: reusable interface pieces, designed in Figma and built in code, with clear behaviour and APIs.
• Documentation: guidance on when and how to use each piece, including examples and things to avoid.
• Process: how teams request changes, contribute, receive updates and get help.

A Figma library without code components gives designers consistency but leaves engineers rebuilding everything. A code library without documentation gets used inconsistently. Neither survives without a process for change.

What a system is not

• Not a finished project. Products evolve, so the system evolves. It needs ongoing ownership and funding.
• Not a tool for control. A system that only says no will be bypassed. Its job is to make the right thing the easy thing.
• Not a substitute for design. Product teams still solve product problems. The system removes repeated decisions so they can focus on those problems.
• Not always necessary. A single small team with one product may get most of the benefit from a tidy Figma library and a shared stylesheet. Systems pay off when several teams or products share an interface.

The value a system creates

Benefits usually fall into three groups:

1. Efficiency: fewer repeated decisions and less duplicated code.
2. Quality: consistent behaviour, accessibility fixed once and reused everywhere.
3. Coherence: products that feel like they belong together.

Be cautious about promising exact time savings. They are hard to measure honestly. It is better to measure concrete things, like adoption of components, accessibility issues resolved at the component level, or time from design to release for common patterns.

Our case study

Throughout the course we follow a company with three product teams: billing, analytics and an admin console. Two teams use React and one uses Vue. Their interfaces share a brand but little else. Your job is to plan, build and run a system that serves all three.