Debt is borrowed time. You solve a problem today by pushing the cost into the future, and the future always collects. Technical debt gets a lot of attention in engineering. There are frameworks for measuring it, sprints for paying it down, architectural reviews for preventing it. Design debt gets much less scrutiny. It's harder to quantify, slower to accumulate visibly, and easier to dismiss as an aesthetic concern rather than a structural one. But design debt is often more damaging. Because it operates at the layer of human experience, not machine logic.
What design debt actually is
It's not inconsistency. Inconsistency is the symptom. The cause is undocumented decisions.
Every time a designer makes a choice that isn't captured somewhere — a slightly off blue, a one-off component, an interaction pattern that works on this screen but contradicts something three flows away — they create a small branch in the decision tree. If it's deliberate and documented, it might be a valid exception. If it isn't, it's debt.
The problem isn't the individual decision. It's that each undocumented decision makes the next designer's job harder. They encounter the inconsistency and have three options: follow it and propagate the error, fix it locally and create a different inconsistency, or flag it and slow everything down. None of these is good. All of them cost something.
Where it accumulates
Design debt doesn't appear in sprint reports. It shows up as slowness. Decisions taking longer because the environment is inconsistent. Engineering taking longer because components can't be reused. QA taking longer because expected behaviour is ambiguous. Users feel it as friction, that slightly-off quality of a product that wasn't built by a single coherent mind. They can't name what's wrong. They just feel it.
It accumulates in predictable conditions: deadline pressure, unclear ownership, poor handoff, no living design system, and the most insidious one — no explicit agreement on what the standard actually is.
I've watched it happen. A component built quickly for one screen, never abstracted. Months later a different designer needs something similar, doesn't find it, builds something slightly different. Now there are two. Then four. Then the pattern is scattered across the whole product and every new screen becomes an act of improvisation.
The entropy principle
Systems tend toward disorder. Left unattended, complexity moves toward noise. This isn't a failure of any individual. It's the nature of how complex things evolve over time.
Design debt is entropy. It's what happens when maintaining coherence isn't explicitly resourced. And this reframes the question. Not "who made this mess?" but "what practices keep the system coherent as it grows?"
The answer isn't perfectionism. Trying to get every decision right the first time produces paralysis and rigidity. The answer is legibility. Making decisions visible, documented, revisitable. A decision that's recorded can be evaluated and changed. A decision that lives only in someone's memory, or in the implicit patterns of a file no one's touched in eight months, is already debt.
The team cost
The most underestimated impact of design debt is on the people doing the work.
An inconsistent, undocumented design environment is demoralising. It creates constant cognitive friction — every decision requires re-solving problems that should already be solved. It erodes confidence in the product and, eventually, in the team's ability to build anything well.
I've worked in environments where even simple questions required investigation. What font size should this label be? What's the standard spacing between these sections? That's not a team that cares too much about detail. That's a team working inside a system that failed to preserve its own decisions.
Paying down design debt isn't glamorous. It doesn't make portfolios. But it's some of the most leveraged work a design team can do, because the returns compound forward just like the debt did — except now in the right direction. Every new screen is faster to design, more consistent to build, cleaner for the user.
The best teams I've encountered treat coherence as infrastructure. Not something you build once but something you tend, the way a craftsperson tends their tools.