Design systems for small teams: tokens, components and documentation

A design system is the shared set of decisions, parts and guidance a team uses to build its product: the colours and type, the buttons and forms, and the notes that explain when to use each. Large companies have dedicated teams for this. A small team doesn’t need that, but it does benefit from writing down its decisions before every page starts to look slightly different.

This guide explains the three layers that matter (tokens, components and documentation), how much of each a small team needs, and how to start without stopping product work.

What a design system is, and isn’t

Therese Fessenden’s NN/g article Design systems 101 defines a design system as a complete set of standards for managing design at scale using reusable components and patterns. It describes three parts: a style guide (brand, colour, typography, tone of voice), a component library (reusable interface elements with their states and code), and a pattern library (larger groupings such as page headers or templates).

A Figma file of polished screens or a one-off brand guide falls short of this. The system has to be a source of truth that designers and developers both use, so that the button in the design file and the button in the code are the same thing.

NN/g lists the benefits: faster design work, fewer inconsistencies, a shared vocabulary, easier rebrands and quicker onboarding. It also notes the cost. A full system pays off for organisations with large volumes of repeated design work, and an early prototype that will change a lot probably won’t earn its investment back soon.

Layer one: tokens

Design tokens are named values for design decisions: colours, font sizes, spacing, corner radii, shadows. Instead of a developer typing #1d70b8 in forty places, the code says color.action.primary, and the value lives in one file.

This idea now has a published standard. The W3C Design Tokens Community Group announced the first stable version of its specification, version 2025.10, on 28 October 2025. The announcement describes tokens as the single source of truth for colours, typography, spacing and other design decisions, and says the format supports theming (such as light and dark modes), aliases between tokens, and generating code for iOS, Android, web and Flutter from one source. It lists Style Dictionary, Tokens Studio and Terrazzo as reference implementations, with support in tools including Figma, Penpot and Sketch. The specification itself is at designtokens.org.

A useful habit is two tiers of token:

• Base tokens hold raw values: blue-600, space-4.
• Semantic tokens say what a value is for: color-text-error, space-section. Components use these.

(Our guide to colour in interfaces covers choosing the palette itself.) The GOV.UK Design System’s colour guidance shows the benefit in practice. Teams reference colours through named functions rather than copying hex codes, and functional colours are used only in the roles they were designed for, so a palette update reaches every service that uses the functions.

Layer two: components

Components are the reusable building blocks: buttons, text inputs, cards, navigation bars, alerts. Each should exist once, in code and in the design tool, with its variants (primary, secondary) and states (default, hover, focus, disabled, error) defined.

Brad Frost’s atomic design offers a helpful way to think about them. Atoms are basic elements such as labels, inputs and buttons. Molecules are small groups working together, such as a search form. Organisms are larger sections such as a site header. Templates place components into a layout, and pages fill templates with real content. Frost stresses that this is a mental model, not a step-by-step process.

For a small team, start with the components you use most. On most business websites and apps, that is buttons, form fields, links, headings, cards, alerts and the main navigation.

Layer three: documentation

Documentation is what turns a pile of components into a system. Without it, people still guess. NN/g’s component library description is a good checklist for each entry: name, description, adjustable attributes, states, code snippet and supported frameworks. Add a short “when to use” and “when not to use” note, which prevents most misuse.

Keep documentation close to the work. A single page per component in a shared wiki, or a tool such as Storybook next to the code, is enough. Polished public documentation sites are for systems with many users.

Starting small: a six-week plan

An example (illustration only). A four-person SaaS start-up (one designer, three developers) finds its app has seven button styles and a dozen greys. Rather than pausing product work, it adds a few hours of system work a week.

1. Week 1: audit. Screenshot every button, input, colour and text style in the live product. Group duplicates.
2. Week 2: tokens. Agree a palette, type scale and spacing scale. Store them as tokens in one file that both design and code read.
3. Week 3: buttons and inputs. Build these once, with all states, using only tokens. Replace old versions as screens are touched.
4. Week 4: documentation. Write one page for each component with usage notes and a code example.
5. Week 5: next components. Add alerts, cards and navigation.
6. Week 6: ownership. Name one designer and one developer as joint owners, and agree how anyone can propose a change.

NN/g notes that a dedicated design system team ideally includes at least an interaction designer, a visual designer and a developer. A small team can’t spare full-time people, but it can give two people clear part-time ownership.

Common mistakes

• Building a large library before the product has settled.
• Designing components in the design tool that never get built in code, or the reverse.
• Hard-coding values instead of using tokens, so a colour change means a search-and-replace.
• Naming tokens by appearance (light-green) rather than purpose.
• Leaving out states, especially focus and error, which then get improvised.
• No owner, so the system drifts within months.

Build, adopt or adapt

NN/g notes that adopting an existing open-source system is the cheapest option, adapting one costs more, and building a custom system costs most. For many small teams, starting from an established component library and putting your own tokens on top is the sensible route. Build your own components only where your product needs something the library doesn’t do. And if you only have a handful of pages and one person designing, a single page listing your colours, type sizes and button styles may be all the system you need for now.