This is the second article in a series dedicated to the redesign of enterprise software. To receive the next ones, subscribe to our newsletter.
In the first article in this series, we described how we approach the redesign of enterprise software: understanding the problems, bringing order to complexity, finding a direction and taking it far enough to test it.
When we work on the redesign of enterprise software, we know that many decisions will be made after handover. New features, unexpected data and technical constraints will put what we designed to the test. Those decisions will mostly be made by the client's team, increasingly with the support of AI agents.
That is why delivering a convincing solution for the cases we know today is not enough. We need to leave behind a system of principles, components and rules that the team can use and extend as the product changes.
The real test comes when the product changes
One of the most dangerous illusions in a redesign is believing that enough detail can eliminate uncertainty. We can explore the main flows, work through edge cases and consult people who know the domain well. This is necessary, but sooner or later something will slip through.
You only need to start building to see it. A field that held a few words in the cases studied has to handle much longer descriptions. A table encounters unexpected combinations of data. A state considered marginal becomes common. A business rule only emerges when the technical team gets into the details of implementation.
Then there is everything that does not exist yet. In six months, someone will add a feature we cannot know about today. In a year, there might be a new module. Another team might start working on the product without having been involved in the redesign.
If every new problem is addressed by looking back at the solutions already designed and finding the closest match, consistency depends mainly on individuals being able to interpret previous decisions correctly. That is a fragile foundation for a product that needs to last.
The point is to make sure that what we have not anticipated can be addressed without starting from scratch every time.
The product needs a memory
During a redesign, we continually make decisions whose value extends beyond the specific case we are working on. We define how the product establishes hierarchies, communicates states, manages information density and makes actions recognisable. Some choices are visual; others concern behaviour or how different parts of the interface work together.
If these choices remain implicit in the solutions we design, they are difficult to transfer. Those who took part in the work can recognise the logic because they remember the discussions behind it. Those who join later mostly see the result.
The design language makes this logic explicit: it defines the principles and rules that give the product a recognisable, consistent language. The design system puts that language into practice, translating it into components, tokens, patterns and documentation that the team can use while designing and developing.
This way, some decisions stop depending on the memory of the people who were there and become part of the product's shared knowledge. A new feature can build on choices already made; when something new is needed, there is a reference point to help determine how it fits into the system.
A good design system therefore allows decision-making to be distributed without losing consistency. This is where it stops being primarily a concern for designers and developers and becomes a product concern.
When design becomes code
Making the rules explicit is a first step. In many projects, it is worth taking the design system all the way to components the technical team can actually use, collected and documented in a component library using a tool such as Storybook.
At Moze, we consider this part of the design work too. Implementing a component forces us to make decisions that may remain more open during design: how it behaves with real content, which variants it should support, which combinations make sense and where it is useful to set limits. It is one of the points where design and technology come closest together. The system stops merely describing how the product should work and starts to exist in the very material the product will be built from.
For the team that inherits it, the difference is tangible. Some design decisions are already built into the components they will use in development, reducing the gap between what was designed and what will actually end up in the product.
Autonomy is part of the outcome
This has become even more important to us in recent years because the way we work with our clients' technical teams has changed.
In the past, it was common for us to design a product and develop much of its front end ourselves. Today, application development is far more often handled in-house. Software companies have mature technical teams and want to keep architecture, code and product knowledge within the organisation. Artificial intelligence is accelerating this shift further, making a growing share of execution more accessible.
Building a system is a form of knowledge transfer. The team receives a direction solid enough to extend without constantly asking the people who designed it how to solve the next case.
For those leading a product, this primarily means reducing a form of dependency. A new designer can join the project and understand existing conventions more quickly. A developer can build a new flow without unknowingly introducing a second way to solve the same problem. The team can discuss exceptions from a shared starting point instead of relying on personal interpretation every time.
There is also a less measurable but very tangible benefit: the peace of mind that comes from knowing the redesign is not a temporary improvement destined to deteriorate as soon as everyday development resumes. The goal should be to leave the client able to keep moving forward without the people who carried out the redesign, rather than dependent on them.
AI agents make the system even more important
Agentic development makes all of this clearer. In a recent project, we built a complete design system and took it all the way to Storybook. The client's team is now using it as a foundation for developing much of the software with Claude Code, at a speed that would have been hard to imagine until recently.
Speed, however, only tells part of the story. What is more interesting is that the agent works within an environment where many decisions have already been made. There are usable components, shared conventions and documentation. When it needs to build something new, it does not have to infer the product's language every time.
This fundamentally changes the value of the system: an agent is very effective when it has a clear goal and reliable context. If that context is weak, greater speed does not solve the problem: it simply allows inconsistent decisions to be produced faster.
The relationship is quite simple: the cheaper execution becomes, the more valuable the rules that guide it become.
This naturally goes well beyond the design system. In agentic development, the quality of specifications, the organisation of the codebase and the ability to verify the result all matter. But the principle is the same: a machine can work with considerable autonomy when its working context has been prepared well.
The design system becomes part of that context. It does more than document the product's appearance: it gives the agent a set of decisions already available to apply as it builds.
This is an interesting consequence because it also changes how we can assess the work done during a redesign. A well-defined system no longer serves only to align the people working on the product today. It can become the shared language between the team and the AI agents supporting them in development.
Designing the ability to change
A design system is not a way to freeze the decisions made during a redesign. That would be pointless, because the product will keep changing anyway.
The system will need to evolve too. Some components will be modified, new needs will introduce new patterns, and certain rules will prove unsuitable for problems we do not yet know about. The difference is that these changes can happen deliberately, within a structure that makes what already exists visible.
This is the value we aim to leave behind after a redesign. A direction clear enough to outlast the project and flexible enough not to become a constraint. A system that allows the team to keep making decisions as requirements, people and even the way software is built change.
The work done upfront helps prevent every increase in speed from simply becoming an increase in entropy. That is why redesign, at least as we understand it today, does not end when we have found a good solution for the product in front of us. It ends when we have given the team the tools to keep evolving it without losing that direction.
That is where a redesign becomes a system.