Design debt is every shortcut, quick fix, and one-off exception in a product’s design that nobody ever went back and cleaned up. The four different date pickers, the three button styles, the form that reinvents a pattern the design system already had. Like money you borrowed, it buys speed now and charges interest later: every unpaid shortcut makes the next change slower and the product a little more incoherent. The difference is that no one writes design debt down, so it is the one debt a business gets to pretend it is not carrying.
Every roadmap meeting is a fight between things you can measure and things you cannot. New features arrive with revenue projections and user counts. Design debt arrives as a feeling, a designer saying the checkout is a mess or the component library has drifted. One of those has a number attached. The other does not. Guess which one keeps losing.
So when I say design debt is real debt, I mean it literally, not as a metaphor. I have watched good teams carry it for years because nobody ever put a price on it, and a cost nobody has counted is a cost the business is free to pretend does not exist. The fix is not to argue harder in the meeting. It is to walk in with a dollar figure and a number of hours, the same currency features are measured in. I wrote about the general discipline in how I measure design ROI, and this is that discipline pointed straight at the debt.
Unmeasured debt always loses the roadmap fight
Here is the mechanic that beats design teams over and over. A prioritization meeting is a comparison, and you cannot compare a number to a vibe. When a product manager weighs a feature that projects two hundred thousand dollars in new revenue against a designer who says the settings flow is confusing, the feature wins by default. Not because it is more valuable, but because it is the only side of the scale with a weight on it. The debt is not deprioritized. It is un-prioritized, sitting off the board entirely because it never got expressed in a unit anyone scores.
And the cost is not hypothetical. In Stripe and Harris Poll’s Developer Coefficient (opens in new tab) survey of more than a thousand developers, the average developer spends 13.5 hours a week on technical debt, out of a 41.1 hour week. That is roughly a third of engineering capacity going to maintenance instead of new work, and design debt sits upstream of a lot of it. Every inconsistent pattern, every one-off component, every screen that ignored the system is a thing engineers now have to work around. You are already paying for the debt. You just are not writing it down.
Put a real number on it
Design debt becomes legible the moment you force it into two columns: hours and dollars. Both are countable if you stop treating the debt as one big fog and break it into named items. Not "the app feels dated," but "we have four different date pickers, three button styles, and a checkout that drops fields on mobile." A vague mess cannot be priced. A list can.
For the hours column, walk the list and estimate the recurring tax each item charges. A designer rebuilding the same pattern from scratch because there is no reusable version. An engineer reverse-engineering which button component is the real one. A support queue fielding tickets that trace back to one confusing flow. Add a few of these up across a quarter and the number is rarely small. I have seen a single inconsistent form pattern eat a day of design and engineering time every sprint, quietly, forever, until someone paid it down once.
For the dollars column, tie the debt to money the business already tracks. The clearest lever is conversion. Baymard Institute’s checkout usability research (opens in new tab) finds that the average large-scale ecommerce site can lift conversion by 35 percent by fixing its checkout UX, across an average of 32 discrete improvements. Those improvements are design debt with a receipt. Take your own funnel, take a conservative slice of that upside, multiply by revenue per conversion, and the confusing checkout stops being an aesthetic complaint and becomes a line item with a dollar sign.
A cost nobody has counted is a cost the business is free to pretend does not exist.
The number that wins the fight
Put the two columns together and you have a design debt register, the same way finance keeps a debt schedule. Each row is one named item, its recurring cost in hours per sprint, its estimated dollar drag, and a rough cost to fix. Now the confusing checkout is not designer feelings. It is a line that reads: costs about eight engineering hours a sprint, drags an estimated fifty thousand dollars a quarter in abandoned carts, takes two weeks to fix. That row can sit on the roadmap next to any feature and hold its own, because it is finally speaking the roadmap’s language.
The register also settles the timing question, because debt gets more expensive the longer it sits. Nielsen Norman Group notes that "it’s 100 times cheaper to make a change before any code has been written than it is to wait until after the implementation is complete." (opens in new tab) Every screen you ship on top of a broken pattern is another place you will have to fix it later, at a higher price. The interest is real, and it compounds. A register makes that compounding visible instead of letting it hide inside next quarter’s slower velocity.
The rule for when to pay it down
Here is the rule I use, and it is simple on purpose. Pay down a piece of design debt before building a new feature when the debt sits directly under that feature, or when its measured drag is larger than the feature’s projected gain. Everything else waits. That is the whole rule.
The first half is about leverage. If you are about to build three new flows on top of the same broken form pattern, fixing the pattern first is not a detour, it is the cheapest that fix will ever be. You pay it down once instead of working around it three times and then paying it down anyway. Building new work on debt you already know about is how a two-week fix becomes a two-month one.
The second half is about competition on merit. Once the debt carries a dollar figure, it earns a real seat at the table. If your register says a broken onboarding flow drags eighty thousand dollars a quarter and the feature you are weighing projects thirty, the debt is the higher-value work and the number says so out loud. If the feature projects three hundred thousand and the debt drags ten, ship the feature and let the debt wait its turn. The point of the number is not to always win. It is to let the debt compete at all.
Put a cost on the debt in dollars and hours, or it will never beat a feature that already has one.
Who this is for, and when it is not the answer
This method is for teams stuck in the same argument every planning cycle, where design keeps flagging the same problems and nothing moves. If that is you, the missing piece is almost never better persuasion. It is a number. Build the register, price a few of the worst items, and bring dollars to a meeting that has only ever heard adjectives.
I would be selling you something false, though, if I said measure everything. Do not spend a week building a forty-row spreadsheet to justify a fix you could ship this afternoon. If the debt is cheap to pay down and obviously worth it, just fix it and skip the accounting. The register earns its keep on the expensive, contested calls, not the easy ones. Quantifying a two-hour fix costs more than the fix.
There is also a real trap in false precision. A design debt number is an estimate wearing a suit, and if you present it as exact, someone will rightly tear it apart and you will lose the credibility that made it useful. Show your assumptions. Say roughly fifty thousand a quarter and here is the math, not exactly fifty-one thousand three hundred and forty. A defensible range beats a fake decimal every time. The goal is a number solid enough to make a decision on, not one precise enough to be wrong about.
And if you are a very early startup still searching for product-market fit, most of this can wait. When you might rebuild the whole product in three months, cataloging the debt in today’s version is effort spent on something that may not survive the quarter. Measure design debt once the product is real enough that the debt will be around long enough to charge you interest. Before that, move fast and let it accrue. The discipline of proving design moved the business matters most when there is a business to move.
For everyone past that stage, the takeaway is one sentence. Design debt that no one has quantified always loses the roadmap fight, so put a cost on it in dollars and hours or it will never get fixed. The feeling that something is broken is real, but a feeling does not get funded. A number does. Do the small, unglamorous work of counting the debt, and you turn a losing argument into a line item the business cannot pretend it never saw.