Why does UX need maintenance after launch?

User needs, technology and rules keep changing. The GOV.UK Service Manual warns that a service that isn’t continuously improved will, over time, stop meeting user needs.

What changed in WCAG 2.2?

WCAG 2.2 became a W3C Recommendation on 5 October 2023. It added nine success criteria, including Target Size (Minimum), and removed 4.1.1 Parsing.

Experience problems that build up when teams choose quick shortcuts over better solutions. Like technical debt, it costs more the longer it is left, as users form habits around flawed designs.

Back to Blog

Why like this?1 November 20265 min read

Your product’s UX is never finished

Why a product’s experience needs ongoing maintenance after launch, and a simple rhythm to keep up as users, platforms and standards change.

$Cover for “Your product’s UX\nis never finished”: A phone inside a loop of a yellow and an orange arrow turning around it.$

An app launches, the first tests go well and the team moves on to the next feature. A year later nothing in the code has broken, yet support messages are creeping up and the checkout looks dated next to the phone’s own apps. On newer Android phones, the main button sits behind the navigation bar. The product stood still. Everything around it moved.

People’s needs move

The GOV.UK Service Manual, the UK government’s guide to building digital services, puts it plainly in its Service Standard: continuous improvement lets a team “respond to changes in user needs, technology or government policy”. It warns that a team that only fixes bugs will be “fixing symptoms rather than underlying problems”, and that “over time, the service will stop meeting user needs.”

The reasons are ordinary. Customers who joined as beginners become regular users and want shortcuts. New customer groups arrive with different expectations. None of this shows up as an error in a log file.

Platforms and standards move

The devices and operating systems your product runs on change every year, and their rules change with them.

Apple. On 9 June 2025 Apple announced a new software design built around Liquid Glass, a translucent material that reflects and refracts what is around it, across iOS 26, iPadOS 26, macOS Tahoe 26, watchOS 26 and tvOS 26. It gave developers updated APIs in SwiftUI, UIKit and AppKit to adopt the new design.
Android. On Android 15, apps that target Android 15 (API level 35) are shown edge-to-edge by default: the window fills the whole screen by drawing behind the system bars, such as the status bar and navigation bar. Google’s documentation warns that if an app is not ready, “portions of your app may be obscured”. Android 15 allowed an opt-out; for apps targeting Android 16 (API level 36), that opt-out is disabled. Since 31 August 2026, Google Play requires new phone and tablet apps and updates to target Android 16. In practice, shipping any update now means handling this layout change.
Accessibility. WCAG, the Web Content Accessibility Guidelines, is the W3C’s standard for making digital content accessible to disabled people. Version 2.2 became a W3C Recommendation on 5 October 2023 and added nine new success criteria. Four of them are at level AA, the middle of its three levels: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum) and Accessible Authentication (Minimum). It also removed one old criterion, 4.1.1 Parsing, as obsolete.
Regulation. The European Accessibility Act entered into application in the EU on 28 June 2025. It covers products and services such as smartphones, computers, e-books, banking services and electronic communications. For Gulf and Arab companies serving customers in the EU, accessibility is now often a legal requirement, not only good practice.

A product that was well designed in 2022 can fall short on all four without a line of its code changing.

Debt builds up quietly

Nielsen Norman Group (NN/g), a UX research and consulting firm, describes UX debt as “mounting experience issues that adversely impact our users”. It builds up when teams keep choosing the quick shortcut over the better solution, often under tight deadlines. Like technical debt, it grows more expensive the longer it is left, because people form habits around flawed designs and lose trust in the product.

Design debt is the visible part: three button styles where there should be one, a form that was patched twice, a screen that no longer matches the design system. NN/g’s Anna Kaley recommends that “severity, frequency, and location in the users’ journey” drive how these issues are prioritised, and that the whole product team, developers included, reviews them regularly.

Measure it over time

A single measurement tells you little. NN/g’s Kate Moran defines benchmarking as using metrics to judge a product’s performance “against a meaningful standard”, such as your own earlier version or a competitor, and notes that “a single number is meaningless” on its own. The methods that tend to work best are analytics, surveys and quantitative usability testing. A large quantitative study might suit a yearly rhythm; analytics can be checked after every major release.

GOV.UK gives similar advice for its own services: “measure performance continuously as much as possible, rather than taking ‘snapshots’”, and “iterate your metrics as your service changes”.

Numbers show where people struggle. Usability testing, where you watch real people try real tasks, shows why.

A simple maintenance rhythm

You don’t need a large team to keep a product healthy. You need a calendar.

Every two weeks: a short round of research or usability testing. GOV.UK aims for at least one round every 2 weeks; NN/g suggests testing key flows with realistic tasks at least monthly.
Every month: review analytics trends, support messages and the UX debt list with product and engineering. Fix the top items before adding new ones.
Every new OS release: read what has changed in Apple’s and Google’s guidelines and in the platform requirements, and test your main journeys on the new versions.
Every year: an accessibility review against the current WCAG version, and a benchmark study to compare with last year.

The takeaway

Launch is the first version of the experience, not the last. Give maintenance a fixed rhythm and an owner, because everything around your product will keep moving whether you plan for it or not. At Stroom this is how we approach the products we design: understand, measure, decide, build, then measure again.