Before you get stuck into building a design system, it’s worth pausing to ask a bigger question: Is the business even ready for one?

Too often, I’ve seen teams fired up to build the “perfect” system, only to hit walls they didn’t expect. Excitement fades, momentum stalls, and suddenly the thing you were all so energised about becomes a source of frustration.

Move too fast (or dream too big too soon) and you risk wasting time, burning people out, and ultimately creating something the business just isn’t set up to support.

Because here’s the thing: a design system isn’t just a library of components. It’s a product. And like any good product, it needs the right conditions to succeed — strategy, structure, and sustained investment.

You’ve got to build for where the business is now, not where you hope it’ll be in six months.

What do we mean by “business maturity”?

When we talk about maturity here, we’re not talking about headcount or how long the team’s been around. We’re talking about how well the organisation actually works across product, design, and engineering.

It’s about how decisions get made, how work gets prioritised, and how teams collaborate (or don’t).

A helpful shortcut is the Product Organisation Maturity Model, which outlines four rough stages:

  • 🟣 Enabled
  • 🔵 Established
  • 🟢 Company-Leading
  • 🟡 Market-Leading

Each one changes what kind of system makes sense — and what’s likely to go wrong if you try to push too far ahead.

Some quick signs of maturity to look for:

  • Are teams working together or mostly in silos?
  • Is product work clearly tied to business goals?
  • Do people follow similar ways of working, or is everyone doing their own thing?

Knowing where you are helps you design something that fits, rather than something you constantly have to drag uphill.

Where are you right now?

Here’s how maturity tends to manifest in practice and how it should inform your approach to systems work.

🟣 Enabled

You’re early days. Teams are starting to work together, but it’s patchy. There are probably a lot of legacy processes still in place, and a handful of individuals driving most of the change. Delivery is often reactive, and there’s a general lack of alignment across teams.

This is the point where enthusiasm can easily outrun readiness.

Focus on:

  • Agreeing on some shared principles and design values to ground future work.
  • Building simple, scalable foundations. Tokens, naming conventions, small wins.
  • Making work visible. Show what’s possible without overpromising.

Avoid:

  • Launching a full system.It’s too early and will likely be ignored.
  • Over-documenting.Guidance will go stale before it’s even used.
  • Assuming everyone’s onboard. You’re probably still earning trust.

This phase is about laying the groundwork. You’re building credibility, not infrastructure.

🔵 Established

You’ve got teams shipping regularly, but things are starting to fray. Growth is exposing gaps. There’s more cross-functional collaboration happening, but still a fair bit of chaos underneath.

There might be some shared tools in place, but they’re probably inconsistent or breaking under pressure.

People are starting to feel the need for a system, even if they haven’t asked for one yet.

Focus on:

  • Introducing light governance. Who owns what? How are decisions made?
  • Creating basic contribution workflows, even if they’re scrappy.
  • Aligning tools and libraries to avoid duplication and drift.

Avoid:

  • Trying to build everything at once—you’ll burn out fast.
  • Running siloed design or dev initiatives. The system needs to cut across both.
  • Skipping onboarding. People won’t use what they don’t understand.

This is your moment to start scaling deliberately. Keep it lean, but structured.

🟢 Company-Leading

Your system is already in use, and now you need to level it up. There’s solid alignment across product, design, and engineering. People expect the system to be part of the delivery pipeline.

But with visibility comes pressure. You’ll start to see growing pains in duplicated components, inconsistent guidance, or drop-offs in contribution.

The challenge here isn’t starting — it’s sustaining.

Focus on:

  • Improving contribution and maintenance models so the system scales with the org.
  • Defining and tracking metrics: usage, adoption, time saved, bugs prevented.
  • Running regular audits to catch issues before they compound.

Avoid:

  • Letting the system sprawl.More isn’t better.
  • Letting documentation rot. Outdated guidance erodes trust fast.
  • Mistaking adoption for impact. Measure how the system’s actually helping.

This phase is about operational excellence. You’re not just running a system — you’re running a service.

🟡 Market-Leading

You’re operating at real scale. The system is business-critical and deeply embedded. Teams rely on it to deliver efficiently and expect it to evolve alongside product strategy.

You’ve got a well-oiled machine, but keeping it healthy takes serious investment.

Focus on:

  • Innovating intentionally. Explore accessibility, performance, and workflow improvements.
  • Building internal tools and infrastructure to automate maintenance and support scale.
  • Planning long-term. Define a vision, set goals, and grow the culture around the system.

Avoid:

  • Treating the system as “done”. Sorry, leadership, there’s no finish line.
  • Letting patterns go stale. Evolution is what keeps the system useful.
  • Forgetting internal storytelling. Advocacy matters just as much now as it did at the start.

This phase is about leading from the front. Your system isn’t just keeping up, it’s setting the standard.

Set expectations early

Wherever you are, one rule always holds: expectations shape outcomes.

It’s easy to get excited about what a system could be. But if the business isn’t ready to support it properly, even the best system will struggle.

Before you start building anything, ask:

  • Do we have leadership backing, or just a few excited individuals?
  • Are there workflows in place to support long-term use and maintenance?
  • Who actually owns this system — and how will it keep evolving?

Start small. Share your thinking. Get buy-in early. Then grow the system with the business, not ahead of it.

Things to Keep in Mind

A design system can be transformative — but only if it’s grounded in the reality of where your business is today.

Frameworks like the Product Organisation Maturity Model help you set the right expectations, avoid the usual pitfalls, and design a system that fits, not fights, the org around it.

Take a clear-eyed look at where you are. That clarity might save you months and help you build something that actually lasts.