This year marks five years since three of us at Danfoss sat down and decided to build a company-wide design system. There was one person from design, one from business, and one from development. That was the beginning of Mosaic.
I want to say thank you to Freddy and Jacob. And to everyone who joined the work after us and made the system what it is today.
Five years is a good moment to pause. And right now there is a question worth pausing on — because I keep hearing it, and I do not think it has been answered well yet.
Do design systems still matter in the age of AI?
AI can generate interfaces. It can produce screens, components, and layouts faster than any designer. So the question is reasonable. If the machine can build it, what is the system for?
I want to answer that question through the same three perspectives we started with. Because I think the answer is different depending on where you sit — and I think each answer matters.
For business
When we started Mosaic, the business case was straightforward. Consistency across products. Faster time to market. Less duplicated work. One set of decisions made once, instead of the same decisions made fifty times by fifty different teams.
That case is still true. But in the age of AI, it becomes more urgent.
AI is making it faster and cheaper to build interfaces. This is genuinely exciting. But speed without direction produces divergence. Teams using AI to ship quickly will produce things that work in isolation and conflict with each other at scale. A customer moving between products will feel it — something slightly different each time, a brand that does not quite cohere.
Speed without direction produces divergence. The design system is what prevents that.
The design system is what prevents that. It is not a constraint on speed. It is the thing that makes speed sustainable. You can move fast because the decisions are already made. The tokens, the components, the interaction patterns — they are there. The AI uses them. The team trusts them. The product stays coherent.
There is also something else that matters to business, and I think it is underappreciated. A design system encodes standards — accessibility, security patterns, compliance requirements. Fix a violation once in the system and it stops appearing across every product. Ignore it, and every team building with AI will reproduce the same problem at scale. The system is governance. In the age of AI that is not a bureaucratic concern. It is a practical one.
For development
When we started Mosaic, one of the clearest wins for development was reducing the decision surface. Developers should not have to decide whether a button is 36px or 40px. That decision should exist somewhere reliable, so they can focus on the logic that actually requires engineering judgment.
That is still true. But the relationship between development and design systems is changing.
AI coding tools are now capable of generating component code, handling token integration, writing documentation. A lot of the implementation work that once lived with developers is becoming automated. The developer’s role in the design system is shifting — less about manually building and maintaining the library, more about defining the architecture that makes automation possible.
This is actually a better job. The interesting question is not how to implement the button. It is how to structure the system so that AI can implement anything correctly, every time. That is a systems problem. It requires the kind of thinking that good developers are excellent at, and that AI cannot yet do on its own.
There is also the question of integration. The most practical way to connect a design system to an AI workflow right now is through something like an MCP server — feeding tokens, components, and rules directly into the generation context. The AI does not guess what your interface should look like. It knows. This is an engineering problem. It requires someone who understands both the system and the toolchain. That is still very much a human job.
For design
This is the one I feel most personally. And I want to be honest about what has changed and what has not.
When we built Mosaic, one of the hardest things to convince people of was flexibility. A design system should not prescribe the interface. It should give you the vocabulary to build one. I proposed the name Mosaic deliberately — when you look at a mosaic you do not see the tiles. You see the image. The pieces are small. The guidance is clear. What you make with them is yours.
I still believe this. And I think AI makes it more important, not less.
Because here is what happens without it. AI generates an interface. It is technically fine. It uses some components that look roughly right. But it does not feel like your product. It does not carry the voice you have spent years building. It is generic in a way that is hard to articulate and immediately felt.
The design system is the answer to that. It is the part of the prompt that says: this is how we speak. These are our words. This is how we use space, how we use colour, what we mean when we say a component should feel light or grounded or urgent. That cannot live in a prompt. It lives in the system.
Language means we share the same words. It does not mean we use the same sentences. Every interface is different because every task is different.
There is a metaphor I keep returning to. We call it design language for a reason. Language means we share the same words. It does not mean we use the same sentences. Every interface is different because every task is different. The design system gives us a shared vocabulary and a consistent voice. What we say with it is still designed. It is still ours.
The role of the designer in relation to a design system is also shifting. Less time on documentation and maintenance — AI can help with that. More time on what the system should become. Listening to the teams using it. Deciding which new patterns matter. Making the judgment calls about whether something is truly a new component or a misuse of an existing one. These are not decisions a model can make well. They require someone who understands the intent behind the system, not just its contents.
The thing all three perspectives share
I said I wanted to give equal weight to business, development, and design. But there is something underneath all three that I have not named yet.
A design system is a product. It serves people. And if the people it serves — designers, developers, product owners — do not feel heard, the system stops being used. Not because it is technically wrong. Because it stopped feeling like something built for them.
This is as true now as it was five years ago. Maybe more true, because the pace is faster and the alternatives are more available. A team that feels underserved by the design system will work around it. With AI, working around it is easier than ever.
So the job of the design system team is still, fundamentally, a service job. Meet with your users. Listen to what they need. React to feedback. Promote the system actively — do not assume adoption happens on its own. Make the right thing easy to use, not just available.
Automation can help here too. The more you automate the maintenance work, the more time you have for the work that actually requires people. Let machines handle consistency. Let people handle direction. That division has always been true in design. It is just more visible now.
Looking forward
I did not know, five years ago, that we would be having this conversation. That the question of whether design systems matter would be complicated by tools that can generate interfaces from a sentence.
But I think the question has a clear answer. Design systems matter because AI needs a reference. Without one, it produces something generic — functional but forgettable, consistent with nothing, belonging to no one. The design system is what tells the AI what you sound like. What you value. What your product is trying to be.
Design systems matter because AI needs a reference. Without one, it produces something generic — functional but forgettable, consistent with nothing, belonging to no one.
They matter because consistency at scale still requires shared decisions made in advance. That has not changed. The speed has changed. The stakes of inconsistency have, if anything, gone up.
And they matter because the teams building products deserve a resource that evolves with them. That is honest about what it is for. That treats them as users, not just consumers of components.
Mosaic started with three people and a shared belief that a common design language would make Danfoss better at building products. I still believe that. And I think what those five years actually taught us is that the system was never really about the components. It was about the collaboration that made the components possible.
That part does not get automated.