If you want to put AI adoption at risk, ignore the design debt at your own peril.
It doesn’t announce itself, but sits there, quietly, underneath every product decision you make, until one day the cost of moving forward is so high that you have to look down.
This is a very accurate (and literal) way of describing what it feels like to accumulate design debt. If you had shivers just from reading it, you’ve been there. Frankly, we’ve all been there at some point, despite organizations sweeping the problem under the rug.
There’s this aura around technical debt. Businesses have built a vocabulary around it and written tons of documentation and best-practice guides on how to tackle it. However, design debt seems to be ignored, left alone, as if it didn’t exist. It comes up when the damage is done: when a product that fulfilled its purpose for years starts failing its users, and there’s not a “why” behind it.
That’s design debt, and it has been there the whole time, accumulating interest… and it’s getting worrying.
Where the “quiet killer” lives
Nobody logs design debt. I find that remarkable, given how much energy goes into tracking technical debt and how many retros are devoted to it. Design debt has no equivalent infrastructure. It lives in the product, and over time, people develop this soft vocabulary to talk around it. They’ll say “legacy decisions” or “the way things are,” which is a polite way of saying people are afraid to open that part of the codebase because last time someone did, it took six weeks before they could even start building what they’d intended to build.
Alicja Suska on debt.design describes design debt as the sum of all imperfections that appear over time as a result of innovation, growth, and a lack of design refactoring. I like that she frames it as a side effect of development, because that’s what it is. Every product accumulates it. It’s just that most teams don’t know how much until they try to build something new and find they can’t get past the first sprint without untangling an old decision that was never documented. get past the first sprint without untangling an old decision that was never documented.
AI entered the chat… to add more fire to the mix
Design debt has been around as long as products have been built under pressure, which is to say, always. Let’s be honest, here: How many shortcuts have you taken to hit a deadline?
Such decisions pile up, and Austin Knight has a good way of explaining how. He writes about how a fresh design starts out debt-free, with every element aware of its surrounding elements, the navigation conscious of the CTA, the CTA conscious of the content below it, everything created in context. Then, with each experiment and optimization, the design drifts from that original coherence. The elements lose what Knight calls “reciprocal awareness” of one another, which makes a product feel consistent to a user.
In a SaaS dashboard, you could tolerate this kind of drift by redesigning the settings page without altering how users understand the rest of the product. AI products broke that, and the reason, I think, is less complicated than it might seem. When building a traditional product, design decisions shape how easy the product is to use, whereas in an AI product, they shape what people believe.
Presenting a probabilistic output as a definitive answer (because someone decided the UX would be “cleaner” without the nuance) leads users to make decisions on false certainty. If feedback mechanisms are buried deep enough that users don’t engage with them, the model never gets corrected, and the product stays wrong. Engagement dashboards will never capture this, because dashboards don’t track comprehension per se. The good news is that this is a solvable problem, and it starts with paying the same seriousness to the design layer that we give to model accuracy or system reliability.
To validate my assumptions, I try to go back to reports from reputable sources. To no surprise, I wasn’t able to find a single report that covered the topic of design debt, but I did find a few interesting reports that touched on the technical debt topic, connecting it to AI, like Forrester’s technology predictions, which are excellent indicators of what might happen in the next couple of years.
Forrester’s 2025 report found that 75% of technology decision-makers expect their technical debt to reach moderate or high severity by 2026, largely because of AI adding complexity to IT landscapes. If that’s the state of debt on the technology side, where people have been tracking and measuring for years, imagine what the design side looks like, where most have even started counting.
The compounding is what worries me most. A questionable interaction pattern can become the default across other flows because it’s easier to copy than to rethink, or a framing choice that flattened uncertainty into certainty might be the template everyone pulls from. Each of these is small on its own, but together, they drift the product toward a place where it’s teaching users the wrong things about what it knows and what it doesn’t.
The ownerless syndrome
AI products are built across many teams, each owning a piece of the system but not the whole, so when things drift, there’s no clear point of accountability, and problems tend to appear at the seams between teams.
The effects surface little by little:
- Iteration slows because you can’t change one pattern without auditing a chain of others.
- Trust erodes and cannot be traced.
- Bias accumulates at the interface through choices about what gets surfaced and what stays hidden, made months ago by people who’ve since moved to other projects.
- Teams optimize locally because they work in a silo, so each group improves its own metrics, even when those improvements create friction elsewhere in the experience.
- Work gets duplicated, with different teams solving the same problem in parallel, each time slightly differently, because there’s no shared layer of ownership.
- Decisions become harder to reverse because they’re entangled across too many parts of the system.
Eventually, the product becomes harder to reason about for users and for the people building it.
A different kind of design leadership?
Changing times need chameleon-like leaders. I can say with confidence that design leaders have this capacity to adapt to any situation, given the (it bears repeating) changing field we work in.
Design debt can only be solved at an executive level, or at least, the decisions to tackle it have to come from there and carry through the rest of the organization. We must strive to make design decisions with the same rigor that engineering audits the codebase, holding a point of view on how the product frames uncertainty and communicates risk, and being present when those decisions are made (early enough!).
Before wrapping up, here’s an exercise I’d suggest. Pick an AI feature in your product that was shipped a few months ago. Sit with it as a user and go through the flow the way someone unfamiliar with the product would.
There’s a decent chance you’ll notice that the interface has drifted from what you intended. Small decisions made months ago, like a simplification your team didn’t think twice about, have accumulated into something quite different from the original intent. This drift doesn’t show up in your data. You have to look at it from a first-time user’s perspective.
Arin Bhowmick (@arinbhowmick) is Chief Design Officer at SAP, based in San Francisco, California. The above article is personal and does not necessarily represent SAP’s positions, strategies or opinions.
Design debt is now as dangerous as technical debt was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.