Design Principles
UX Debt
Deferred UX iteration accumulates like technical debt — first-pass decisions that were never revisited compound into a product that quietly stops working.
Where it comes from
The term borrows directly from software's 'technical debt' and is articulated for design by Jeff Gothelf and the Lean UX tradition. Just as code accumulates debt from shortcuts never revisited, a product accumulates UX debt from first-pass design decisions that were never tested or improved.
Why it matters for your website
Just as codebases accumulate technical debt from shortcuts never revisited, products accumulate UX debt from first-pass design decisions that were never tested or improved. Gothelf's concept of UX debt names the phenomenon: the site becomes progressively harder to use not because it was badly designed initially, but because the world moved on and the design didn't. What shows up in an audit as "outdated," "inconsistent," or "confusing" is often not bad design — it's design that was adequate once and overdue for a second iteration.
The crucial reframe is that UX debt usually isn't bad design — it's unfinished design. A page that's now confusing was very often adequate when it shipped; what's changed is the surrounding world — expectations, conventions, the rest of the product — while the page stood still.
Because the debt accrues silently, it's easy to misdiagnose. What an audit labels 'outdated', 'inconsistent', or 'confusing' is frequently not a mistake to be ashamed of but a decision that was fine once and is simply overdue for its second iteration. Naming it as debt, rather than failure, points to the fix: revisit it.
Wrong vs right
A flow that was fine at launch but now clashes with newer parts of the product, left unrevisited as 'good enough'.
Periodically revisiting first-pass decisions and bringing them up to current standards as the product evolves.
Treating accumulated inconsistency as permanent character rather than debt to be paid down.
Identifying the design debt and scheduling iteration, the way a team schedules paying down technical debt.
Assuming a confusing page was simply badly designed, and missing that it was adequate once and overdue for update.
Recognising the page as design that the world moved past, and iterating it forward.
Understanding UX Debt
UX debt is the design equivalent of technical debt: the accumulated cost of first-pass design decisions that were never revisited or improved. Just as a codebase gathers debt from shortcuts taken under deadline, a product gathers UX debt from interfaces that were shipped, judged 'good enough', and then never iterated — even as the world around them changed.
Jeff Gothelf's framing makes an important point about cause. A product often becomes harder to use not because it was badly designed to begin with, but because expectations, conventions, and the rest of the product moved on while a given page stood still. The debt is the growing gap between what was adequate then and what's expected now.
This reframes a lot of audit findings. What gets labelled 'outdated', 'inconsistent', or 'confusing' is frequently not bad design but design that was fine once and is overdue for a second iteration — and naming it as debt points straight to the remedy: revisit it. It connects to hypothesis-first design, outcomes over output, and the discipline of iteration.
How Kweri checks it
Kweri can surface the symptoms of UX debt it can observe — inconsistency with newer parts of a product, dated patterns, friction that no longer matches current conventions — and frame them as debt overdue for iteration rather than simply 'bad design'. What it can't always know is the history: whether a given choice was a mistake or simply an un-revisited first pass. So Kweri flags the debt-like symptoms and prompts the question of what's overdue for a second iteration, while the decision of what to pay down and when is a prioritisation call for your team.
FAQ
What is UX debt?
UX debt is the accumulated cost of first-pass design decisions that were never revisited or improved — the design equivalent of technical debt. Over time, un-iterated interfaces become harder to use as expectations and the rest of the product move on.
How is UX debt different from bad design?
UX debt usually isn't bad design — it's unfinished design. A page that's now confusing was often adequate when it shipped; what changed is the surrounding world. The debt is the gap between what was fine then and what's expected now.
What causes UX debt?
Shipping first-pass design decisions and never iterating on them, while expectations, conventions, and the rest of the product evolve. The design stands still as the world moves on, and the gap accumulates as debt.
How do I pay down UX debt?
Revisit un-iterated decisions and bring them up to current standards, the way a team schedules paying down technical debt. Identify the interfaces that were 'good enough' once and are now overdue for a second iteration, and prioritise them.
Who coined the term UX debt?
The concept borrows from software's 'technical debt' and is articulated for design by Jeff Gothelf and the Lean UX tradition, naming the gradual accumulation of un-revisited design decisions.
Related principles
Every design decision is a testable assumption — treat it as a hypothesis until user behaviour proves it right or wrong.
The brain has a limited processing budget — demand too much and performance collapses.
Show only what the current task needs — reveal complexity when the user asks for it.
Attribution & sources
Identified by Jeff Gothelf (concept from technical debt). Catalogued from Lean UX (Jeff Gothelf).
A design adaptation of 'technical debt', articulated in the Lean UX tradition; the linked reference is used here.
See UX Debt on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →