- A design system pays off once several people design or build the same interface, or once the product ships in more than one theme or platform.
- For a first product with one designer and one developer, a small kit of tokens and core components is enough; a documentation site can wait.
- Design tokens are the part to get right first: name them by purpose, keep one source and export them to code.
- Code is the source of truth for how a component behaves; the Figma library should mirror its names and options.
- A system needs an owner and a simple way to request and ship changes, or it drifts within months.
When is a design system worth it for a small product team?
A design system is worth it once more than one person designs or builds the same interface, once the same parts appear on many screens, or once the product has to work in more than one theme or platform. Before that point, a small kit of shared colours, type styles and core components does the job with far less effort. The mistake small teams make is not skipping the design system; it is building a large one before the product has settled.
The goal is simple: the next screen should be faster to design and build than the last one, and it should look like it belongs to the same product. If you are planning a new product interface, this is part of the UI and UX design work, not an extra project on the side.
What is the difference between a UI kit, a component library and a design system?
| What it is | What it contains | Who it suits |
|---|---|---|
| UI kit | Shared colours, type styles and drawn components in the design tool | One designer working with one or two developers |
| Component library | Coded, reusable components with their options and states | A development team building many screens |
| Design system | Tokens, the design library, the coded components and the rules for using and changing them | Several designers or developers, or more than one product or platform |
Most small teams need the first two and a light version of the third: enough rules that a new person can build a screen without guessing.
Which signs say you need one now?
- The same component exists in several versions. Buttons, inputs or modals differ slightly from screen to screen, and nobody knows which is right.
- Developers rebuild what is already built. A new screen means new styles instead of reused components.
- Design reviews keep catching the same issues. Spacing, colour contrast and empty states are fixed one screen at a time.
- A second theme or platform is coming. Dark mode, a white-label version for clients or a mobile app all multiply every inconsistency.
- New people take a long time to get going. Freelancers or new hires ask the same questions about how things should look.
If none of these apply, keep a small kit and revisit the question when the team or the product grows.
What is the smallest useful design system?
Start with what every screen uses:
- Tokens: colour, type, spacing, corner radius, shadows and motion timing.
- Core components: button, text input, select, checkbox and radio, modal, toast or alert, table, card, tabs and the main navigation.
- States for each component: default, hover, focus, disabled, loading, error and empty, because these are what get forgotten.
- A page of rules: when to use each button style, how forms show errors, how dates and numbers are written.
The brand comes first. If the logo, colours and type are still moving, settle them before you lock them into tokens; our guide to a brand kit for a new software company covers what to decide at launch.
How should design tokens be set up?
A design token is a named design decision, such as the colour of primary text or the spacing between form fields. Two layers keep them manageable:
- Base tokens hold the raw palette and scales: every shade of blue, every spacing step.
- Semantic tokens say what a value is for, such as text-primary, surface-raised or border-error, and point to a base token. Components use only semantic tokens, so a new theme changes the mapping, not the components.
In Figma, variables and modes can hold tokens and switch a design between contexts such as light and dark themes. Figma's guide notes that publishing variables to team libraries is available on its Professional, Education, Organization, Government and Enterprise plans, so check your plan before you depend on it.
To move tokens between tools and code, the Design Tokens Community Group has published its first stable version, 2025.10, of a JSON format for tokens. The specification itself states that it is a community group report, not a W3C Standard, so treat it as a shared format that tools are adopting rather than a rule. Keep one source for your tokens and generate the CSS variables or platform files from it.
Check contrast when you set colour tokens, not after the screens are built. WCAG 2.2 success criterion 1.4.3 asks for a contrast ratio of at least 4.5:1 for normal text.
How do you keep Figma and code in step?
Design and code drift apart when they are maintained separately. A few habits prevent most of it:
- Match names and options. Figma variant properties such as size, state or colour can be mapped to code components, so give them the same names and values the developers use.
- Let code decide behaviour. The coded component is the source of truth for focus order, keyboard use and loading states. The design file shows how it looks.
- Show components in isolation. Storybook describes itself as a frontend workshop for building components in isolation and can generate documentation from them, which gives designers a live reference.
- Review changes together. A component change is done when both the library and the code are updated and the changelog says so.
On React and Next.js projects, our React and Next.js development team builds the component library alongside the first screens so that it is used from the start.
Who owns the system, and how do changes get made?
Every system needs a named owner, usually one designer and one developer together. Keep the process light:
- Anyone can request a new component or a change, with the screen that needs it.
- The owners decide whether it is a new component, a new option on an existing one or a one-off for that screen.
- Changes ship as a version with a short note on what changed and what to update.
- Old components are marked as deprecated before they are removed, so screens can move over in their own time.
How do you add a design system to a product that already exists?
- Audit what is there. Screenshot every button, input, colour and heading style in the live product and group the duplicates.
- Pick the canonical version of each and define the tokens behind it.
- Build the core components in code and in Figma, with all their states.
- Replace as you go. Move screens to the new components when they are next changed instead of freezing the roadmap for a big rewrite.
This is slower than a rewrite on paper, but it keeps features shipping and lets the system prove itself on real screens. For a first product, the same thinking applies to planning an MVP: build the parts you use now and grow from there.
Frequently asked questions
Should we use an open-source component library instead of building our own?
Often, yes. A well-maintained open-source library gives you accessible, tested components on day one, and you add your own tokens on top so it looks like your product. Build your own components only where the library fights your design or your workflows, and keep a list of every place you have overridden it.
Do we need a documentation website for our design system?
Not at first. For a small team, a single page of rules in the Figma library plus the component stories in code is enough. A separate documentation site becomes worth it when people outside the core team, such as agencies, freelancers or a second product team, need to use the system without asking questions.
How long does a first version take to set up?
For a small product it is usually a matter of weeks, not months, because you start from the screens that already exist. Tokens and the core components come first, then the system grows as screens are redesigned. Treat it as part of normal product work rather than a separate project with its own deadline.
Can one design system serve both a web app and a mobile app?
The tokens can, and that is where most of the value is: colours, type, spacing and radius stay the same everywhere. Components usually differ, because native mobile controls and web controls behave differently. Share the tokens and the naming, and accept that each platform has its own component set.
What does a design system cost to keep up?
Mostly time. Someone has to review requests, update the Figma library and the code together, and write a short changelog. On a small team that is a slice of one designer and one developer each week. The cost of skipping it shows up later as inconsistent screens and slower builds.
Last updated