What is UX debt, and why does it stay hidden?
UX debt is the build-up of design compromises that make a product harder to use than it needs to be. Every quick fix, extra field and bolted-on screen adds a little, but none of it breaks anything, so none of it gets logged as a bug.
It stays hidden because of who uses legacy software. In a consumer app, frustrated users leave and the drop-off shows up in your analytics, but business software is different. IT and procurement chose the system, while the claims handler, the check-in agent and the practice nurse just have to use it. They can’t leave, so they adapt.
Your dashboards won’t catch it either. Uptime, response times and error logs tell you whether the system works, but they say nothing about whether people can finish a task without a workaround.
The cost is real all the same: in a 2025 survey of nearly 2,000 Swiss physicians, 56% said their medical record system doesn’t support patient safety. A finding like that never appears on an uptime report.
What are the 8 signs of hidden UX debt in legacy software?
The eight signs are habits users build to get around legacy software. Each one points to a specific design problem, and none needs new tools to find.
1. Repeat tickets about the same screen
The same screen or field keeps coming up in support tickets because it asks for something users don’t understand or can’t supply. Where to look: tag the last 90 days of tickets by screen. Tickets only show what users bother to report, so the real number is higher.
2. How-to tickets spike after every release
Questions jump after each release and then fade, but the fade isn’t a fix. It usually means users found a workaround, and that changes are shipping without anyone checking the workflow around them. Where to look: ticket volume plotted against release dates.
3. New staff take longer to train each year
Onboarding keeps growing, and trainers end up teaching the order to click things rather than the job. The product now relies on memory instead of what the screen shows. A 2025 study at a Malaysian university hospital found that formal training alone couldn’t fix the design problems in its hospital system. Where to look: onboarding plans and trainer notes.
4. Cheat sheets sit beside the screen
Printed guides, sticky notes and laminated cards of codes mean key steps depend on shortcuts the screen doesn’t show. In aviation, reservations agents using cryptic, command-based systems often keep a card of formats taped to the monitor. Where to look: walk the floor, or ask trainers what they hand out.
5. Required fields are full of “N/A” and “0000”
Users type anything to get past a mandatory field. The form doesn’t fit real cases, so the data downstream can’t be trusted and reports built on it are quietly wrong. Where to look: a database query on required fields.
6. The same data gets typed twice
Staff copy details from one screen or system into another, usually because one job is split across modules or an integration is missing. In banking and insurance back offices, one claim or loan can mean moving between several systems, and every re-keyed field is a chance for an error. Where to look: watch one task from start to finish.
7. One person does a task for the whole team
Everyone sends the same task to the same “expert”. The task is too complex for occasional users, so that person becomes a single point of failure whenever they’re on leave. Where to look: ask team leads who gets asked.
8. Help-page views cluster on one topic
Most help-centre traffic lands on one article, which means one flow is causing most of the confusion. It is often the quickest sign to check and the clearest place to start. Where to look: help centre analytics.
How do you check your legacy software for UX debt?
Check one critical workflow at a time, using the eight signs and data you already have, and a week is usually enough.
- Pick one critical workflow, such as rebooking a flight, writing a consult note or approving a claim. The whole product is too big to judge at once.
- Pull 90 days of support tickets and tag each one to a screen in that workflow.
- Query the workflow’s required fields for placeholder values like “N/A”, “0000” or “see notes”.
- Watch two experienced users and one new starter complete the task without helping them.
- Count the signs. One on its own can be a training gap, but three or more pointing at the same screens usually means the design is the problem.
What should you check before legacy application modernisation?
Before any legacy application modernisation, measure how your critical workflows perform today, so the new version has a number to beat. Most modernisation approaches carry UX debt forward by default:
| Approach | What happens to UX debt |
| Rehost or replatform | Moves across unchanged: same screens, new infrastructure |
| Refactor | Mostly carried over, because the interface is rarely in scope |
| Rebuild | Can be designed out, or copied faithfully if the old screens become the specification |
Rebuilds are the risk teams underestimate. When the old product is the only full record of how work gets done, “same as current” becomes the requirement and every workaround becomes a feature. That’s why it pays to baseline each critical workflow first. Track time on task, error rate and ticket volume, and run a short usability survey such as the System Usability Scale.
This is the job a UX assessment is built for. Each UX assessment looks at one workflow and shows what to keep, what to change and what to simplify before the rebuild locks the answer in.
What if the problem isn’t UX?
A UX assessment still helps when the cause is technical, because it shows which problems come from the design and which come from the system behind it.
Users don’t report problems by cause. To them, a slow integration, wrong data and a confusing screen all feel the same: the task just takes too long. Watching people work through one workflow separates them. An eight-second load time is an engineering fix, and a required field full of “N/A” points to the data model. Three screens doing the job of one is where design comes in.
This matters most before a rebuild. If you redesign the screens alone, the slow integration stays. If you fix the backend alone, the extra clicks move across to the new system. Knowing which is which tells you where to spend the budget.
Sometimes it’s better to wait. If you already know the cause, such as a known integration fault, it makes sense to fix that first. If the product is being retired within the year, the effort is better spent on its replacement. After that, the eight signs will show you what’s left.
Conclusion
Legacy software rarely fails loudly. Its users are patient, so the struggle stays hidden until a rebuild copies their workarounds into the new system. That friction is much easier to find before go-live, which is also the best time to sort design problems from technical ones.
If there’s one workflow your support team keeps explaining, that’s the one worth a UX assessment.
