How do you tell design debt from something that’s just old?

You tell them apart by cost, not by appearance: design debt is age that actively charges you something, in friction, inconsistency, or maintenance burden, while something that is merely old still works and still serves users fine. The fact that a screen looks like it shipped four years ago is not, by itself, a verdict. The question that decides the matter is whether the age imposes a real, ongoing cost on the people using the product or the people maintaining it. If it does, it is debt. If it only offends current taste, it is just old.

The reason the distinction matters is that taste is an infinite obligation and cost is a finite one. Visual fashion moves every couple of years, so if “looks dated” is your trigger for rework, you will never stop redesigning, and most of that effort buys nothing a user can feel. Debt is different because debt accrues interest. A pattern that confuses people charges you in support tickets and abandoned tasks every single day it survives. An inconsistency between two flows charges you in the extra QA, the duplicated components, the bug that gets fixed in one place and not the other. Those costs compound, and they are the ones worth spending a redesign budget against. The old-but-fine surface charges you nothing until the day you decide to be embarrassed by it.

Consider a checkout flow built in 2020 with a slightly heavy drop shadow, rounded corners that are larger than the current house style, and a button color that no longer matches the rest of the marketing site. It looks dated to a designer who lives in the current trend. But it converts at the same rate it always has, every input validates correctly, and nobody on the team dreads touching it. That is just old. Now contrast it with a settings page from the same era that was hand-coded before the component library existed, so every toggle is a one-off, the spacing is improvised, and changing a label means hunting through three files because nothing is shared. That page also looks dated, but its real problem is that it fights you every time you open it and quietly trains users that settings are unpredictable. The first is cosmetic age. The second is debt, and they can look nearly identical from across the room.

One place the rule bends: cost and appearance sometimes travel together, and you should not let “it still works” become an excuse to ignore real friction. An old pattern can carry hidden debt that has not surfaced yet, an accessibility gap, a layout that breaks on the device sizes that became common after it shipped, a flow that quietly leaks users at a step nobody has measured. So “it works” has to mean it works for the people using it now, not that nothing has crashed. The test is not “do I like how it looks” but “can I point to a cost.” If you can name the friction, the inconsistency, or the maintenance tax in concrete terms, treat it as debt. If the only thing you can say is that it looks like an older era, leave it alone until something better to spend on runs out.

When you are looking at an aging part of the product, force yourself past the visual reaction and write down the actual cost: what does this age make slower, more error-prone, harder to change, or more expensive to maintain. Fix what costs you, and protect the budget by leaving what merely looks dated but works. Treating every old screen as debt is how teams spend a quarter chasing taste while the genuinely expensive friction sits untouched, still charging interest the whole time.