Design Systems That Scale: What 300+ Components Taught Me

When I redesigned most of the 23degrees platform, the work produced more than 120 screens and over 300 components in Figma. Later, for GTAI, we built a modular system of 50+ components ready to grow with new data. Here's what those projects taught me about systems that actually scale.

1. Start from real screens

Libraries designed in a vacuum rarely survive contact with the product. Audit the screens you already have, find the patterns that repeat and the inconsistencies that hurt, and build from there. At 23degrees, one goal was connecting previously separate services into one seamless flow — the system had to reflect real journeys.

2. Foundations before components

Colour, type, spacing, grid, elevation and states are the grammar. Get them right as tokens and most components almost design themselves. Hundreds of variants can't fix weak foundations.

3. Design every state

A component isn't done until it has its states: hover, focus, disabled, loading, empty, error, long text. Data and AI products add more — no data, partial data, low confidence. Designing states up front is what prevents surprises in development.

4. Name things for the people who use them

Names are the API of your system. Use names that designers, developers and product managers understand the same way, and document when to use a component, not just how it looks.

5. Make it scale with content

Real content is longer, messier and more multilingual than mock-ups. Test components with long labels, German compound words (GTAI's own language) and Spanish text before calling them finished.

6. Treat hand-off as part of the system

Specifications, prototypes and naming conventions are what make a system usable by developers. A system that only lives in Figma isn't a system yet.

7. Keep it alive

Assign ownership, version changes and collect requests. A design system is a product for your team — it needs a roadmap like any other.

Is it worth it?

If your team keeps redrawing the same button, debating the same spacing or shipping inconsistent screens, yes. A good system frees your team from design guesswork so it can focus on growth. Let's look at yours.

FAQ

When does a product need a design system?

When several people design or build screens, when the product keeps growing, or when inconsistency starts slowing the team down. Small products benefit from foundations even before a full library.

How many components should a design system have?

As many as the product needs and no more. Strong foundations and well-defined states matter more than the number of components.

What's the difference between a UI kit and a design system?

A UI kit is a set of components. A design system adds foundations, rules, documentation, naming and governance, so teams can build consistent products at scale.