Design Systems
Status: Stub Category: Design Default enforcement: Soft Author: PushBackLog team
Tags
- Topic: design, consistency, component-driven
- Skillset: design, frontend
- Technology: generic
- Stage: architecture, execution
Summary
A design system is a shared repository of reusable components, design tokens, usage guidelines, and interaction patterns that forms the single source of truth for how a product looks and behaves. It bridges the gap between design and engineering, enabling both disciplines to speak the same visual and structural language.
Rationale
Product interfaces built without a design system accumulate visual inconsistency over time. Components that should look identical diverge. Colours are hardcoded differently across files. Interactions that should behave the same are implemented differently by different engineers. The result is a product that feels assembled rather than designed.
A design system inverts this pattern. When design decisions are centralised — typography, colour, spacing, motion, component variants, interaction states — every new feature inherits them by default. Consistency becomes the path of least resistance rather than the result of deliberate effort.
For teams using AI personas, a design system gives the AI a defined vocabulary to operate within. Rather than making aesthetic decisions ad hoc, a persona can reference tokens, components, and usage guidelines that encode the decisions the design team has already made.
Guidance
Design tokens
Design tokens are the atomic units of a design system — named values for colour, typography, spacing, elevation, and motion. They sit between design intent and implementation:
color.brand.primary→#1E3A8Aspacing.md→16pxfont.heading.size.xl→2rem
Tokens decouple design values from their usage. A rebrand changes the token value; nothing else changes. A theme adds a token set; nothing in the component library changes.
Token categories to define:
| Category | Examples |
|---|---|
| Colour | Brand, semantic (success, warning, error, info), surface, text |
| Typography | Font families, sizes, weights, line heights |
| Spacing | Scale (4px base recommended), named sizes (xs → 3xl) |
| Elevation | Shadow levels, z-index scale |
| Motion | Duration, easing curves |
| Border | Radii, widths |
Component library
A component library is the engineering implementation of the design system. Each component:
- Is documented with its variants, props/API, and usage examples
- Has design tokens wired in rather than hardcoded values
- Has accessibility (ARIA attributes, keyboard interactions) built in, not added later
- Has defined states: default, hover, focus, disabled, error, loading
Component coverage should progress from atomic (Button, Input, Badge) to molecular (FormField, Card) to organism (Header, DataTable, Modal).
Usage guidelines
Components alone are not a design system. Each component needs guidance on:
- When to use and when not to use
- Which variants are appropriate in which contexts
- Interaction and behaviour expectations
- Accessibility requirements specific to the component
Versioning and governance
A design system without a governance model drifts. Establish:
- A versioning strategy (semver recommended)
- A contribution process for new components
- A deprecation process for components being replaced
- An owner or working group responsible for standards
For AI personas
When an AI persona is building UI, it should reference the design system for all visual decisions. If the design system does not cover a case, the persona should flag the gap rather than resolve it unilaterally.
Common failure modes
| Failure | Description |
|---|---|
| Token creep | New values added without governance; token count balloons |
| Design-implementation drift | Design tool and component library diverge and are no longer in sync |
| No adoption | Design system exists but teams continue copying and pasting components instead of importing |
| Under-documented | Components exist but usage guidelines don’t; engineers make arbitrary choices |
| Premature abstraction | Design system built before sufficient product patterns exist; components don’t fit real use cases |