Why it matters
Without one, every new screen is drawn from scratch and small differences pile up: three button styles, four greys, spacing that changes from page to page. A design system removes that drift and speeds up new work. It also lets you apply accessibility and brand rules once instead of everywhere. It matters most when several people, or several products, share the same look.
What it contains
| Part | What it is | Example |
|---|---|---|
| Design tokens | Named values for colour, type, spacing, radius and shadow | A primary text colour, a small spacing step |
| Components | Reusable interface pieces, designed and coded | Button, input field, modal |
| Patterns | How components combine to solve a recurring task | A sign-in form, an empty state |
| Guidelines | Written rules for use, voice and accessibility | When to choose the primary button |
Designers usually keep the components in a tool such as Figma. Developers keep the coded versions in a component library documented in a tool such as Storybook. The two must match, and the tokens are what keep them in sync. For the service itself, see design systems.
An example
Imagine a retailer with a website and a mobile app that both show product cards. With a design system, the card is defined once: its spacing, its text sizes and its right-to-left layout for Arabic. When the brand colour changes, a designer edits one token and both products follow. This is a hypothetical example, not our work.
Common mistakes
- Building every component before shipping anything. Start with the pieces your product already uses most.
- Having no owner. A system nobody maintains drifts back into a pile of exceptions.
- Leaving right-to-left layouts and accessibility until later, when they are expensive to retrofit.
- Documenting the look but not the reasoning, so people cannot tell when a rule applies.