A crowded operations screen can look like an obvious candidate for simplification. Yet removing half its fields could leave an experienced employee opening several windows to finish the same job. For a product owner commissioning legacy product modernization, the first question is which parts of the existing workflow earn their place. The answer requires evidence about the work, including tasks that rarely appear in a polished demonstration.
Here, a legacy product means an established digital product that remains in use while its technology, interaction patterns, or supporting processes need updating. Age alone does not explain its usability. A dated application may support valuable shortcuts; a recent interface may still force people to reenter information. A digital UX design agency needs to distinguish those conditions before proposing what should change.
Table of Contents
Look beyond the screen being redesigned
Commission a review of complete tasks, from the trigger to the point where someone can confidently move on. Include the documents people consult, approvals they obtain, and corrections they make after submission. The UK Government’s guidance on contextual research and observation explains why watching people use their own equipment in their usual surroundings helps reveal barriers and workarounds.
Give the research team access to experienced staff and newer users, including people who use assistive technology. Ask it to investigate disagreements. If a manager calls a field redundant while a caseworker checks it before every approval, the deliverable should explain that dependency. A screenshot annotated with preferences will leave the underlying decision unresolved.
Frequency also needs context. A rare correction may prevent a serious downstream mistake. For each proposed removal, record who uses the feature, what would replace it, and what happens if the replacement fails. That creates a defensible scope for improving legacy product usability.
Hiring a digital UX design agency: brief considerations
Consider a hypothetical invoice system.
Staff export a spreadsheet to compare disputed charges across several accounts. Simply reproducing the export button preserves the current method. Removing it because spreadsheets seem outdated ignores the comparison task. Research may support an accessible comparison view within the product, with export retained where a separate reconciliation process still needs it.
This distinction should shape the digital UX design agency’s brief. State the information and actions a user must retain, then allow the team to explore better ways of providing them. Familiar labels or keyboard shortcuts may merit continuity, while a confusing sequence can change. Require an explanation for both choices.
When considering a partner, Ergomania’s UX services provide an entry point to its discovery, design, and development offering. Use that overview to discuss who would investigate existing workflows and how findings would reach the engineering team. Ask for relevant project evidence before assuming that a broad service offering demonstrates experience with your particular system.
Test continuity as well as improvement
Before approving a new interface, agree on tasks that both the current product and the prototype must support. Include a routine task, an interruption, and an exception selected for their relevance to the operation. Use comparable information and conditions so differences in the test do not obscure differences in the design.
Look at successful completion, consequential errors, requests for help, and the ability to resume unfinished work. Time matters where speed affects the job, but a faster attempt that leaves an incorrect record is a poor result. Examine experienced and newer users separately: an overall average could conceal a substantial loss for one group.
Agree in advance which failures block release. The client’s operational owner should judge whether an essential task remains viable; the agency should show the observed evidence. Where a prototype cannot reproduce permissions or live data behavior, carry that uncertainty into implementation testing rather than treating a successful session as final approval.
Make retirement a separate decision
A staged release needs technical planning. Microsoft’s Strangler Fig pattern describes replacing parts of a legacy system incrementally while the existing application continues operating. It also identifies constraints, including cross-system dependencies and the temporary cost of maintaining transitional architecture. Whether that approach fits is an engineering decision.
For the product owner, the practical implication is to specify how work passes between old and new functions. Someone must own incomplete records, support questions, and recovery if a release goes wrong. A rollback plan must account for data written after launch, not merely restore the previous screen.
Keep the old workflow available only for a defined purpose and period, with evidence required before retirement. Modernization is complete for that workflow when its users can perform the necessary work reliably in the replacement and the team has resolved the dependencies that justified keeping the old version.
