Design Debt

About a year into a product, the same scene plays out on every team. A designer lays out twenty screens side by side and finds seven kinds of button. Some are 40 pixels tall and some are 44. The same blue exists in three slightly different values. None of it looked strange while each screen was being made.

The hard part was saying any of this out loud. "I think we should clean up the buttons" sounded like a matter of taste. Nothing was broken, no user had complained, and next to a new feature on the same planning list it lost every time. Postpone that for three quarters and seven kinds of button become twelve.

Design debt is a borrowed name that puts a price on the situation. Calling the postponed work something owed rather than something preferred changes the conversation. Instead of "I'd like to clean this up," a designer can say "five days now, fifteen days next quarter" — and only then does the work sit on the same list as everything else.

The whole idea rests on one property: the cost of postponing grows over time. Like borrowed money, the cleanup itself is the principal, and the interest is everything that spreads while the cleanup waits.

It accumulates in three stages.

1. Origin — a deadline is close, so instead of reaching for the system, someone draws a new button inside the screen. That day it saves two days of work. Nothing has gone wrong yet, and if the team chose it knowing what follows, it was a reasonable trade.
2. Spread — the next person copies that screen to make a new one, and the person after that copies it again. One quarter is usually enough for a single component to reach six screens. Cleaning it up at that point costs two weeks.
3. Collection — the bill arrives whole when something has to change everywhere at once. Adding dark mode does that, and so does changing the brand color. If color lives in design tokens, which give each value a name that design and code both refer to, one name changes and the product follows. If the values were typed directly into each screen, forty places get found by hand.

It piles up in four layers. Values like color and spacing are the first, and components like buttons and inputs are the second — buttons built outside the component library while a library exists belong here. The third is documentation: without a component spec recording a component's properties and edge cases, everyone using it uses it a little differently. The fourth is patterns, as when the confirm-before-delete flow works differently on every screen — one asks twice, one asks once, one offers an undo afterward, and a user who learns the behavior in one place learns nothing about the next.

The line that matters is whether the debt was taken on knowingly. A note saying "this button is separate for launch, merge it next month" means the team knows the amount and the due date. With no note, someone discovers the debt six months later while laying out twenty screens side by side.

It shows up most often in planning. When the team picks what the next quarter holds, design debt is the name that lets cleanup sit on the list beside new features, with the cost of doing it now and the cost of waiting stated together.

That requires numbers someone can see. Three are common: how many button components in the Figma file carry roughly the same name, how many distinct color values are typed directly into the code instead of referenced by name, and how often a newly hired designer has to ask which button to use. The last one is the most honest, because it measures the product as a newcomer meets it rather than as its authors remember it. Six questions in three days means there isn't one standard, whatever the documentation claims.

There are two ways to pay it down. Clear a whole sprint and do nothing but cleanup, or fix things in passing whenever a screen is being touched anyway. The first is hard to get approved and the second is easy to skip, so most teams keep a written list and use both. Either way, without design system governance — the rules about who can change what — debt accumulates faster than it's repaid, because the week after the cleanup somebody builds outside the system again.

"I'm reserving five days this quarter to pay down debt."

Cleanup is going on the schedule as a real line item.

"Let's just build a new one for now and write it down as debt."

Choosing to postpone, but recording the choice.

"I went to add dark mode and found more debt than I expected."

A global change exposing everything that was deferred.

At Pagedeck, five rounds of changes to the document sharing screen left four different share buttons behind. Noa laid out twenty screens and counted three button heights and four blues. She didn't describe it as inconsistency. She wrote that merging now takes four days and merging next quarter alongside dark mode takes twelve, and sent that to Mia.

Mia put the four days into the quarter's plan, but not all of it at once — colors get merged first. Color is what dark mode depends on, so its cost grows fastest, while three button heights block nothing downstream. The rest stayed on the list to be fixed whenever someone touches those screens.

The most common mistake is reading debt as somebody's failure. Looking at an untidy product, it's easy to assume laziness or inexperience produced it. Most of it came from decisions made under deadline, and a fair share of those decisions would be made the same way again. Treat debt as failure and nobody records the debt they take on. Unrecorded debt never reaches a due date, which is why it keeps getting discovered in the middle of a global change.

The second mistake is believing it can be settled in one push. Clearing a backlog on a dedicated day is how most backlogs work, so the assumption is natural. But if the rules stay the same, the pile starts growing again the following week. Teams that spend two months merging every button are often back where they started six months later. The repayment has to come with a decision about who judges the next case and how, otherwise the same two months get spent again on the same buttons.