Skip to content
FANKAARstudio

Design · 5 min read

Design systems for teams that are not big enough for one

Full design systems are overkill for most businesses. The small version that delivers most of the benefit, and the point at which the full thing pays off.

Design system content is written by companies with design system teams, which makes it advice for a situation most businesses are not in. The useful question for everyone else is which parts are worth having at five people rather than fifty.

The part worth having immediately

Tokens. A named set of colours, type sizes, spacing steps and radii, defined once and referenced everywhere. Not a component library, not documentation, just the values.

This is an afternoon of work and it prevents the specific failure where a site accumulates fourteen greys and six button heights over two years. It also makes a rebrand or a dark mode a change to one file rather than an archaeology project.

--ink: #07070A;
--bone: #FAF8F4;
--accent: #F5A524;
--space-1: 0.5rem;
--space-2: 1rem;
--radius: 12px;
The whole thing, at the size most teams need.

The part worth having soon

  • A dozen components used everywhere: button, input, card, dialog, table.
  • One place they live, so a fix lands in every instance.
  • States handled once: hover, focus, disabled, loading, error. This is where consistency is usually lost.

The part to skip until it hurts

  1. 01A published documentation site. Useful when many people who never speak consume the system. Overhead when there are four of you.
  2. 02Versioned package releases. Necessary across repositories, ceremony within one.
  3. 03Exhaustive component coverage. Build components when the second use appears, not in anticipation.
  4. 04A separate design-to-code pipeline. Appealing, and rarely survives contact with a real deadline.

The test for whether you need more

Count how often two people build the same thing differently without noticing. Once a quarter is fine. Once a week means the system is not doing its job and the next piece is worth adding.

One rule worth enforcing

No hard-coded values in components. Every colour, every spacing step, every radius comes from a token. It is a small discipline and it is what keeps the system real rather than aspirational, because the moment exceptions are allowed they become the majority.

Working on something like this?

We build websites, stores and custom applications, and we will tell you honestly if the thing you are describing does not need one.

Start a projectWhat we do