Insights
UX debt (design debt) is cost a product keeps charging users and the team. Measure both, log each item with an owner and a decision, repay it in roadmap work. UX debt, also called design debt, is the cost a product keeps charging because of earlier decisions: users pay it in workarounds, retries and support contacts, a
UX debt, also called design debt, is the cost a product keeps charging because of earlier decisions: users pay it in workarounds, retries and support contacts, and the team pays it in changes to that area that take longer and break more. To measure it, count both costs for one product area at a time. To pay it down, record each item with its evidence, consequence, owner and a decision (repay, accept or retire the feature), and repay it inside the roadmap work that already touches that area.
When many items trace back to the same product model, cleanup will not reach the cause, and the question becomes modernisation. Some teams use "design debt" more broadly, to take in visual and design-system inconsistency; whichever name your team uses, the test below decides what belongs on the list. The short definition is in our UX debt glossary entry; this article is about what to do with it.
Debt or defect: the accumulation test
The metaphor comes from software. In his OOPSLA 1992 experience report on the WyCash system, Ward Cunningham compared shipping first-time code to borrowing, with every minute spent on not-quite-right code counted as interest: "The danger occurs when the debt is not repaid." In a later video explanation, transcribed on his wiki, he said the metaphor was never a licence to write code poorly: repaying meant putting what the team had learned back into the code.
Two parts of that carry over to UX. Interest is a recurring cost, not a one-off flaw. And the debt sits in a gap between what the product embodies and what the team now knows about the work it supports. One part does not: code debt is paid mostly by developers, while UX debt is paid by users first, then by the team. Sebastian Baltes and Veronika Dashuber put it in the title of their CHASE 2024 paper: UX Debt: Developers Borrow While Users Pay.
We use one test to separate debt from a contained defect. Ask two questions about the problem:
| Question | If yes | If no |
|---|---|---|
| Does the cost recur for users, every time they do this work? | People are paying interest: workarounds, exports, retries, support contacts | It is a one-off annoyance |
| Does every change in this area get slower or riskier because of it? | The team is paying interest too | The problem is local |
Two yeses make it debt: record it and decide what to do. Two noes make it a defect: fix it in the normal backlog and keep it out of the debt conversation. A mixed answer is still worth recording, because the cost is real, but it tells you which side to measure first.
The test matters because "UX debt" easily becomes a label for every wish-list item, and a list that long is hard to act on. A misaligned button is a defect. Two approval states for the same record, which force users to reconcile them in a spreadsheet and force every new approval feature to handle both, is debt.
The test also tells you what to leave alone. In the listing and pipeline workflow Tcules redesigned for Dealpath, an institutional real estate platform, the listing cards were dense, but acquisition teams needed that density to judge an opportunity, so it was not debt. The structural problem was one action: adding a listing to the pipeline opened a new-deal flow before checking whether the deal already existed, which made duplicates easier to create. We changed that path to search existing deals first, and largely kept the other listing actions as they were, because each familiar workflow carries learned behaviour and regression risk. The case records a design decision, not a measured fall in duplicates.
The little measurement there is points the same way. Across 145 technical-debt items in five projects at four Brazilian public companies, usability items were 13.8% of the items but only 5.1% to 6.7% of the estimated effort to resolve the debt, and the authors call usability debt frequent and cheap to repay (Lage, Trevisan and Kalinowski, 2020). Our reading: many items tagged as usability debt are contained defects, best simply fixed, and the expensive kind sits in workflows and product models, where no agreed metric exists yet. So measure its cost directly.
How to measure UX debt
Measure UX debt as two running costs for one product area at a time, rather than as a single score. A score invites argument about weights; two plain counts invite argument about the product, which is the useful argument.
What users pay. In our view, workarounds are the clearest signal, because people build them when something stands in the way of their work. Steven Alter's theory of workarounds treats them as goal-driven adaptations people make to get past obstacles in a work system, which is a useful lens: each one marks a place where the product and the work have parted.
What the team pays. DORA, a long-running research programme on software delivery, defines change lead time and change fail rate for one application or service at a time. Our adaptation is to slice them by product area: if changes that touch the approvals workflow take twice as long and need twice as many follow-up fixes as changes elsewhere, the area is charging interest.
| Cost | Signal | Where to find it |
|---|---|---|
| Users | Workarounds: exports to spreadsheets, copying between screens, side-channel messages to confirm a change | Interviews, observation, export and copy events in analytics |
| Users | Support contacts about the same workflow | Support tickets tagged by workflow, not by feature |
| Users | Retries, repeated submissions and manual checks | Analytics events, session review |
| Users | Abandoned steps | Funnel drop-off at a named step |
| Users | Workarounds written into training or help material | Onboarding decks, internal guides, help articles |
| Team | Time for a change in this area to reach users, compared with other areas | Tickets and pull requests tagged by product area |
| Team | Changes in this area that needed a fix or rollback afterwards | Incident and hotfix records |
| Team | Places a single rule has to be changed (states, screens, services) | Code and design review of recent changes |
Three habits keep the numbers honest. Count over a fixed window, the same for every area. Record a baseline before repaying anything, so you can tell whether repayment worked. And look past completion rates: a task can complete while users quietly do extra work, which is how interface regressions hide from completion metrics.
The UX debt register
A register turns measured cost into decisions. Our glossary entry names the three records that keep the metaphor useful: consequence, owner and a reason to repay or accept. We add the evidence behind each item and a test for repayment, so the register can be checked later. Copy these columns:
| Column | What goes in it |
|---|---|
| Item | The condition, named as a cause ("approval status held in two places"), not a symptom ("approvals are confusing") |
| Area | The workflow or product area it lives in |
| User evidence | The recurring cost users pay, with counts and the window |
| Change evidence | What it costs the team to change this area, with examples |
| Consequence | What happens if nothing changes: to users, to revenue, to delivery |
| Owner | One named person who can decide, not a team |
| Disposition | Repay, accept, or retire the feature |
| Reason and trigger | Why this disposition, and what event reopens it |
| Repayment test | Which counts should fall, and by when they are checked |
An illustrative row, built on the example in our glossary rather than on any client:
| Column | Illustrative entry |
|---|---|
| Item | Approval status held in two places |
| Area | Approvals |
| User evidence | Approvers export to a spreadsheet to reconcile status; support contacts ask which status is correct |
| Change evidence | Each new approval feature has to handle both states; recent changes needed follow-up fixes |
| Consequence | Approvers keep a parallel record; each approvals feature costs more to ship |
| Owner | Product lead for approvals |
| Disposition | Repay |
| Reason and trigger | The approvals roadmap item next quarter touches the same model |
| Repayment test | Spreadsheet exports and status questions fall; approval changes ship without follow-up fixes |
Three rules keep the register short enough to act on. An item without evidence is an idea, not debt: it goes to the normal backlog. An item without an owner has not been decided, whatever its disposition says. And "accept" is a real decision, not a parking place: it needs a reason (the area is stable, the cost is small and contained, the feature is near its end) and a trigger that reopens it.
Retiring a feature belongs on the list because some debt is cheapest to repay by removing what carries it. If few people use the workflow and it costs a great deal to keep working, retirement may beat repair.
The first register is the hard one, because local defects and structural debt have to be told apart before the evidence is in. Our UX Product Audit produces findings in this shape: each one traced to the condition behind it, marked structural or local, and given a consequence, an owner and a disposition.
How to pay it down
Pay UX debt down inside the roadmap work that already touches the affected area, rather than in a separate "debt sprint". That is our judgement, not a measured result. A dedicated sprint competes with every roadmap item for the same time, sits outside the area's ongoing work and is the first thing cut when a deadline moves. Repayment attached to roadmap work in the same area shares its context, its people and its testing.
In practice:
- Record debt when you take it on. GitLab's development documentation has a "Deferred UX" label for the moment a team knowingly ships a shortcut that harms the experience, asks for the issue to mention the merge request it came from, and gives such issues the same priority as new features. In our view, recording the shortcut at the time costs less than reconstructing it later.
- Scope repayment into the next roadmap item in the area. When a feature touches the approvals model, the register item for that model is part of its scope, with its own repayment test.
- Repay the cause, not the symptom. Fixing one screen where the two approval states disagree removes one symptom and leaves the interest running.
- Check the repayment test. If the user and team counts have not fallen over the next window, the item is not repaid, whatever the ticket status says.
- Review the register on a fixed rhythm, with the owners in the room, and close accepted items whose trigger has fired.
When cleanup is the wrong answer
Some debt is too structural to repay item by item. These are signs that the question has become modernisation rather than cleanup:
- many register items trace back to the same product model, such as how a record's status or permissions work;
- repaid items come back, because the cause sits underneath the area being fixed;
- a single rule change needs coordinated changes across several screens, states or services;
- the model no longer fits the work, and users have built a parallel process outside the product.
At that point, the decision is per capability: preserve it, redesign it, replatform it or retire it. Our article on whether to rebuild or modernise legacy software sets out that framework, and our Product Modernisation Assessment makes the decision capability by capability, with a staged sequence rather than a default rebuild.
