Key takeaways
- A small design system should remove recurring decisions, not become a side product to maintain.
- Start with named tokens and the components already repeated in production.
- Document behaviour, accessibility and content rules alongside appearance.
- Track adoption and retire exceptions; component count is not a useful success metric.
A four-person product team does not need a miniature version of a global company’s design platform. It needs a dependable answer to recurring questions: which blue is the action colour, how does a disabled button behave, and what does an error message say?
The useful system is the smallest shared set of decisions that designers and developers use in real product work. It should shorten a feature, not create a second roadmap competing with the product.
Audit before creating
Take screenshots of a few representative flows and list the patterns already present. Count button styles, field heights, spacing values and modal layouts. The audit usually reveals both genuine patterns and accidental variations.
- Keep a variation when it communicates a real difference in meaning or behaviour.
- Merge variations that exist only because different people built them.
- Leave a one-off feature local until another use proves it belongs in the shared system.
Name decisions with tokens
Tokens replace raw values with names that describe purpose. Use names such as color-text-muted and space-section rather than gray-500 and 48px. Purpose-based names let the visual value change without editing every component and make themes easier to reason about.
| Token group | A practical small-team starting point |
|---|---|
| Colour | Page, surface, text, muted text, border, action, danger, success |
| Type | Body, small, label, heading levels, line heights and weights |
| Space | A short scale used for gaps, padding and page sections |
| Shape | Two or three radii plus a pill value |
| Elevation | One subtle card shadow and one overlay shadow |
Build the workhorses first
Choose components by frequency and cost of inconsistency. Buttons, links, form controls, alerts, cards, navigation and dialogs normally earn their place before charts or elaborate marketing sections.
Each component needs more than a polished default. Define hover, focus, disabled, loading, empty, error and long-content states. Check keyboard interaction and screen-reader naming while the API is still easy to change.
Documentation that fits beside the work
A live component page or Storybook is helpful, but a small team can begin with one page per component. Show the supported variants, a working example, when to use it, when not to use it and any content constraints. Link directly to the implementation so examples cannot quietly drift away from the code.
- Button: reserve the primary style for the main action in a region.
- Error message: name the problem and the next action; do not write “Invalid input”.
- Dialog: use for a short interrupting decision, not as a container for an entire workflow.
- Card: do not make nested controls part of the same large link target.
A lightweight contribution rule
When a feature needs something new, first try the existing component and record why it fails. If the need is likely to recur, add the smallest general variant with a design and code review. If it is unique, keep it with the feature. Review exceptions quarterly; repeated exceptions are evidence, not disobedience.
Measure whether it is helping
- How often new screens use shared components without custom copies.
- How many visually duplicate components remain in the product.
- Whether accessibility defects recur after being fixed in the shared layer.
- How long common interface work takes before and after adoption.
Written by the Prestigious Software team
We design, build and run web platforms, SaaS products and mobile apps. About us
Our team reviews each article. Claims based on standards or research link to primary sources; examples are illustrative unless identified as client work.
