Design Systems for Growing Products: When and How to Start

A design system is the shared set of decisions, code and guidance that lets a team build a new screen without designing the button again. Most products do not need one on day one. Most growing products need one sooner than they start it, and pay for the delay in inconsistent screens and slow front-end work.

This guide covers how to recognize the moment, what belongs in the first version, and how to keep that version small enough to finish.

Signs you have outgrown ad hoc styling

• The same brand color appears in the CSS as five slightly different hex values.
• There are three kinds of primary button, each built by a different person.
• Every new screen begins with a debate about spacing and font sizes.
• A change to the form error style has to be made in a dozen files.
• What ships drifts away from the design files, and QA logs visual bugs every release.
• A request for dark mode or a rebrand would mean touching every template.
• Accessibility fixes such as contrast and focus outlines are made screen by screen, and come undone.

One or two of these are normal. With four or more you are already paying what a design system costs, without having one.

When it is still too early

Before launch, while layouts and flows change every week, fixed components slow down the learning you need. With one designer, one developer and one product, a conversation does the job of a system. And if nobody can be given time to maintain shared components, they will go stale within a few releases.

In those cases adopt an existing component library or CSS framework as it comes, and keep one short page of your own choices: colors, type sizes, spacing. That page becomes the seed of your tokens later.

What a design system is made of

Three layers and one habit. Tokens are design decisions stored as named values. Components are reusable pieces of interface built from those tokens, in code and in the design tool. Documentation says when and how to use each one. The habit is a known way of changing all three, with a person responsible for it. Without that last part you have a UI kit, which is accurate on the day it is made and a little less so every week after.

Start with tokens

Tokens come first because everything else refers to them. Use two tiers. Base tokens hold the raw scales: the palette, the spacing steps, the radii. Semantic tokens say what a value is for. Components use only the semantic tier, so a rebrand or a dark theme means remapping a handful of semantic tokens instead of editing every component.

:root {
  /* base tokens: the raw scales */
  --blue-700: #1d4ed8;
  --gray-900: #111827;
  --white: #ffffff;
  --space-2: 0.5rem;
  --space-4: 1rem;
  --radius-2: 0.375rem;

  /* semantic tokens: what each value is for */
  --color-action: var(--blue-700);
  --color-on-action: var(--white);
  --color-text: var(--gray-900);
  --radius-control: var(--radius-2);
}

.button-primary {
  background: var(--color-action);
  color: var(--color-on-action);
  padding: var(--space-2) var(--space-4);
  border-radius: var(--radius-control);
}

For a web product, CSS custom properties like these are enough. When the same decisions must also reach a design tool or a mobile app, keep the tokens in a JSON file and generate the CSS from it. The Design Tokens Community Group at the W3C has published a stable format for such files, and design tools and build tools increasingly read and write it.

A first token set covers color, the type scale, spacing, corner radius, shadows and breakpoints. Name semantic tokens by purpose, not appearance. --color-action survives a rebrand, while a name with "blue" in it becomes a lie the day the brand turns green.

Build the components you already repeat

Do not guess which components you need. Take an inventory: screenshot every button, input, card, table, modal and alert in the product and sort them into groups. The piles of near-duplicates show you what to build first. For most products the first ten are close to this list: button, text input, select, checkbox and radio, a form field wrapper with label and error message, alert, modal, card, table and tabs.

For each component, write down and build:

• its variants (primary, secondary, destructive) and sizes;
• every state: hover, focus, pressed, disabled, loading and error;
• how it behaves on a narrow screen;
• its accessibility: keyboard operation, a visible focus indicator, labels tied to their fields, and enough contrast.

That last line is one of the strongest arguments for the whole exercise. A focus style or a contrast problem fixed in the component is fixed on every screen that uses it. If the product has to meet WCAG 2.2, the component library is where most of that work belongs, and our WCAG starter guide lists the criteria that affect components most.

Build components in the technology the product already uses: Blade components in a server-rendered Laravel application, React or Vue components in a JavaScript front end (the setup we describe under Laravel with React and Vue). Mirror them in the design tool with the same names and variants. When the two disagree, the code wins, because the code is what users receive.

Documentation people open

Give each component one page: what it is for, when not to use it, its variants, an example of right and wrong use, a snippet to copy, and its accessibility notes. Live, rendered examples are better than screenshots, and Storybook is a widely used tool for browsing components in isolation. Keep the pages in the same repository as the components, so that the pull request that changes a component also changes its documentation.

A first month that produces something usable

1. Take the inventory. A few days of screenshots and sorting, done by a designer and a developer together.
2. Agree the tokens and replace hard-coded values in the existing CSS with them. Nothing visible changes, and that is the point.
3. Build five to ten components inside the real product, replacing existing instances as you go. A system built off to one side is a system nobody has tested.
4. Document each component on the day it is finished.
5. Name an owner and write down how changes happen: who approves a new component or variant, and how someone proposes one.
6. Keep a changelog, and version the library if more than one application uses it.

From then on, apply one rule: new screens use the system, and old screens move over when they are next touched. A migration project for its own sake rarely gets finished.

How design systems fail

Built in isolation. A separate team works for months and announces a finished library. Product teams, who were not involved, carry on as before.

Too large, too soon. Sixty components are specified before ten are in use. Most are wrong, because nobody had a real screen to test them on.

Design and code drift apart. Nobody owns keeping the two in step, so each becomes a slightly different system.

No owner and no time. Maintenance is everyone's side task, which means it is nobody's.

Too rigid. There is no route for an exception or a contribution, so teams override the styles locally and the inconsistency returns under a new name.

The common thread is treating the system as a project with an end date. It is a small product with users, releases and a backlog.

Build, borrow or bring in help

A team with a designer and a front-end developer can do the first month described above without outside help. A team without a designer is usually better off borrowing: take an established open-source component library, theme it with your own tokens, and document only what you changed. That is a legitimate design system, and it is often the right size.

Outside help makes sense when the existing interface has to be refactored while feature work continues, when several products or a web app and a mobile app must share one set of tokens, or when there is nobody in-house to make the design decisions. Our UI/UX design service covers the inventory, tokens and component design, and the same team builds the components into the product, which matters most on long-lived SaaS products where the interface keeps growing.

Frequently asked questions

What is the difference between a design system and a style guide?

A style guide describes how things should look: colors, typography, logo use. A component library is the code. A design system contains both, plus the documentation and the process for changing them, so that designers and developers work from the same source.

Can one design system serve a website and a mobile app?

The tokens can. Colors, spacing and type sizes kept in one JSON file can be turned into CSS for the web and into theme code for a mobile framework such as Flutter. Components are built separately for each platform, following the same names and rules.

Should we build our own components or use an existing library?

Use an existing library unless your interface has needs it cannot meet. Established libraries have already solved keyboard handling, focus management and browser quirks, which are expensive to get right. Apply your tokens on top, and build your own components only for what is particular to your product.

How do we know the design system is working?

Watch adoption and friction. Count the screens built from system components, the one-off style overrides in the codebase, and the visual bugs logged per release. If new screens are quicker to build and those overrides are shrinking, it is working. If teams keep going around it, find out what it lacks.