Design debt is the inconsistency and usability cost that builds up in a product when teams take shortcuts to ship. The term comes from Austin Knight's essay and borrows from technical debt, a term Ward Cunningham coined for code.
Shortcuts can save time during a release but create extra work later. Users may need to relearn patterns, while teams may have to rebuild screens or components that could have been standardized.
Use cases
Design debt builds over many releases and shows up as confused users and slower work.
Button sprawl: 3 teams ship features in the same quarter, each with its own primary button. Users can't tell which style submits a form.
Fire-drill feature: A sales deal needs CSV export by Friday. It lands in a menu no other feature uses, and support tickets follow.
Slow delivery: A simple settings change takes 2 sprints because the same form exists in 4 versions.
How it's used in practice
Run an interface inventory. Screenshot every button, input, modal, and alert. Count the variants and identify where the same pattern appears differently.
Log debt in the backlog. Tag items so they're estimated and prioritized alongside feature work.
Rank by severity and location. Fix issues on high-traffic journeys such as signup or checkout first.
Reserve capacity. Set aside a fixed share of each sprint for cleanup.
Leave screens cleaner. When a team touches a screen, fix its inconsistencies instead of adding another variation.
🪄
Pro-tip: Report debt in concrete numbers. "14 button styles and 6 date pickers" gives a PM something specific to prioritize.
Challenges & limitations
Low visibility: Debt rarely breaks a flow outright, so new features often win prioritization meetings.
No standard metric: Teams build their own measures, such as component variants or task time on affected flows.
Deliberate debt: Shipping fast to test a market can be a reasonable tradeoff when the team records the shortcut, understands the cost, and schedules the cleanup.
