What a design system really needs
Components, rules and ownership: an essential structure for scaling coherent products without slowing teams down.
Published · 4 September 2026Updated · 4 September 2026
00 · Premise
A library is not yet a system.
A design system works when it connects design intent, interface behaviour and implementation. Components alone tell a team what can be reused, but not necessarily when, why or with which exceptions.
A useful distinction
A library and a system answer different questions.
In complex digital products, having consistent elements is not enough. Teams also need a shared agreement on meaning, behaviour, ownership and evolution.
UI library
- Components and variants
- Tokens and foundations
- Visual states
Design system
- Usage and content rules
- Experience patterns
- Ownership, release and maintenance
Principles and foundations
Colour, typography, spacing and grids become useful when they follow shared principles such as accessibility, density, tone and product priority.
Practical actions
- Define a small set of testable principles.
- Document tokens and scales with usage examples.
- Connect every foundation to accessibility requirements.
Purposeful components
Each component should solve a recurring need. Variants and properties should cover real states, not make the library abstractly complete.
Practical actions
- Explain when to use and not use the component.
- Include empty, error, loading and disabled states.
- Avoid variants without a verified use case.
Patterns and content
Products are sequences: search, input, comparison and confirmation. Patterns and content guidelines explain how components become understandable experiences.
Practical actions
- Document the most frequent journeys.
- Use realistic content in examples.
- Define tone, terminology and status messages.
Governance and adoption
Without ownership and update cycles, the system quickly drifts from the product. Governance should be lightweight but explicit.
Practical actions
- Share ownership across design and development.
- Define proposal, review, release and deprecation.
- Measure reuse, exceptions and solved problems.
Ready to use
The minimum credible system
- Shared principles and quality criteria.
- Foundations and tokens aligned with code.
- Components with states and usage rules.
- Patterns for core product journeys.
- Content and accessibility guidance.
- Ownership, versioning and contribution process.
Key principle
Consistency comes from shared decisions.
A design system should not eliminate design judgement. It should make that judgement faster, traceable and consistent across people, products and technologies.