The debt nobody tracks
Every engineering team I have worked with has a concept of technical debt. They track it, they discuss it in retros, they allocate sprints to address it. It is a legitimate, understood part of the development process.
Design teams? Almost never. And the consequences compound silently until they become catastrophic.
What design debt looks like
Design debt accumulates every time you:
- Ship a "good enough" pattern that does not quite match your system, promising yourself you will fix it later
- Add a one-off component because the design system does not cover this case yet
- Let inconsistencies creep in across features because different designers made different choices
- Skip updating documentation when a pattern evolves
- Ignore interaction patterns that users have learned to work around but that remain fundamentally broken
None of these feel urgent in the moment. All of them erode the product over time.
Design debt is invisible until it is everywhere. Then it is the only thing you can see.
Why it compounds
Unlike a single bug, design debt does not announce itself. It manifests as:
- Slower design velocity -- new features take longer because there is no reliable system to build on
- User confusion -- inconsistencies force users to re-learn patterns they thought they understood
- Engineering friction -- developers waste time asking which version of a component is "correct"
- Onboarding pain -- new designers cannot ramp up because the source of truth is scattered or contradictory
How to address it
First, name it. If your team does not have a shared vocabulary for design debt, start using one. Put it on the board next to tech debt.
Second, audit regularly. Every quarter, do a heuristic review of your own product. Screenshot every screen. Look for inconsistencies, outdated patterns, and workarounds that became permanent.
Third, allocate time. This is the hard part. Design debt reduction needs to be a line item in your sprint planning, not something designers squeeze in between feature work. I advocate for dedicating at least 15-20% of design capacity to system maintenance.
Fourth, prevent it upstream. The best way to manage design debt is to produce less of it. That means investing in your design system, writing clear documentation, and conducting regular design reviews.
The leadership angle
If you lead a design team and you are not tracking design debt, you are flying blind. You might be shipping features, but you are slowly degrading the coherence of your product. And coherence is what separates a product from a collection of features.
Start the spreadsheet. Do the audit. Pay the debt.