UX Glossary Process & Methods

Technical Debt

Process & Methods

The cumulative consequence of expedient implementation choices that create future rework — shipping code or design that works now but is harder to maintain, extend, or correct later. For designers, the equivalent involves inconsistent patterns, undocumented decisions, and workarounds that don't integrate cleanly with the design system, silently degrading the product experience over time.

Technical Debt illustration
Source: picsum.photos

Common contexts

Use when

Acknowledge and name technical debt deliberately when scoping work under tight deadlines — making the debt visible with a documented plan to repay it is far healthier than pretending it isn't accruing. Naming it gives the team permission to revisit it later rather than letting it silently compound.

Avoid when

Don't use 'technical debt' as a blanket excuse to avoid shipping — some shortcuts are reasonable trade-offs, not debt. Treating every pragmatic decision as debt creates analysis paralysis and signals poor judgment about when good enough is genuinely sufficient.

Design debt is more insidious than code debt because it's invisible in the backlog — inconsistent patterns don't throw errors, they just erode user trust and slow down every designer who joins the project later.

Real-world examples

Related terms

Design Debt Design System Iterative Design Pattern Inventory
← Browse all UX Glossary terms