Design Debt Is Technical Debt. Treat It the Same Way.

Most engineering organizations track technical debt on a dashboard. Most design organizations track design debt as a vague feeling that the product used to be more consistent. That asymmetry is costing teams more than they realize.

Every organization understands technical debt at some level. The term was coined by Ward Cunningham in the early days of software development to describe the hidden cost of shortcuts taken under pressure. The code works. It ships. But the decisions made to get it out the door faster create a compounding obligation that has to be paid down eventually, usually at a much higher cost than the original shortcut saved.

Engineering leaders have spent decades building systems to manage it. They track it in backlogs. They allocate sprint capacity to reduce it. They measure its impact on velocity and escalate it to leadership when it threatens delivery. Technical debt is treated as a business problem, not just a code problem, because that is exactly what it is.

Design debt operates the same way. It accumulates the same way. It compounds the same way. And it costs the same way.

The difference is that almost nobody tracks it.

What Design Debt Actually Is

Design debt is not a poorly designed screen. It is the accumulated cost of design decisions that were made under pressure and never revisited: one-off components that were never added to the system, interactions that differ across surfaces because nobody reconciled them, tokens that were hard-coded because there was no time to do it properly, accessibility shortcuts that passed QA but do not actually work for the people who need them.

It builds the same way technical debt does. A deadline forces a shortcut. The shortcut ships. The next sprint assumes the shortcut as a baseline. Six months later, the product has three versions of the same button, five different error states that behave differently, and a design system that reflects what the product looked like eighteen months ago rather than what it looks like today.

The organizational impact is identical to technical debt. Designers spend an increasing proportion of their time reconciling inconsistencies rather than solving new problems. Engineers build against multiple conflicting component versions because nobody has cleaned up the old ones. New features take longer because the foundation they need to build on is unstable. Quality reviews catch surface-level issues but miss the structural ones because nobody has mapped the full extent of the problem.

Research shows developers spend 23% of their time fixing technical debt instead of building new features. The equivalent number for design teams is harder to find because design debt is rarely measured. But anyone who has led a design or engineering team through a major product overhaul knows exactly where the time goes.

Why Design Debt Goes Unmeasured

Technical debt became measurable because engineers fought to make it visible. They built the language of debt, interest, principal, and paydown, that allowed them to translate a technical problem into a business one. When a CTO says the team is spending 40% of capacity on debt service, a CFO can understand what that means and what it is costing.

Design debt has not had that translation layer. The consequences are real: slower delivery, inconsistent experiences, frustrated teams, products that feel like they were built by a committee across five different years. But they are rarely quantified. They get described as aesthetic problems, or taste problems, or resourcing problems. The language used to describe them does not connect to business outcomes the way technical debt language does.

McKinsey has estimated that technical debt can amount to as much as 40% of a company’s technology estate. Design debt does not show up in that estimate because it is not being counted. But it is there, embedded in every inconsistent component, every duplicated pattern, every accessibility issue that will eventually require remediation under regulatory pressure.

The invisibility is the problem. What is not tracked is not prioritized. What is not prioritized does not get fixed. And what does not get fixed compounds, quietly, until someone proposes a redesign and the team discovers that the foundation has been eroding for years.

Treating It the Same Way

The shift is not complicated in principle. It requires three things that engineering organizations have already figured out for technical debt.

First, make it visible. A design debt register does not need to be sophisticated. It needs to exist. A shared, maintained record of known design inconsistencies, out-of-sync components, accessibility gaps, and token misalignments, prioritized by the frequency with which they affect users and the cost of fixing them later versus now. The act of writing it down changes how it gets treated.

Second, allocate capacity to reduce it. Best practice for technical debt is to reserve 15 to 25 percent of each sprint for debt reduction and treat it as seriously as feature development. The same principle applies to design debt. A team that never allocates time to paying it down will always be outrunning it. A team that treats debt reduction as a regular, visible, funded activity gradually builds on a more stable foundation.

Third, connect it to business outcomes. Inconsistent experiences increase support costs. Inaccessible products create regulatory exposure and exclude users. Slow design velocity caused by an unstable foundation delays features. These are business problems, not aesthetic ones. The language used to describe design debt should reflect that.

The AI Connection

This is the right moment to take design debt seriously, for a specific reason.

The vibe coding and AI-assisted workflows we talked about in recent weeks are generating design output faster than ever before. That speed is real and valuable. But AI tools that generate UI without a stable design system to work from produce inconsistent output at a scale and speed that a human designer working alone never could.

AI does not slow down because the foundation is unstable. It generates on top of whatever is there. Which means organizations with significant design debt are now accumulating it faster than before, not slower.

The teams that will move fastest with AI are the ones who paid down their design debt before they accelerated. The ones who have a token-first, component-based foundation that AI output can be validated against. The ones where “does this reflect the system” is a question that can be answered clearly because the system is current, documented, and maintained.

Design debt was always a problem worth solving. In an AI-assisted workflow, it is an urgent one.

Eddie Lou is a UX and Design Engineering leader with 30+ years of experience at Cisco, PayPal, Apple, Visa, BigCommerce, and Indeed. He is the author of the Design Engineering Handbook (InVision / Design Better) and the founder of EFX Design, a design and development studio specializing in experience platforms, design systems, and custom product development.

Interested in evolving your design system? Let’s talk.