Design systems are an economic investment in scale and operational efficiency. A well-executed system reduces overheads, increases reuse, and accelerates time to market. The value proposition is clear: ship faster, maintain consistency, reduce waste.

But in most product teams, a design system isn't for designers — it's for engineers.

Many teams can miss this. We build for the wrong user, optimising too early for design workflows, and watch as adoption stalls. The system looks clean in Figma but struggles in production. Engineers find workarounds. Costs rise. Usage drops off.

The disconnect is structural, stemming from a fundamental misunderstanding of who the design system is really for.

Built for the wrong audience

Many design systems are built back-to-front.

We instinctively start in Figma, where a system represents a hypothetical ideal case. Early energy goes into creating diverse tokens, well-documented components and flexible variants, forging a design language that looks elegant in the abstract.

But that abstraction doesn't reflect the day-to-day experience of most engineers. They're implementing these components across multiple views, devices, and codebases. They're working in real environments, under pressure, with real constraints. They're dealing with edge cases, browser quirks, accessibility needs, and framework limitations.

And they're doing it at scale.

Most product teams run at a 6:1 or 8:1 ratio of engineers to designers. That means every efficiency gain has a 6-8x multiplier.

If the design system doesn't make engineering faster, easier, and more repeatable, we've optimised for a minority user and missed the most potential value. No matter how great the Figma files are, we've already missed the primary purpose.

When we design a system that prioritises designers over engineers (simulations over implementation) we're building something one step removed from reality.

The cost of that disconnect will inevitably show up everywhere.

The economic impact

The consequences are both technical and financial. We build technical debt. We waste costly engineering hours re-implementing components. We pay for a system that doesn't deliver its promised return.

Engineers hit mismatches between what's designed and what's available in code. They (very reasonably) start duplicating work because it's faster to rewrite than to reverse-engineer a design.

The system becomes bloated with one-off exceptions and deviations. Trust erodes. Usage drops off.

Teams find themselves maintaining a design system and a set of workarounds, doubling the surface area for bugs, complexity, and maintenance.

This isn't just theoretical. Teams and products can live and die in the gap between design and production.

Unlocking the economic benefit.

We can unlock more economic benefits by starting where value is created: with working code. Design the system from the engineering layer upward.

Define tokens, primitives, and components in code, with clear documentation, strong typing, and sensible defaults. Build for developer experience first. Usage should be frictionless, predictable, and boring.

Then, once that layer is working, bring it into Figma. Reflect what already exists in code. Let designers work from what's real, not what's ideal.

The result will be a system rooted in the actual constraints and logic of implementation — one that's naturally more consistent, more scalable, and more likely to be adopted by engineers.

This inversion — code first, Figma second — reduces rework, shortens feedback loops and gets features to market faster.

In short, it scales.

The real job of a design system

When we invest in a design system, we're investing in engineering efficiency. The biggest force multiplier effect isn't making designers faster — it's making engineers faster, more consistent, and less error-prone.

The system's real job is to help them stay consistent, reduce overheads, and ship features without repeatedly solving what's already been solved.

Design systems aren't for showing off how well we can abstract a button. They're infrastructure. They're about reuse over reinvention. About moving fast without breaking things. About addressing real implementation problems at scale.

Build for designers first, and well get a wonderful Figma file. Build for engineers first, and we get product that ships faster, works better, and costs less to maintain.

That's where the value lives.