Generated Screens Are Debt Until Proven Otherwise
Nov 2026What design debt is, how to measure it, and why AI changes how fast it piles up.
Why this is on my mind
Design debt used to accumulate at human speed: a rushed launch here, a one-off button there. If a model can produce a plausible new screen in seconds, debt can accumulate at machine speed. I want a way to think about that before it happens to my own product.
What's true right now
The metaphor is borrowed on purpose. Nielsen Norman Group defines UX debt as the design counterpart of technical debt, incurred when teams work under tight timelines or constraints, and notes it accrues cost over time, like compound interest. Skipping user testing is one named cause. They also make a useful exception: temporary inconsistencies from an A/B test are not debt as long as the winner gets scaled into the design system with full consistency.
It comes in kinds. Practitioner guides split design debt into UX, operational, visual, and testing and research debt. One glossary lists a missing design system as a sign of operational debt, and describes visual debt at its extreme as parts of a product that look like they belong to different products.
It can be measured. One consultancy proposes pairing an expert review against Nielsen's ten heuristics with a calculation that scores each issue by severity and frequency, so design debt can be tracked like a KPI and managed like technical debt.
It's quiet. A concept note on design debt points out its costs show up as user frustration, churn, and support load rather than crashes, and that users stop complaining as they adapt, which makes it harder to see.
A worked example of a debt tag
Illustrative: my own sketch, not a sourced fact.
Two screens, two tags. Say a model generates a settings screen entirely from existing system components. That one is tagged composed, carries no debt, and needs no follow-up. Say it generates a pricing card with a new corner radius and a one-off shadow. That one is tagged novel, so it gets an owner and an expiry date before it ships.
What the tag forces. At the expiry, someone has to decide: promote the pattern into the system, or delete it. Doing nothing is no longer an option, which is the whole point. Without the tag, the pricing card just stays, and a year later it is one of the parts that looks like it belongs to a different product.
My hypothesis
This section is my opinion, not a sourced fact.
Every generated screen that is not promoted into the design system should be counted as debt the moment it ships.
Under the old model, one-offs were rare enough to notice. With generation, one-offs become the default output unless something forces them back into the system. The NN/g rule about A/B test winners is the template: a variation is fine while it's an experiment, and it becomes debt the day it quietly becomes permanent.
So I'd want a "debt budget" at generation time. Each generated surface gets tagged as either composed from the system (no debt) or novel (debt, with an owner and an expiry). Novel patterns that survive two review cycles either get promoted into the system or get deleted.
What I would do first on a real product
My opinion, based on the tradeoffs above.
Count before you govern. I would not begin with a process. I would begin with the audit, one product area, composed versus custom, because a number is harder to argue with than a worry. If the novel share is already high before any generation, the debt problem is older than the model, and I want to know that.
Keep the ceremony light. A debt budget that takes real effort per screen will be skipped, and a skipped budget is worse than none because it implies control. I would want the tag to be close to automatic, something a pipeline can mark, with humans only deciding on the novel ones.
How I'd test it
Audit one product area. Count surfaces built purely from system components versus surfaces with custom styling. Then simulate generation: have a model produce ten new variants and count how many introduce a new value. If the novel ratio is high, a debt budget is worth the overhead.
What would change my mind
If a mature system can absorb novel patterns automatically (for example, by proposing new components from repeated one-offs), the manual budget becomes unnecessary.
Where I would not trust this yet
My opinion, based on the tradeoffs above.
Novel is not the same as bad. A new pattern can be exactly what a product needs. Treating every novel surface as debt risks punishing good ideas along with sloppy ones. I would read the tag as a prompt to decide, not a verdict, and I would not want it to make people afraid to try something.
Expiry dates can become noise. If owners routinely extend them, the budget turns into a ritual. I would watch how often the answer is simply more time. If that happens often, either the review cycle is wrong or the system is not able to absorb new patterns fast enough, and that second problem is the real one.
References
- Nielsen Norman Group, UX Debt
- Helio (Zurb), Measure and prioritize design debt in your product development
- Emergn, Design debt: What it is and how to overcome it
- Elementor, What is design debt?
- Concepts, Design Debt