The real reason design systems fail

Design systems are supposed to be a potent accelerant for product organisations. The promise is speed, consistency, and quality. Yet first-time efforts often misfire. Why?

When we wrote Why design systems fail, we put forward 11 reasons why these projects can stall. But there’s one overarching reason they fail before they get going. We’ve seen it time and again: The organisation tries to hire the design system team and build the system at the same time. Few succeed.

Analysis paralysis

Ideally, you give new teams space. They explore the problem, get to know each other, run experiments, and define their operating model. But that’s not what happens.

In reality, organisations smash together a design system team of all the disciplines. Design, engineering, product and content. A week later, people start asking where the components are.

This ignores the social progression of any new group, Tuckman’s Forming, Storming, Norming, Performing.¹ You have to build relationships before you can build norms. You have to decide how you make decisions before you can actually ship effectively.

When you demand a design system from a team that hasn’t normed, you skip the foundational work, and analysis paralysis sets in.

Teams freeze up over questions around:

• Choice of technology
• Defining a design token schema
• Using composable architecture

Because the team members haven’t gelled, they lack the collective confidence to figure things out. Meanwhile, the organisation looks on with increasing unease.

Systems, not stacks

This is compounded by the trend toward generalists. Organisations often assume they can airdrop a group of engineers and designers into the problem.

But a design system requires extensive domain experience underpinned by systems thinking. You can put generalist engineers on a product feature, and as long as they know the stack, they’ll probably figure it out because the domain is constrained.

Platform work is different. It requires understanding the ecosystem. Without that experience, you might as well grab them off the street.

So, if building the team and the system at the same time is a trap, what are your actual options?

Option 1: Don’t build a design system

This is a valid choice. Not every organisation needs one. Particularly if you’re building a monolith.

But if you have, say, 10 products, plus different brands and stacks that operate independently, the trade-offs of not having a system can be huge.

You accept that you’ll rebuild the same wheel 10 times, and continually wrestle against degradation of the user experience.

Usually the equation is easy. Outcome: you need a design system.

Option 2: Outsource to an agency

You could pay an agency to build the design system for you.

This appeals to the factory model of software development. You pay a capital expenditure to build the factory, and then it’s done. But software isn’t a factory. It’s people, it’s time, and it changes constantly.

Agencies can build you an artefact, but a design system is a living service. If you outsource the build, who owns it when they leave? If you haven’t built an internal team alongside, the system stalls the moment you get the keys.

You’re back to square one. You may have a starter design system, but you still need an internal team to build on it.

So: don’t do this.

Option 3: Work with a consultant

This is the approach we advocate, obviously.

You bring in a team that has done this before. This offers two massive advantages:

1. Immediate velocity: The consultant (humour our use of the third person here) builds a scaffolding team of specialists who can start meaningful work immediately. Because they’re already norming and performing, they don’t have to figure out how to work together. They know where the sharp edges are because they’ve seen and accounted for them before.
2. Co-piloting the handover: They don’t just build the library; they help build the team that will replace them.

They help leadership hire the right designers, engineers and product people. They help navigate the specific constraints of the sector, because building a system for a risk-averse bank requires a different approach than building one for a fast-moving tech company.

Crucially, an experienced consultant solves Fredkin’s Paradox for leadership: the closer two options are in value, the less the decision matters and the harder it can be to choose between them.

When a new team faces two good technical options, they can lose weeks debating them. The consultant comes with the pattern recognition to say, “We’ve seen this before. Just do option 1.” The project is unblocked and velocity is maintained.

With a permanent design system team in place, and a core system built, the scaffolding comes down. The permanent team takes over, running the system with established norms. The organisation gets a system ready to evolve, and the team to do it.

Sound about right? Drop Paul a line.

Footnotes

1. If you can read Tuckman’s words without thinking “Schwarzkopf”, we envy you. ↩