A design system for small teams: start with tokens
Design systems aren't only for large companies. With a few tokens, ten base components and a handful of clear rules, a small team can ship a consistent product and build faster. Where to start, and what you can skip.
Mention "design system" and many people picture the several-hundred-page documentation of a large company, then conclude it is too much for a small team. Six months later the product has seven kinds of button, twelve greys and five spacing values.
A small team needs a design system more, because it has no time for rework.
What a design system is
A shared set of decisions made once and used everywhere. It has three layers:
- Tokens: base values — colour, spacing, type size, corner radius.
- Components: button, field, card, tag.
- Patterns: how components combine — forms, lists, empty states.
Start with tokens
A token gives a raw value a name. Rather than writing the green's hex code in a hundred places, you define one name and call it everywhere.
The benefit is immediate:
- Change in one place. If the brand colour changes, you edit one line.
- Light and dark themes almost for free. Only the token values change, not the components.
- Automatic consistency. With only five spacing values defined, nobody can invent a sixth.
This site is built that way: one file holds the raw colour values and every component uses names. An automated test checks that no component contains a raw colour.
Semantic tokens
Name tokens by role, not appearance. "Primary text colour" beats "dark grey", because in a dark theme the primary text is no longer dark.
A small set of components
You don't need fifty components to begin. This list covers most products:
- Button (primary, secondary, link)
- Input field and its label
- Select and toggle
- Card
- Status tag
- Dialog
- Error and success messages
- Empty and loading states
Define each with all its states: default, hover, pressed, disabled, error and focus. A component designed only in its default state is half-finished.
Rules worth writing down
- A spacing scale. A few fixed values, not whatever looked right.
- A type scale. Five or six sizes, each with a defined use.
- Contrast. Every text and background pair must be readable. This can be tested automatically.
- One primary button per screen. If everything is important, nothing is.
- Motion. Durations and easings are tokens too, and they switch off for users who prefer reduced motion.
Accessibility from the base
If accessibility is built into the base components, every screen made from them is accessible by default:
- A clear focus ring.
- Touch targets that are large enough.
- Labels for screen readers.
- Full keyboard operation.
Getting this right in ten base components is easy. In two hundred screens it is not.
Multilingual and right-to-left
If the product is Persian or may become bilingual, the design system needs logical direction from the start. Adding it later means revisiting every component.
What you don't need to begin
- A separate documentation site.
- Dedicated tooling.
- A component for every special case.
- Complex versioning.
One sample page showing every component and its states side by side is enough.
Keeping it alive
- New components only after repetition. Don't add something until it has been needed three times.
- Record exceptions. If you break a rule somewhere, write down why.
- An automated guard. A test that finds raw values in components prevents erosion better than any document.
What the business gets
- Speed. New screens are assembled from ready parts.
- Consistency. The product looks more professional and more trustworthy.
- Cheaper change. A rebrand takes days, not weeks.
- Easier onboarding.
The takeaway
Start the design system with tokens, build ten base components, write a few rules and protect them with an automated test. That much delivers most of the value.
Related: multi-step forms people actually finish.