🔗 Why Federated Design Systems Keep Failing from Shaun Bent
A nice read on how to run design systems in teams, and some insights on how Spotify did theirs (and where they failed haha)
Essentially: it does seem like if you’re building a design system and you want it to grow meaningfully—meaning, every update to it is something other teams would use and is not just fluff to pad the system with more components and documentation no one would use—it’s better to adopt a more centralized approach for the most part.
Initially I was of the impression that federated design systems would work out of the bat, it’s all in the way we set up the workflows and the systems, it’ll work for sure, but reality shows otherwise.
I understand the frustration of working on the design system only for it to amount to nothing but a shared component library in Figma that developers don’t look at. Designers and developers really have to work hand-in-hand when setting up the foundations of a design system, be it two people working together or the tasks merged into one person (though that would be harder and skillsets may vary) because documentation can only get you so far if it’s talking about things that need to be implemented.
The frustration compounds if no one is actually in charge of the design system and instead it’s delegated to “everyone”—whoever that would include—so what happens is no one takes the reigns. Even if someone did, when they leave… what happens then?
Reading this made me think of the thing Syndrome said to Mr. Incredible in the Incredibles, and thus I give you this meme to end this post:
