Design systems have a reputation problem. Public examples from large companies — hundreds of components, dedicated documentation sites, governance committees — make them look like something only big organisations can afford.
But the problem a design system solves is felt most acutely in small teams: the third slightly different button, the fourth shade of grey, the modal that behaves differently on every screen. A lean system prevents that drift without becoming a project of its own.
Start with tokens, not components
Tokens are the named values everything else is built from: colours, type sizes, spacing, radii, shadows. Defining them first gives you most of the consistency for a fraction of the effort.
- A colour palette with semantic names — surface, text-muted, accent, danger — rather than blue-500.
- A type scale of six to eight sizes, each paired with a line height and weight.
- A spacing scale based on a single unit, used for every margin and gap.
- Two or three radii and elevations, not one per designer.
Put the same tokens in Figma and in code, with the same names. When a designer says spacing-6, the developer should know exactly what that means.
Build the ten components you use every day
Most products are assembled from a small set of parts. Build those properly — with every state — before building anything rare.
- Button, with primary, secondary and quiet variants
- Text input, select and checkbox, with error and disabled states
- Card or surface
- Modal and drawer
- Toast or inline alert
- Table or list row
- Tabs
- Avatar and badge
- Empty state
- Loading skeleton
What to leave out
Resist building components for things that appear once. A bespoke onboarding illustration or a one-off marketing layout doesn't belong in the system. The rule we use: a pattern earns a place in the system the third time it's needed.
The best small design system is the one your team still uses six months later.
Documentation that fits on a page
Skip the documentation website. A single page per component in Figma, plus a Storybook for developers, is enough. Each entry should answer three questions: when to use it, when not to, and what states it has.
Keep it alive
Nominate one designer and one developer as joint owners, and review changes to the system together. Fifteen minutes in the weekly design review is enough governance for a team of five. The system grows as the product does — deliberately, and only when the product needs it.
Written by
DevTechnology Design