Imagine a Formula 1 team that improves its car after every race.
Engineers add a new control for tire management. Another button appears for energy recovery. A new setting is introduced for changing track conditions, followed by another for launch configuration. Every addition has a valid purpose, and technically, every control works exactly as designed.
Now imagine nobody ever steps back to redesign the steering wheel.
After several seasons, the driver is surrounded by controls introduced by different engineers at different times. Some functions use similar buttons but behave differently. Important settings have become harder to find under pressure, and actions that once required one movement now require several.
The car has become more capable.
The experience of operating it has become worse.
Long-lived applications often develop in exactly the same way.
A product may launch with a clear navigation structure and a handful of simple workflows. Then customer requests, new business rules, acquisitions, integrations and years of feature development begin layering new decisions onto the interface.
A new reporting module introduces its own filtering pattern. One team calls an action Archive while another calls the equivalent action Remove. Settings spread across several screens. A workflow that once required three decisions now asks for seven because every new requirement was added to the existing journey rather than reconsidering the journey itself.
Nothing has to be technically broken for the product to become harder to use.
In fact, this kind of deterioration often happens precisely because the product keeps improving. Each individual feature makes sense, but the accumulated experience becomes increasingly difficult to understand.
That is why user experience needs maintenance.
UX maintenance is the ongoing work of identifying and removing the friction, inconsistency, complexity and outdated assumptions that accumulate as an application evolves.
The goal is not to keep redesigning the product for aesthetic reasons. It is to make sure that as the application becomes more capable, it does not simultaneously become more difficult for users to operate.
The Nielsen Norman Group's work on UX debt describes how usability problems, inconsistent interaction patterns, content issues and other experience compromises accumulate over time, particularly when teams repeatedly prioritize fast delivery over resolving existing experience problems.
For Levelworks, UX maintenance primarily supports User Friendly & Delightful App Health. But it is not about endlessly polishing an interface or making cosmetic improvements. The purpose is much more practical: preserving users' ability to understand the application and complete important work efficiently as the software changes around them.
Poor UX is not always created by poor design.
Often, it appears gradually as a by-product of successful product development.
Imagine the original account screen contains:
A year later, customers request permissions.
Then audit history.
Then integrations.
Then usage limits, workflow settings, API keys and data-retention controls.
Each feature may be well designed independently.
The accumulated experience can still become difficult because users now have to understand how all nine areas fit together.
This is one of the central challenges of UX maintenance:
local improvements do not automatically create a coherent overall experience.
Product development usually happens feature by feature. Users experience the application end to end.
Without periodic review, the gap between those perspectives widens.
Technical teams are familiar with technical debt: shortcuts or compromises that make future engineering work harder.
UX debt works similarly.
The Nielsen Norman Group defines UX debt as ongoing problems in the experience caused by earlier design decisions or compromises. It can accumulate in interface elements, interaction patterns, content, information architecture, accessibility and consistency across a customer's journey.
Consider a sequence of individually reasonable decisions:
A new button is added quickly before an important release.
Another team creates a slightly different version because the original component does not quite meet its requirement.
A third workflow uses another label for the same underlying action.
A fourth team introduces a modal with different confirmation behavior.
Months later, users encounter four interaction patterns for essentially the same task.
There was no single moment when the UX became inconsistent.
The inconsistency accumulated.
Common sources of UX debt include:
Some UX debt is a reasonable trade-off. A business may genuinely need to ship quickly.
The maintenance mistake is not creating any UX debt.
It is creating it and never returning to it.
The users you designed for at launch are not necessarily the users you have three years later.
Early customers may have been technically sophisticated adopters. Later customers may expect more guidance.
A product originally used by small teams may now be deployed across large organizations with administrators, managers and occasional users who have very different goals.
The business itself may also evolve.
A workflow designed around one product tier may become confusing after several new plans and permissions are introduced.
This is why user research should continue after launch.
The UK Government Service Manual's guidance for live digital services explicitly recommends ongoing research to understand evolving user needs, assess how people experience the service, and evaluate newly introduced features and improvements. It suggests combining analytics, support-ticket analysis, surveys, interviews and usability testing rather than assuming the understanding developed during initial design remains permanently correct.
GOV.UK: User research in live services
Launch is therefore not the end of UX research.
It is the point at which the application finally begins generating evidence from real, sustained usage.
A feature can be useful and still damage an existing workflow.
Suppose submitting an expense originally requires:
Later, the organization introduces:
Each addition has a valid business purpose.
But if every requirement simply becomes another field in the original form, a four-step task gradually turns into a dense administrative workflow.
UX maintenance asks a question feature delivery often does not:
Now that all these requirements exist together, should the workflow still be structured this way?
Perhaps some values can be inferred.
Maybe project allocation is needed only for particular users.
Perhaps approval routing can happen automatically from existing account information.
UX maintenance therefore is not just fixing old mistakes. It is periodically reconsidering the experience created by years of otherwise legitimate product decisions.
A backlog containing comments such as:
"The dashboard is confusing."
is useful evidence, but not enough to diagnose the problem.
Product analytics can reveal where friction is occurring.
Depending on the application, useful signals may include:
The GOV.UK guidance on service performance recommends combining performance data with user research. For example, analytics may reveal where users abandon a transaction, while research can help explain why they abandon it.
Analytics identifies patterns.
Usability research explains behavior.
Neither should replace the other.
A user may spend eight minutes on a page because the task legitimately requires eight minutes—or because they cannot understand the interface. The number alone cannot tell you which.
Teams often evaluate UX subjectively:
"The new version feels cleaner."
That is difficult to maintain over several years.
For important user journeys, establish simple usability benchmarks.
The GOV.UK Service Manual's usability-benchmarking guidance recommends periodically testing representative tasks and tracking measures such as whether users complete them successfully, how long completion takes and whether users perceive the task as easy or difficult.
GOV.UK: Usability benchmarking a service
For example:
Task
Completion rate
Median time
Common difficulty
Invite a team member
96%
42 sec
Role terminology
Create monthly report
81%
3m 10s
Filter configuration
Change billing contact
68%
2m 35s
Users look under Account instead of Billing
Export transactions
93%
55 sec
Minor
Run the same tasks periodically.
If creating a report becomes progressively slower as new options are introduced, the decline becomes measurable rather than anecdotal.
The Nielsen Norman Group similarly recommends task success as one of the simplest usability metrics and describes benchmarking as a way to compare experience quality over time or before and after redesigns.
Nielsen Norman Group: UX benchmarking
Support teams frequently know about experience problems long before a UX backlog reflects them.
Consider tickets such as:
"Where do I change the invoice email address?"
"Why can't I edit this order?"
"I thought deleting the project would only remove it from my dashboard."
Individually, they look like support requests.
Repeated frequently, they are usability evidence.
A maintenance team should regularly look for:
The GOV.UK guidance for live user research explicitly includes analysis of support tickets as a way to identify problems users are having with a live service.
The objective is not to eliminate every support request.
Some domains are inherently complex.
But if hundreds of people ask the same question because the interface repeatedly communicates something poorly, answering the ticket is treating the symptom.
UX maintenance should address the source.
[Internal Link: “What Does Good Post-Launch Application Support Look Like?”]
Navigation often reveals product age.
A young application might have:
Dashboard
Customers
Orders
Reports
Settings
Years later:
Dashboard
Customers
Accounts
Contacts
Orders
Subscriptions
Products
Analytics
Reports
Automations
Integrations
Administration
Settings
Developer
Every addition may have been reasonable.
The resulting navigation may not be.
Users do not care which product team built a feature. They need to know where functionality belongs within their mental model of the application.
Periodic UX maintenance should therefore examine:
Sometimes the answer is renaming.
Sometimes several areas should be consolidated.
Sometimes the product's original information architecture simply no longer represents what the application has become.
Experience inconsistency is not limited to buttons and colors.
Language drifts too.
One screen might say:
Customer
another:
Client
and a third:
Account
Perhaps those genuinely represent different concepts.
If they do not, the application has imposed unnecessary interpretation work on its users.
Similar problems appear with actions:
Content standards belong in UX maintenance because users build understanding through repeated language patterns.
The Nielsen Norman Group's guidance on content standards in design systems argues that design systems should include content guidance alongside visual components so that interface language remains consistent as products scale.
Nielsen Norman Group: Content standards in design systems
A terminology review can therefore produce surprisingly large usability improvements without changing underlying functionality.
Design systems are often introduced to prevent UI drift.
They do not maintain themselves.
A product may begin with one approved button, modal and form pattern. Teams then encounter edge cases, create local variations and gradually bypass components that no longer meet their needs.
A few years later, the design system technically exists while the application contains several competing implementations.
The Nielsen Norman Group defines a design system as a set of standards used to manage design at scale through reusable patterns and components. Its more recent guidance emphasizes that consistency still requires active stewardship; standards alone do not stop teams from diverging over time.
Nielsen Norman Group: Design Systems 101
UX maintenance should therefore include:
Otherwise every feature team slowly creates its own application inside the application.
Users develop expectations.
If the primary action appears in the same place and uses the same visual hierarchy across workflows, users learn that pattern once.
If every module behaves differently, users repeatedly stop to interpret the interface.
The Nielsen Norman Group's consistency heuristic emphasizes that users should not have to wonder whether different words, situations or actions mean the same thing. Its guidance also notes that consistency requires active review because discrepancies naturally emerge as different teams extend a product over time.
This is why maintenance teams should periodically conduct cross-product consistency reviews instead of evaluating screens only in isolation.
The question is not:
Does this screen look reasonable?
It is:
Does this screen behave like the rest of the product where users reasonably expect it to?
A workflow can be visually elegant and still feel poor if every action hesitates.
UX maintenance therefore needs awareness of real interaction responsiveness, although detailed performance optimization belongs elsewhere.
For web applications, Google's current Interaction to Next Paint (INP) guidance describes responsiveness in terms of how quickly the page provides visual feedback after user interactions. INP observes interactions across the page lifecycle rather than considering only initial loading.
web.dev: Interaction to Next Paint
This matters because users experience performance through interaction.
A dropdown that takes a second to open may cause repeated clicks. A filter that freezes the screen can make users think the interface is broken, even when the underlying request eventually succeeds.
UX reviews should therefore consider whether frequently used interactions feel responsive as the application's frontend becomes more complex.
Detailed diagnosis belongs to performance maintenance, but the resulting user friction belongs in the UX conversation.
Teams naturally design the happy path first.
Long-lived applications expose many more unhappy paths:
These experiences frequently receive less design attention because they occur outside the normal successful workflow.
Yet this is precisely where users need the interface to be clearest.
An error message such as:
Request failed. Code 409.
may be technically accurate and operationally useless.
A maintained experience should answer, where appropriate:
Error-state maintenance often produces high-value improvements because it reduces the moment when technical system behavior becomes the user's problem.
Product teams are good at adding.
They are often less disciplined about subtraction.
Over time, applications accumulate:
Every additional interface element competes for attention.
UX maintenance should therefore ask not only:
What should we improve?
but:
What should no longer be here?
Deletion can be one of the highest-value forms of UX maintenance because it reduces the amount of product users have to understand.
This should be evidence-based rather than cosmetic. Low usage does not automatically make a feature unnecessary; some low-frequency actions are business critical. Combine usage data with customer context before removing anything.
Applications increasingly adapt interfaces based on:
This flexibility is useful, but it can make UX maintenance harder.
Two customers may effectively use different versions of the product.
When experiments finish or features graduate from limited rollout, clean up the temporary variants. Otherwise the interface accumulates historical branches that nobody fully understands.
The same principle applies to feature flags: flags that become permanent without deliberate design review can leave different users following inconsistent workflows long after the original experiment ended.
Maintenance should periodically ask which variations are still intentional.
Accessibility deserves its own maintenance discipline, and it has a dedicated Levelworks article, so it should not be reduced to a subsection of general UX work.
There is nevertheless an important overlap.
Adding new components, interaction patterns or content can introduce new barriers even if the original product was accessible.
The W3C notes that accessibility and usability overlap significantly, while emphasizing the specific requirement to include people with disabilities and their needs rather than treating general usability as a substitute for accessibility.
W3C: Accessibility, Usability and Inclusion
UX maintenance should therefore coordinate with accessibility review whenever meaningful interface changes are introduced.
[Internal Link: “Accessibility Maintenance: Keeping Your App Usable as It Evolves”]
Once teams begin auditing an older application, the backlog can become enormous.
Do not prioritize everything equally.
A practical prioritization model considers:
How often do users encounter the problem?
Does it create slight confusion, or prevent task completion?
Does it affect a peripheral setting or a core business workflow?
Does it affect a small specialist group or almost every customer?
Is the issue supported by analytics, usability research, support data or repeated observation?
A simple scoring view might look like:
Issue
Frequency
Severity
Journey importance
Priority
Confusing checkout validation
High
High
Critical
Immediate
Inconsistent icon in settings
Medium
Low
Low
Low
Hidden export action
High
Medium
Important
High
Old terminology on admin page
Low
Medium
Medium
Medium
This prevents UX maintenance from becoming endless cosmetic cleanup.
The goal is to reduce friction where it affects users meaningfully.
A redesigned workflow can look more elegant to the team and still perform worse for users.
That is why UX maintenance should close the loop.
If analytics showed that users abandoned a workflow at Step 4, measure abandonment again after the redesign.
If usability testing showed that people could not find an export function, test whether they can find it now.
If support repeatedly received one question, determine whether those tickets decline after the change.
The GOV.UK usability-benchmarking guidance explicitly recommends repeating the same usability measures periodically so teams can compare whether services are becoming easier to use.
Maintenance should therefore follow a cycle such as:
Observe friction
↓
Investigate why
↓
Prioritize
↓
Improve
↓
Test
↓
Measure production result
↓
Repeat
Without that final validation, UX maintenance becomes opinion-driven redesign.
Not every UX problem needs a special audit.
Some should be fixed continuously as they appear through customer feedback, design review and feature work.
Other issues become visible only when the product is evaluated as a whole.
A useful cadence has two layers.
During normal product development:
At wider intervals:
The Nielsen Norman Group specifically recommends recurring product-team reviews of UX debt and periodic consistency reviews because inconsistencies naturally accumulate despite design standards.
This combination prevents minor friction from waiting years for a redesign while still creating opportunities to detect system-level experience problems.
Large redesign projects are tempting because they promise to solve accumulated experience problems all at once.
They also carry significant risk.
Users have learned the current product. Business workflows depend on it. Teams may redesign areas that already work while overlooking the specific friction causing real problems.
Often, the safer maintenance strategy is incremental.
Improve the confusing form.
Consolidate duplicated components.
Simplify the navigation area where research shows users struggle.
Replace outdated terminology.
Remove the obsolete setting.
Then measure whether the experience improved.
A complete redesign may eventually be justified, but UX maintenance should not stop while everyone waits for that project to happen.
Small, evidence-based corrections prevent the debt from compounding further.
A common reason UX deteriorates is structural.
The roadmap contains features.
UX problems live somewhere else.
If maintenance work has no capacity allocation, feature development wins every prioritization meeting because its business value is easier to describe.
Treat UX maintenance items with the same discipline as defects and engineering debt.
A useful UX maintenance backlog records:
For example:
Problem: Enterprise administrators frequently fail to locate audit exports.
Evidence: Search analytics, usability sessions and support tickets.
Impact: Delays a compliance workflow.
Target: Increase task-success rate during benchmark testing and reduce related support contacts.
Now UX maintenance is no longer “make the screen nicer.”
It is a measurable product-quality problem.
When reviewing a mature application, ask:
Area
Maintenance question
Core tasks
Can users still complete important journeys efficiently?
Navigation
Does the information architecture still represent the current product?
Consistency
Do similar actions use similar patterns?
Content
Is terminology clear, current and consistent?
Design system
Are teams actually using maintained shared components?
Errors
Do failure states explain what happened and what to do next?
Performance perception
Do important interactions respond quickly enough to feel reliable?
Product clutter
Are obsolete controls or content still competing for attention?
Feedback
What recurring problems appear in research and support?
Measurement
Can important usability tasks be compared with previous benchmarks?
The purpose is not to generate another checklist that is completed once and forgotten.
These questions should help identify where the current application experience differs from the experience the organization thinks it has.
Users rarely distinguish among design, frontend engineering, product management and maintenance.
They experience one product.
A confusing permission screen, slow interaction, inconsistent form, obsolete instruction or impossible-to-find feature all become part of their judgment of the application.
That broader customer-experience impact deserves its own discussion, particularly because poor experience can eventually influence adoption and retention.
[Internal Link: “How App Maintenance Affects User Retention and Customer Experience”]
The narrower point here is that usability itself is not permanent.
An application can launch with an excellent experience and gradually lose it through accumulated features, inconsistent patterns, outdated content and changed user needs.
Software maintenance traditionally focuses on whether the application continues to operate.
Are services available?
Are defects being fixed?
Are dependencies current?
Those questions matter.
They are still incomplete from the user's perspective.
A feature that technically works but takes users twice as long to find has deteriorated.
A workflow that completes successfully but now requires navigating around years of accumulated options has deteriorated.
An interface whose modules use increasingly different terminology and interaction patterns has deteriorated even though monitoring reports no errors.
For Levelworks, that is why User Friendly & Delightful is a distinct App Health aspect.
A healthy application should not merely retain functionality as it ages. It should retain the user's ability to understand that functionality and accomplish useful work without accumulating unnecessary friction.
UX maintenance provides the mechanism for doing that.
It observes how the live product is actually being used, identifies where complexity and inconsistency are accumulating, corrects high-impact problems, and validates whether those changes genuinely make important tasks easier.
The question after launch should therefore never be only:
“Does the application still work?”
It should also be:
“After everything we have added and changed since launch, does it still make sense to the people who have to use it?”
That question needs to be asked repeatedly, because the application will keep changing—and so will its users.
