Why teams don't use what gets built for them

Why teams don’t use what gets built for them

Nobody says it directly. But almost every founder who has tried to fix their design process before has felt it.

What if we pay for something nobody actually uses?

This fear sits underneath a lot of “we’ve tried this before and it didn’t stick.” It’s not a dramatic concern. It’s quiet. Reasonable. Based on something that actually happened.

And it’s almost always pointing at the wrong cause.

---

The failure wasn’t the system. It was the process that built it.

Most design systems fail at adoption for one reason: they were built for the team, not with them. A designer or a studio produced something technically solid, handed it over, and assumed the team would slot it into their workflow. They didn’t. Nobody was being difficult. They just had no ownership of something they’d never touched.

This is not a design problem. It’s a change problem.

And the people who write long documentation guides about it are solving for the wrong thing.

---

Three ways a system gets abandoned before it’s ever used

The first failure mode is building without asking. The team gets a finished system the day it lands in their Figma workspace. Nobody was consulted on the patterns that matter most to them. Nobody flagged the edge cases specific to their data product. The system is technically correct. But it doesn’t quite fit how they actually work. So they work around it.

The second is handing over without training. A 60-minute walkthrough of a component library is not training. It’s a tour of a city where you’ve never driven. People nod, feel vaguely overwhelmed, and go back to what they know. Six weeks later the system is untouched.

The third is the most damaging and the most overlooked: there’s no way for the team to participate after delivery. A design system is not a finished product. It’s a living structure. When people encounter patterns that don’t work, or data types the system didn’t account for, they need a way to flag it and feed it back. Without that process, the team’s only options are to work around the system or ignore it. Most choose ignore.

---

What changes when the team helps build it

At Santander, I was working across four countries with 70+ designers. Partway through, we noticed three of the four markets weren’t using a set of components we’d already shipped. The obvious response would have been better documentation. That wasn’t what fixed it.

What fixed it was weekly sessions explaining and questioning the reasoning behind every new addition, and dedicated update sprints that gave each country’s representative a way to flag what was and wasn’t working. The team started contributing to the system rather than just receiving it.

The system didn’t change. Their relationship to it did.

This is what shared ownership looks like in practice. Not a workshop. Not a survey. A process where the people who have to use something can shape it, question it, and improve it. When someone has had a hand in building a thing, they defend it. When something gets handed to them fully formed, they tolerate it until they don’t have to.

---

The real question

The question most people ask when evaluating a design system engagement is: is this system good enough?

That’s not the right question.

The right question is: does the team feel like this system is theirs?

A technically excellent system that nobody owns will fragment within months. A simpler system that the team built together, understands, and has a process for evolving will outlast the people who built it.

Good documentation helps. Solid components help. But the thing that actually determines whether a design system works six months after handoff is whether the team treats it as infrastructure they rely on, or something someone else put there.

That’s not a design decision. It’s a process one. And it starts on day one, not at handoff.