Technical debt has vocabulary — refactor, deprecation, migration. Design debt often has none. Teams ship exceptions: one-off modals, bespoke tables, hero layouts that break the grid. Each exception feels small. Together they signal that the product no longer has a system.
Design debt compounds because humans pattern-match. Inconsistency reads as unreliability. Unreliability erodes trust faster than a single missing feature.
How debt accumulates
Deadline pressure is the usual cause. But organisational causes matter too: when research findings never reach the component library, when brand teams and product teams maintain separate files, when AI-generated screens bypass review because they look plausible at a glance.
We map design debt explicitly during discovery — not to shame teams, but to price the cost of ignoring it in roadmap conversations.
Paying it down without stopping the road
Debt reduction works best as a parallel track: tokenise what repeats, document what varies intentionally, retire what no longer serves. Grand redesigns without behavioural evidence often swap old debt for new aesthetics.
Products grounded in research and built to last — the standard we hold — invest in systems that survive team turnover. That is the difference between a launch and a practice.
Every exception you ship teaches users that the system cannot be trusted.