Legacy constraints

Modernizing without starting over

I led the discovery and redesign of a case management product inside a large ERP system. An ERP connects much of a company’s daily work, including customers, orders, inventory and support. That made this case tool more than an isolated interface. People depended on it to resolve real customer problems, and changes could affect several connected parts of the business.

The product had been built long before modern UX practices and had accumulated years of complexity. Information was spread across tabs. Creating a case meant facing a long form. Important behaviour depended on an old database structure that we could not simply replace.

The challenge was not to make the interface look newer. It was to make the work easier without breaking what support reps already relied on.

1. Understanding the system before changing it

There was no agreed definition of the problem or plan for what to improve first. Different teams understood different parts of the product, and some important rules were not documented anywhere. We found them in interviews, when support reps explained why they moved between screens or finished parts of the work outside the product.

I took ownership of framing the work. I brought product, engineering and design-system partners together to map what we knew, what we still needed to learn and which decisions belonged to each team.

I reviewed previous research, mapped every step from opening a case to closing it and interviewed support reps using the product. I wanted to understand more than which screens were frustrating. I needed to see what information people looked for at each step and where the product stopped helping them.

The research showed that most of the friction happened at two moments:

• Starting a case required too much information too early.
• Understanding an existing case meant reconstructing its history across several views.

These became the first priorities. Improving them would help support reps immediately and give the rest of the product clearer ways to handle forms and case history.

2. Working inside constraints that would not disappear

The redesign had to run on the old software and data structure behind the interface. Much of that could not change. Support reps also needed to move gradually between the old and new experiences instead of switching everything at once.

At the same time, the company’s new design system was still young. This was the shared library of buttons, fields and standard ways of handling common actions across the product. It did not yet include many of the pieces needed for a case-management workflow with a lot of data and activity.

This meant every proposal had to answer two questions:

• Can we build this safely with the system we have now?
• Does it move us towards a better product, or simply reproduce the legacy interface in a new visual style?

I worked closely with engineers to separate hard limitations from things we could change safely. I also partnered with the design-system team when we needed a shared way to present information that did not exist yet.

3. Making it easier to start a case

The legacy creation form exposed almost everything at once. Support reps saw many fields before they had enough context to answer them. Some requirements were unclear, and reaching a dead end often meant losing momentum or submitting incomplete information.

The straightforward migration would have been to restyle the same form. I chose to ask for less information upfront instead.

I worked with the team to identify the minimum information required to create a valid case. The new flow grouped those inputs into three focused sections and automatically filled customer information the system already knew. Less urgent details could be added after the case existed.

This made the first step shorter without weakening the record. The product still captured the information it needed, just at the moment when the support rep could provide it.

4. Putting the full case story in one place

Once a case existed, the next problem was understanding it.

Messages, notes, status changes and system events lived in different tabs and sub-tabs. Several people might work on the same case. Before replying to a customer, a support rep had to jump between views and piece together what had happened, what was still pending and who was responsible.

I proposed bringing that activity into one chronological timeline.

An early timeline already existed in the shared design library, but it was too simple for this product. I worked with its designers to extend it so it could show customer messages, internal comments, status changes and automated actions while keeping each type easy to recognise.

This was not only a layout change. It created one shared history that support reps could read from beginning to end. It also gave other product areas a reusable way to show activity over time.

What changed

• Roughly half as many inputs upfront: In the simplified comparison, the initial view went from around 25 visible inputs to about 13, organised into three focused sections. Customer details were filled automatically, and secondary information could be added later.
• Activity from four separate places became one readable history: Support reps no longer had to move between different parts of the product to understand what had happened. Everything appeared in one chronological timeline.
• Less repeated communication: Support reps could see what had already happened before replying, reducing the need to repeat questions or reconstruct the case elsewhere.
• Higher use of the new experience: More support reps moved to the redesigned product, and teams relied less on external tools to manage the same cases.
• One shared timeline used across multiple product areas: The new timeline was added to the company’s shared design library instead of remaining specific to Case Management.

What I learned

The most important work happened before and between the screens.

Writing down assumptions and unresolved questions helped product, design and engineering disagree earlier, before those disagreements became expensive changes. Owning the work from research and deciding what to tackle first to the detailed screens made it easier to see how one decision affected the whole case workflow.

The young design system initially looked like another constraint. Working closely with its team turned it into an advantage. Case Management helped improve the shared timeline, and the improved timeline made this product and others easier to build consistently.

The project did not remove the legacy underneath. It found the changes that could make the product meaningfully better now without closing off what it could become later.