This is the first article in a series dedicated to the redesign of enterprise software. To receive the next ones, subscribe to our newsletter.
Over the years we have worked with service companies that develop and maintain proprietary software, B2B SaaS platforms, and complex digital products. Solid products, often built over years of work, that continue to generate value but are starting to show a different problem: they no longer communicate the true quality of the solution.
In this article, we try to bring order to what we have learned: why redesign becomes necessary, where projects risk slowing down, and which tools help build a shared direction more quickly.
The moment when redesign becomes necessary
The first sign that an enterprise software product needs to be reconsidered often comes from the sales team. It happens when, during a demo, someone systematically avoids certain screens, when the conversation keeps shifting toward what the product will do in the future rather than what it can do today, or when a prospect simply observes that the software looks outdated.
It is a situation we see often. Nobody loses a deal because a button is ugly or because a table uses a font that feels a little dated. Opportunities start to fade when the product communicates complexity, slowness, and rigidity while the market expects simplicity. At that point the problem is no longer aesthetic, it is competitive.
Interestingly, redesign rarely starts as an independent initiative. In most cases, it comes as a consequence of something much more concrete: a replatforming project, a technology migration, or the need to modernize software that has become increasingly difficult to maintain and evolve over the years. At that point, an unavoidable question emerges: if we are investing months of work to rebuild the platform, does it really make sense to rebuild the same problems too?
Context changes faster than software
Many enterprise software products are the result of years, if not decades, of evolution. Every new feature, integration, or commercial request has left a trace in the product. In most cases, those decisions were correct at the time they were made. The problem is that software keeps accumulating history while the world around it changes.
In recent years, we have seen a significant shift in user expectations. People use digital products every day that constantly raise the bar for simplicity, clarity, and speed. It does not matter whether they are consumer products, productivity tools, or new SaaS platforms. When a product shows that an experience can be more intuitive, that expectation immediately carries over elsewhere.
This phenomenon is visible across many industries. In recent years, products have emerged that are capable of redefining user expectations; not necessarily because they offer revolutionary features, but because they present complex processes in a simpler and more accessible way. When this happens, users unconsciously begin to compare every other experience with that new standard.
Artificial intelligence is accelerating this process even further. For years, we asked people to adapt to software. Today, we are starting to see software that tries to adapt to people, suggesting actions, reducing repetitive tasks, and simplifying access to information. We are not yet at a complete paradigm shift, but the direction is clear.
For this reason enterprise software no longer competes only with its direct competitors. It competes with the expectations generated by any modern digital experience. It is no surprise that UX and usability are increasingly present in selection processes, tender documents, and comparative product evaluations.
Endless research does not reduce risk
When a company decides to approach a redesign, the first reaction is almost always the same: reduce risk. Workshops, interviews, alignment sessions, analysis activities, and requirements-gathering exercises are organized. These activities are useful and often essential. It would be naive to argue otherwise.
The problem begins when a very common belief takes hold in enterprise projects: the idea that sooner or later there will be a moment when everything is clear enough for the project to start without uncertainty.
That moment simply does not arrive.
Enterprise software products are complex organisms. There are processes nobody has documented, exceptions that emerge only in specific situations, business rules layered over the years, and technological dependencies that become visible only when you go into the details of individual features. Trying to understand every aspect of the system before starting to design often means chasing an unreachable goal.
We have seen organizations spend months trying to eliminate every possible area of uncertainty. The consequence is that the project keeps accumulating documentation while decisions are postponed. After a certain point, every new workshop produces less and less marginal value. To put it less elegantly: after the tenth workshop, you are no longer reducing uncertainty; you are producing increasingly accurate documentation of the fact that the project has not started yet.
This does not mean that understanding is less important. It means its goal should be different. Do not understand everything. Understand enough to choose a direction.
Working like it is 2020 is an expensive luxury
In this scenario, artificial intelligence is radically changing how we approach the early phases of a project. Not because it replaces research, design, or strategic decisions, but because it drastically reduces the cost of understanding.
Until a few years ago, it was normal to spend entire days listening back to workshops, organizing notes, synthesizing insights, and building documentation. Today we can record a session, transcribe it automatically, and use AI tools to identify recurring patterns, shared pain points, areas of disagreement, and emerging themes. We can turn hours of conversations into navigable and searchable knowledge in a fraction of the time.
The same applies to existing documentation. Functional specifications, manuals, screens, video recordings, and operational processes can be analyzed much faster than in the past. We can explore specialist domains, investigate design alternatives, and work on microcopy at a speed that would have been difficult to imagine only a few years ago.
The most interesting aspect, however, is something else. AI does not eliminate the need to understand the problem. It removes a significant part of the friction required to understand it. This allows teams to spend less time collecting information and more time on the decisions that have a real impact on the product.
Quickly finding a shared direction
If we accept that complete understanding is impossible and that technology allows us to accelerate many preliminary activities, the way we approach a redesign also changes.
In our case, we prefer to start with focused, highly pragmatic workshops, usually lasting one or two days. The goal is not to collect every possible detail about the system. It is to quickly identify enough problems, goals, opportunities, and constraints to build a first shared vision.
From there, we move quickly into building a high-fidelity concept. This is probably one of the clearest differences compared to more traditional approaches. Many organizations are used to thinking that design begins only after a long analysis phase. We tend to consider the prototype as a tool for understanding.
When people see something concrete, the quality of the conversation changes radically. Details emerge that would never have appeared in a meeting, constraints that nobody had considered become visible, and opportunities that had remained hidden until that moment come to the surface. Many of the most useful observations we collect during a project come precisely in front of a prototype.
That is where someone says that the process works differently than expected. That is where a forgotten business rule emerges. That is where it becomes clear that the problem initially perceived was not the real problem.
For this reason, we consider the concept not only as a presentation tool, but as a discovery tool. Once the general direction is shared, the work can be divided into flows, functional areas, and more focused initiatives, progressively deepening what truly matters.
Why a design system accelerates the work
Another element that helps accelerate the process is the presence of a design system. It is often perceived as a topic related exclusively to governance or visual consistency, but in practice its impact is much broader.
When there is a shared system of components, patterns, and rules, the team can focus on the problems to solve instead of constantly reopening the same interface discussions. Many decisions are made once and then reused consistently throughout the product.
Without a shared system, every screen risks becoming a new discussion. Every component is reinterpreted, every flow develops exceptions, and every decision has to be reconsidered. With a well-built design system, many of these choices are made once. This frees time and energy to focus on what truly matters: user problems and business goals.
This makes design more fluid, more systematic, and faster. In some cases it even makes it possible to reduce the reliance on traditional wireframes, working directly on high-fidelity solutions and accelerating alignment with stakeholders and users.
A design system is therefore not an activity that slows the project down. It is one of the tools that allows the project to move faster.
Users are almost always right
None of this means ignoring end users. On the contrary, when the context allows it, directly involving the people who use the product is one of the strongest quality multipliers available.
In our experience, there is almost always a gap between what stakeholders believe they know and what users are actually trying to achieve. Not because there is a lack of expertise or domain knowledge, but because very often companies observe the symptoms while users experience the problem.
It is a subtle but important difference. Organizations tend to ask for a new interface, a different navigation, or an additional feature. Users, instead, are trying to complete a task, avoid an error, reduce the time needed to carry out a process, or simply work with less friction.
This is why activities such as Jobs To Be Done can be extremely useful in the early phases. They help understand goals, priorities, and real needs before discussing possible solutions. Later, concepts and prototypes can be validated directly with end users, turning research into a continuous learning tool rather than an isolated phase at the beginning of the project.
Time and budget do not always allow us to do everything we would like. But when we are able to include users in the process, the quality of decisions improves significantly.
Understanding by design
In contemporary enterprise software, redesign is no longer just an aesthetic exercise. Nor is it a long preliminary analysis process. It is a progressive process that combines business, technology, research, design, and AI tools to quickly build a shared direction and improve it over time.
The most effective projects do not try to eliminate uncertainty completely before starting. They build understanding as the product takes shape. They use prototypes to make decisions, systems to accelerate the work, and research to verify that the direction is correct.
Finding a direction, however, is only the first step. Once a shared vision has been defined, the next challenge is to make it coherent, scalable, and sustainable over time. This is where design language, design systems, and collaboration between design and development come into play.
We will talk about this in the next article.
Because modernizing software does not mean rebuilding the past with new technology. It means using every intervention to reduce complexity, increase clarity, and build a product capable of evolving faster than the context in which it operates.
This is the first article in a series dedicated to the redesign of enterprise software. To receive the next one, subscribe to our newsletter.