10xdesign.com

Design Systems for Small Teams: When You Need One

6 min read

A design system is not a component library or a shared design file. It is a set of recorded decisions, plus a process for changing them, that lets several people build screens that look and behave like one product. Small teams tend to adopt one too early, when a shared file would do, or too late, after the product has drifted into five button styles. This guide helps you tell which situation you are in and what the smallest useful version looks like.

What a design system is made of

Most working design systems have four parts. When a system stops being used, one of these is usually missing.

Tokens

Tokens are named design decisions: color.text.primary, space.medium, radius.small, duration.fast. Instead of a hex value or a pixel number pasted into a hundred places, the code and the design file both refer to the name. Change the value once and everything that uses the name follows.

Components

Components are the reusable building blocks: buttons, inputs, menus, dialogs, cards. A component in a design system is more than a drawing. It has defined states (default, hover, focus, disabled, loading, error), defined variants, and a matching implementation in code that behaves the way the drawing says it will.

Documentation

Documentation answers the questions people would otherwise ask in chat: when to use this component, when not to, which variant fits which situation, and what the accessibility requirements are. For a small team this can be one page per component, written in plain language, with an example of correct and incorrect use.

Governance

Governance is the process for change: who can add a component, who approves a new token, how breaking changes are announced, and when old things get removed. It sounds like bureaucracy, but without it a system either freezes, because nobody feels allowed to change it, or fragments, because everybody changes it.

Signs a small team needs one

Headcount is a poor signal. A team of three can need a system, and a team of fifteen working on one simple app may not. Look for these patterns instead:

  • The same component keeps getting rebuilt. Two engineers ship two date pickers in the same quarter, each slightly different.
  • Values are drifting. Search your stylesheets for distinct color values and font sizes. If you find clusters of near-duplicates, such as three grays one shade apart, nobody is working from a shared source.
  • Handoff arguments repeat. Designers and developers keep settling the same spacing, the same focus style, the same empty state, one ticket at a time.
  • A second surface is coming. A native app, a marketing site, a partner-branded version, or dark mode. Each new surface multiplies every inconsistency you already have.
  • New people take too long to ship UI. If a new hire has to ask which button to use, the answer should live somewhere they can find it without asking.

Signs you can wait

  • You have one product, one platform, and one or two people making most interface decisions.
  • The product is still searching for fit, and screens get thrown away every few weeks.
  • An off-the-shelf component kit already covers most of what you build, and your changes to it are small.

In those cases a shared design file plus a short style page is enough. Revisit the question when one of the signs above shows up.

A minimum viable design system

The smallest useful version is small enough to build alongside product work. Build it in this order.

  1. Audit what exists. Screenshot every distinct button, input, heading style, and color in production, then group the duplicates. The inventory is both your case for the work and your list of what to consolidate.
  2. Define a small token set. Start with color (text, backgrounds, borders, brand, and feedback states such as error and success), a spacing scale, a type scale, corner radius, and elevation. Name tokens by purpose, like color.text.muted, rather than by appearance, like gray-500, whenever the value might change by theme.
  3. Build the few components that appear everywhere. Usually buttons, text inputs, selects, checkboxes, links, and a dialog. Cover every state in both design and code.
  4. Write one page of documentation per component. When to use it, when not to, its variants, and how it behaves with a keyboard and a screen reader.
  5. Name an owner and a change rule. One person, even part-time, owns the system. Changes go through one place, such as a pull request reviewed by a designer and a developer.

Resist building a documentation website on day one. A well-organized README or wiki page that people actually read beats a polished site that goes stale.

Design tokens and the DTCG format

For years every tool stored tokens in its own format, so moving decisions between a design tool, a code repository, and a build pipeline meant writing converters. The Design Tokens Community Group (DTCG), a W3C Community Group, has been working on a shared, vendor-neutral format, and it announced the first stable version of its specification, version 2025.10, on October 28, 2025.

Be precise about what that status means. The Design Tokens Format Module 2025.10 is published as a Final Community Group Report, and its own status section says it "is not a W3C Standard nor is it on the W3C Standards Track." It also says the specification is considered stable and that further updates will come in superseding versions. For a small team choosing a token format, that is stable enough to build on.

The format is JSON. Each token has a $value and usually a $type, and can carry a $description. Groups nest tokens, a $type set on a group applies to the tokens inside it, and a token can point at another token with curly braces. That last feature is how you separate a raw palette from the semantic names your components use:

{
  "color": {
    "$type": "color",
    "blue-600": {
      "$value": {
        "colorSpace": "srgb",
        "components": [0, 0.4, 0.8],
        "hex": "#0066cc"
      }
    },
    "action": {
      "$value": "{color.blue-600}",
      "$description": "Background for primary buttons."
    }
  },
  "space": {
    "$type": "dimension",
    "medium": { "$value": { "value": 16, "unit": "px" } }
  }
}

Two more details from the spec are useful early. The recommended file extensions are .tokens and .tokens.json. And a $deprecated property lets you mark a token as on its way out, optionally with a message that names its replacement.

Tool support is growing but uneven. Style Dictionary, an open-source build tool that turns token files into CSS, JavaScript, iOS, and Android outputs, has had first-class support for the DTCG format since its version 4. As of September 2026, though, its own documentation says the 2025.10 format is not yet fully supported and that the work is in progress in version 5. The structured color and dimension values in the example above are 2025.10 syntax, so check which version of the spec each tool in your pipeline reads before you commit to it.

What maintenance costs

Building the first version is the cheap part. The ongoing cost is what sinks small-team systems, so plan for it before you start.

  • Keeping design and code in sync. Every change lands in two places. If only one gets updated, people stop trusting either.
  • Versioning and change notes. Once product code depends on your components, a renamed property or a removed variant breaks someone's screen. Use version numbers, keep a short changelog, and batch breaking changes.
  • Deprecation. Removing things is harder than adding them. Mark the token or component as deprecated, point to its replacement, and remove it on a stated schedule.
  • Saying no. Every one-off request, such as a special variant for a single campaign, adds to what you maintain indefinitely.

A useful model for that last point comes from the GOV.UK Design System, which publishes its contribution criteria. A proposal has to be useful, meaning there is evidence many teams would use it, and unique, meaning it does not replicate something already in the system. Before publication it must also be usable (tested in user research with a representative sample of users, including disabled people), consistent with existing styles and code standards, and versatile enough to work in different services. A small team can copy those five words into its pull request template as a checklist.

Budget the time explicitly. Whoever owns the system needs protected hours for it in every cycle, or it becomes the thing everyone relies on and nobody maintains.

A simple way to decide

If you are unsure, run the audit from step one anyway. It is quick, and the result answers the question for you. If the audit turns up a handful of consistent patterns, keep your shared file and look again in six months. If it turns up clusters of near-duplicate colors, several button styles, and two versions of the same component, you already have a design system. It is just undocumented, unowned, and inconsistent, and the work ahead is making it deliberate.

More from 10xdesign.com