Large software systems are very poorly understood, even by the people most in a position to understand them. Even really basic questions about what the software does often require research to answer. And once you do have a solid answer, it may not be solid for long - each change to a codebase can introduce nuances and exceptions, so you’ve often got to go research the same question multiple times.
I believe a lot of the challenges we’re seeing in the current generation of software comes down to this very issue. Software is so big and complicated that no one fully understands the thing they’re working on.
That is such a existential problem. I cannot overstate how destructive this is to quality.
Design systems are not immune to this. The bigger they become, the harder it is to grasp its full footprint. Now imagine working on software that no one fully understands with a design system that no one fully understands…
I cannot think of a greater responsibility for a design system team than for everyone on the team to truly grasp how their design system works. From head to tail. Resist sprawl and feature creep. Stay small, focused and understandable.
This promise is fundamentally about money. The federated model gets framed as a way to get a design system “for free.” You can save the cost of staffing a dedicated team by distributing the work across existing teams.
Yup. This is entirely about money. If companies were so bought in to the idea of federated models, they’d be pervasive in organizational operating models. But they aren’t–at least from my purview. The push for federated design systems is the push to get something without having to pay for it. Which, to be fair, is human nature. The problem is that it doesn’t work. Not only does it not work, it becomes a distraction to everyone roped in to work on it. As is the case with a lot of things, “free” ends up costing a lot of money.
The Design Tokens Community Group today announced the first stable version of the Design Tokens Specification (2025.10), marking a milestone for design systems teams and tool makers worldwide. After years of collaborative development, the specification provides a production-ready, vendor-neutral format for sharing design decisions across tools and platforms.
This is a relatively dated update, but a significant one. Design systems are ironically lacking in open standards. Design tokens represent a great starting point. My hope is that this spreads to defining standards around documentation, component specification and library structure.
I’m not a fan of blindly following what others are doing. But I’m also not fond of reinventing a half-ass wheel whenever it’s time to spin up a new design system. Standards would create a bare-minimum that teams would be held to. I think it’d go a long way to raise the floor on the quality of systems. Here’s to more standards in 2026.