Behind the scenes: crafting design systems that teams actually use
Design systems that work solve real problems teams already have, keep design files and code components in sync, are documented with clear usage guidance, have named owners and a contribution process, and are measured by adoption. They are treated as internal products with users, a roadmap and regular releases, rather than as a one-off style guide.
Why many design systems fail
Design systems promise consistency, speed and quality, and most medium and large digital organisations now have one in some form. Yet many struggle to get used. Designers keep creating one-off components, developers rebuild buttons from scratch, and the documentation site slowly falls out of date. The system exists, but it does not change how teams work.
The causes are usually organisational rather than technical. Systems are often built in isolation by a small team that tries to anticipate every need, then launched with a big announcement and left to fend for themselves. Without owners, a roadmap or a way for product teams to contribute, the system cannot keep up with real work, and teams quietly route around it.
| Failure | What it looks like | Root cause |
|---|---|---|
| Design and code drift apart | Figma components do not match production | No shared source of truth |
| Low adoption | Teams build their own components | System does not meet real needs |
| Stale documentation | Guidance contradicts current practice | No owner or update process |
| Bottlenecks | Teams wait weeks for new components | No contribution model |
Principles of systems that work
- Solve real problems: Start with the components and patterns teams struggle with today.
- One source of truth: Design tokens and components shared between design files and code.
- Useful documentation: Explain when and why to use each part, with examples.
- Clear ownership: A named team or person responsible for quality and roadmap.
- Open contribution: A defined path for product teams to propose and add components.
- Regular releases: Versioned updates with change notes, like any product.
Design tokens: the foundation
Design tokens store the basic design decisions of a brand, such as colours, type sizes, spacing, radius and shadows, as named values that can be used in both design tools and code. When a token changes, every component that uses it updates. Tokens make it possible to support themes, dark mode and multiple brands from one system. The W3C Design Tokens Community Group is working on a common format so tokens can move cleanly between tools. Our guide to building a design system from zero covers how to define them.
Documentation people read
Good documentation answers the questions people actually ask while they are working: which component should I use here, what are the options, what should I avoid, and is there code I can copy? Short, scannable pages with live examples beat long written guides. Include do and don’t examples, accessibility notes and links to the code and design file for every component.
- A one-line description of what the component is for
- Live examples of each variant and state
- Usage guidance with do and don’t examples
- Accessibility requirements and keyboard behaviour
- Links to the design component and code package
- A change log showing recent updates
Governance without bureaucracy
Governance decides how the system changes. Too little and the system fragments; too much and teams wait weeks for decisions and stop asking. A lightweight model gives product teams a clear way to request or contribute components, with a small core team that reviews, refines and publishes them.
- Request: A team describes a need the system does not meet.
- Review: The core team checks whether an existing pattern solves it.
- Build: The requesting team or core team builds the component to system standards.
- Release: The component is documented, versioned and announced.
Driving adoption
Adoption grows when the system makes teams faster. Pair with product teams on real projects, offer office hours, migrate high-traffic screens first and celebrate teams that adopt it. Make the right thing the easy thing: if using a system component takes less effort than building one, most developers and designers will choose the system.
| Metric | What it shows |
|---|---|
| Component coverage | Share of screens or code using system components |
| Detached components | How often designers break away from the library |
| Time to build a screen | Whether the system speeds up delivery |
| Contribution rate | How involved product teams are |
| Satisfaction survey | How useful teams find the system |
Accessibility as a built-in benefit
A design system is the most efficient way to make a whole product family accessible. When buttons, form fields and navigation components meet WCAG 2.2 AA once, every team that uses them inherits the benefit. Include colour contrast checks in your tokens, keyboard and focus behaviour in every component and screen-reader labels in the code. Our post on accessibility in UI/UX design covers the standards in more detail.
Treating the system as a product
The most successful design systems are run like internal products. They have users, which are the designers, developers and content writers who rely on them every day. They have a backlog of requests, a roadmap of planned improvements and a release schedule. The core team talks to its users regularly, watches how components are used in real projects and prioritises work that removes the biggest pain points.
This mindset changes the conversation with leadership too. Instead of asking for budget to maintain a style guide, the team can show how many hours the system saves, how much faster new features ship and how many accessibility issues it prevents. That evidence makes it much easier to keep investing as the organisation grows.
- Run quarterly surveys with designers and developers
- Hold regular office hours for questions and feedback
- Publish a public roadmap of upcoming components
- Share release notes after every update
- Track requests and how quickly they are resolved
Who builds and maintains the system
A design system team does not need to be large. Many organisations start with one designer and one front-end developer working part-time on the system, alongside product work. As adoption grows, the team may add a dedicated design lead, engineers for each platform, a content designer and an accessibility specialist. What matters most is that someone clearly owns the system and has time set aside to look after it.
Scaling across an enterprise
Large organisations often have several brands, platforms and regional teams. A layered approach works well: a core layer of tokens and foundations shared by everyone, a component layer for each platform, and brand themes on top. Our enterprise design systems guide explains how to organise this, and our product design team helps clients set up the structure and governance.
Frequently asked questions
Why do design systems fail?
Usually because they are built in isolation, drift away from code, lack owners and do not give teams an easy way to contribute.
What are design tokens?
Named values for design decisions such as colours, spacing and type sizes, shared between design tools and code.
Who should own a design system?
A small core team, often designers and front-end engineers, with clear responsibility for quality, roadmap and releases.
How do we measure design system success?
Track component coverage, time to build screens, detached components, contributions and team satisfaction.