Design Systems Don't Fail on Craft. They Fail on Trust.

Nobody could tell me exactly how many separate design systems were quietly running across BT Global's product estate when I started looking properly. That was rather the point.

Each product team had built its own answer over the years: its own components, its own version of the type scale, its own idea of what a button was allowed to look like. None of it was written down anywhere useful. None of it had been checked against the accessibility standards a global brand is actually supposed to meet. It wasn't chaos exactly. It was worse than chaos: it was lots of small, locally reasonable decisions that had quietly stopped adding up to anything coherent at all.

The obvious response is to build a proper system and roll it out. I've watched design leaders do exactly that and still fail, because they treated it as a production problem: build the components, write the guidelines, announce the launch, done. It isn't a production problem. Design systems only work if teams actually use them, and teams don't use things they don't trust. You can have the most elegant component library in the world and it will sit there, admired and ignored, right next to the scrappy internal pattern library everyone actually opens.

The audit came before a single new component. Before anyone touched Figma, we catalogued what already existed across the whole estate. Not to mock it, to understand it. Some of those locally evolved solutions were genuinely good, built by people solving a real problem with whatever tools they had to hand. The system needed to absorb that work, not stand over it and declare that none of it counted. Teams forgive being asked to improve on their own work. They don't forgive being told to throw it away for something that clearly never looked at it.

Accessibility was the floor, not a feature you add later. Every colour token, every type scale, every interactive state and focus behaviour was built with accessibility as a first principle, not a compliance pass bolted on before launch. That decision alone did more for the system's credibility than any amount of visual polish would have. It told every team using it that the people who built it had actually thought about the humans on the other end, which is a lower bar than it should be and a rarer one than it should be too.

Documentation was the trust exercise, not the paperwork. We put real weight behind usage guidelines and worked examples, for designers and developers both, specifically so teams could adopt the system without needing us stood over their shoulder explaining it. A system that only works with hand-holding isn't actually authoritative yet. It's just tolerated, and tolerated things get quietly abandoned the moment the person doing the holding looks away.

The real signal was never adoption. It was contribution. Plenty of teams will use a system because someone with a title told them to. The ones worth watching are the sceptics, the teams who'd built their own version and were quietly attached to it, who eventually came back with a fix or an improvement for the shared system instead of their local one. That's usually the sign it's actually working.

So what does this actually tell us? That rolling a system, or a brand standard, into an estate that already has years of embedded habits isn't a design exercise wearing a governance hat. It's the other way round. You are not primarily building components. You are earning the right to be the default, and you earn that by proving, early and visibly, that you respect what already exists more than you're asking anyone to respect you.

Most design systems that fail were perfectly well designed. Nobody trusted them enough to actually put them to work.