Micro Design Systems, Seven Years Later
What held up, what changed, and what we'd write today
In 2019 we wrote a post arguing that design systems should be built like microservices — modular, purpose-driven, and composable — rather than as one giant monolith.
Seven years is a long time in this field. Figma has variables now. Design tokens have a W3C spec. Design engineer became a job title with its own conference talks. AI generates components you didn't ask for. And a lot of design system teams that existed in 2019 no longer exist.
So a revisit is overdue. What did the original post get right? What aged? What would we write if we were sitting down today?
What modularity confirmed
The core argument held up. Centralized, one-size-fits-all design systems collapse under their own weight. Every design system we've worked with since has either already discovered this or is on the path to discovering it.
The teams that build their systems modularly — Core primitives, Extensions for brand or domain, Frameworks for product-specific patterns — move faster. They ship more. Their contributors don't have to fight a monolith to add a variant. They can reach for what they need without bringing along everything they don't.
That part of the thesis aged well. What aged differently is how we implement it.
The tokens layer changed everything
In 2019, design tokens were mostly JSON files exported from Figma via plugins, regenerated whenever a designer breathed on them. Implementation was messy. Most teams didn't bother.
Today tokens are a discipline. The W3C draft for design token format, around since 2022, pushed the ecosystem toward a shared definition. Figma shipped variables. Tokens Studio became the default for teams with even moderate complexity. Style Dictionary is the boring backbone nobody talks about that runs in production at enormous scale.
What this enabled is more important than the tooling itself. You can now have one token layer, consumed by multiple brands, multiple products, multiple platforms. The modular argument from 2019 used to terminate at the component level. It now extends all the way down, into the raw values that components compose from.
Which means a micro design system in 2026 isn't three tiers. It's four. Tokens sit underneath everything.
Design engineers moved the line
In 2019 the people maintaining design systems were mostly designers who could prototype in code and engineers who cared about components. The job title "design engineer" existed at Vercel and a few other places but hadn't really caught on.
It has now. And the effect on design systems has been significant. Design engineers don't build systems the way designers build Figma libraries. They build them as code primitives, carefully typed, closely tracking how they're actually used in product code. A design engineer on a team tends to pull the design system closer to the application. The gap between the Figma library and the shipped product shrinks.
This doesn't make the 2019 architecture wrong. It makes it more implementable. The Core/Extension/Framework distinction is clearer when someone is actively policing the boundary in pull requests.
The quiet death of the design systems team
Here's the one we didn't predict.
In 2019, the model was clear. You had a design system, therefore you had a team that owned it. The Material team at Google. The Polaris team at Shopify. The Lightning team at Salesforce. These teams were expected to be permanent, expanding institutions.
Several of them don't exist in the same form anymore. The pattern we've watched play out at multiple companies: the design system team hits a peak in year three or four. After that, the arguments for maintaining a dedicated team get harder. Product teams want to move faster than the central team can review. Central teams calcify. The conversation shifts from "we need a team to own this" to "we need this to stop being owned by a team."
What replaces it is usually a federation. Primitives are owned centrally, by a handful of people. Extensions and Frameworks are owned by the product teams that use them, with a shared review process. The system remains coherent but the ownership is distributed.
This is the 2019 thesis taken to its logical endpoint. If your system is modular, the teams that own it can be modular too.
What we'd write today
If we were writing the original post now, three things would be different.
One: we'd start from tokens, not components. The token layer is the load-bearing part of the system. Components are downstream.
Two: we'd talk about the organization as much as the architecture. The systems that work are the ones where nobody has to ask permission to extend them. Modularity in code, modularity in ownership, modularity in decision-making. One without the others doesn't hold.
Three: we'd take AI more seriously. Not because AI is generating design systems (most of what's been shipped in that space is noise). But because the tedious work of keeping components and tokens in sync across platforms is the exact work AI tools can plausibly do well, and the teams who figure out how to use them without losing coherence will move meaningfully faster.
What still stands
The reason monolithic design systems fail isn't a technical limitation. It's that complex systems always fragment. The only question is whether the fragmentation is planned or accidental. Monoliths fragment accidentally. Modular systems fragment by design.
That part hasn't changed. It won't.
If your design system is pulling in opposite directions — too rigid for product teams, too chaotic for platform teams — the underlying issue is almost always the boundary between what's centralized and what's federated. Happy to talk through how to draw that line for your situation.
