When Adobe wanted to expand beyond photo editing and join the page layout market in 1994, it acquired the company Aldus and its product, Pagemaker. They repeated this strategy in 2005, acquiring Macromedia and its numerous software applications—including Flash, which had become a very successful web platform.

They were following a tried-and-true method for increasing a company’s value, but think about the product consequences. All of a sudden, Adobe had several products designed and built by others, all following different visions, different aesthetics, and different behavioral philosophies. When a new product is suddenly dropped into a team’s collective lap, it doesn’t take long to uncover residual gaps in the product.

Whether it’s a poorly-worded confirmation message that slips out the door or a strange behavior that fell through the cracks, it’s really easy for these gaps to slide by unnoticed.

Before long, a product or three falls short of intended standards and develops an ever-growing list of “We’ll get to it eventually” problems.

In other words, UX debt.

UX Gaps = UX Debt

UX debt is an accumulation of design and development decisions that negatively impact the users of a product or service.

All UX debt is either intentional or unintentional. We should seek to minimize the intentional debt, while proactively avoiding the unintentional debt.

As explained in the free guide Eliminate the UX Gaps In Your Product I wrote with UXPin, reasons for intentional debt include:

  • Time to market– A company might release a product with design debt to meet strategic timelines. For example, a startup seeking a Series B investment might release an imperfect mobile app to better position themselves for a faster Series C investment.
  • Focus on new features – A company may decide a “critical mass” release of robust features for a new product is required to gain market share. The team will then schedule design debt cleanup for later sprints.

Reasons for unintentional debt include:

  • Separation of design and development – When UX is treated as an island, design debt is inevitable.
  • Design by committee – When design leadership needs to satisfy everyone’s requests, the product becomes convoluted. The inconsistency creates UX debt.
  • Lack of access to end-users – If the product team can’t test concepts with end-users, the design is educated guesswork at best.

Regardless of the reason, unaddressed UX debt will eventually lead to products that are so painful to use that customers seek out competitors. UX debt is particularly common in enterprise contexts due to product and organizational complexity.

The below overview of classifications will help you better weigh your options for intentional debt, and better identify and eradicate your unintentional debt. Even if you aren’t able to fix a particular issue yourself, understanding the concepts will help you better pick your battles.

1. Technical Debt

Stop and think about the times developers asked for compromises or shot down your designs citing technical limitations.

Perhaps they said that your requests were too time consuming, wouldn’t perform well, or just weren’t possible. These cutoffs and bypasses alter the intent of your design, in ways that wouldn’t be necessary with a modern, well-maintained technology stack. This is technical debt.

Technical debt comprises two subcategories: Back-End and Front-End Debt.

Back-End Debt. Even minor changes in this part of your stack can irreparably undermine your product’s usability. Back-end debt segments into four key areas:

  • Performance
  • Hardware
  • Database
  • Security

All four aspects are deeply entangled; an issue with one typically pulls in others.

Front-End Debt. Your technology stack greatly impacts the types of debt you’re going to find here. Since I primarily work on browser-based web applications, I classify front-end technical debt as follows:

  • Browser Version Support
  • Outdated HTML
  • Outdated/ Non-responsive Frameworks
  • Poor Coding Practices

2. Functional Debt

Functional debt is usually the result of naturally-evolving shifts in requirements (e.g., technology changes, customers needing new capabilities, features added to attract a wider customer base).

You’ll primarily encounter four types of functional debt.

Scale. If we don’t regularly set new performance goals for our products and improve their UI in order to deal with scale, they will eventually choke. Our users also need efficient tools for managing data at increased scale. This means improving search capabilities, providing more sorting and filtering options, and making it easier to perform bulk actions once desired data is found.

Information Architecture. As hard as we try to account for future growth, we aren’t fortune tellers. Bolt-ons can turn carefully-planned architecture into Frankenstein’s monster. We are forced to make compromises to get the job done because we don’t have the freedom to rearrange content and navigation each time.

Old Features. Enterprise product teams are often loathe to remove features, just in case some customer still uses an obscure function. But these little-used tools may be harming users as a whole—interfering with features the majority are using.

Priority of Functions. Your customers’ priorities change over time, so don’t be afraid of reflecting those needs in the UI. Bring the most popular features to the fore, then move special use cases or anything needed for backwards compatibility to a tucked-away spot that won’t clutter the UI. Regularly evaluate how functions are accessed, even if there aren’t features you intend to cut.

3. Behavioral Debt

Behavioral debt specifically refers to the behavior of the user interface. It’s often a symptom of functional debt, but worth categorizing separately to afford more granular prioritization.

Photo credit: Amanda Linden. Quickbooks before her redesign. A good example of additional tabs required to support more functions.

Tool Time. As the UI gathers more functions, more cruft is created to contain them—more tabs, more toolbars, and more settings. A user may spend so much time fiddling with widgets that she runs short on time to actually accomplish tasks with the tool.

Consistency. It’s easy for inconsistencies to sneak into the UI as a tool matures, and the effect can be much larger than you would anticipate. Inconsistencies cause confusion and erode trust.

Conventions. A convention is formalized consistency. You create a convention when you recognize intentional consistency (or unintentional consistency that is deemed valuable after the fact) and document it as a rule or guide. Be cognizant of this while classifying and addressing UX debt, keeping your conventions up-to-date alongside your UI.

4. Visual Debt

Teams with poor communication between developers and designers are especially prone to visual debt.

UI Chrome. The amount of screen real estate available for the content and important, interactive parts of the UI is frequently reduced as an application accumulates chrome. These static, non-interactive parts of the UI (the button bars, borders, title areas—essentially, anything that isn’t text and can’t be clicked) significantly cut away your high-value space for functionality.

Iconography. Inconsistent iconography is arguably the worst visual debt infringement. Usually the outcome of pure laziness, someone might choose a pre-existing graphic to represent a function rather than design a custom icon. Unbeknownst to them, someone else has already used the graphic to represent a completely different function, sowing confusion across the product..

Consistency. Consistency again? Yep. Visual consistency in color, typography, layout, and style is imperative to a quality user experience. Regardless of how well it actually works, if a UI looks broken or unkempt, users will translate that into their perception of the product.

Trends. User interfaces are consumer products and likewise subject to trends, whether you like it or not. If your application falls too far behind, users will see it as “old” and “outdated,” regardless of how well it works. If your interface still looks skeuomorphic, expect some backlash in today’s era of Flat Design.

Branding. There should be a collaborative process between UX and marketing; when it comes to software, your interface is your brand. When your brand changes for marketing reasons, you should consider changes to the UI in support of the brand. Conversely, when changes are made to the UI for usability reasons, those that impact branding guidelines should be discussed with marketing.

Copywriting. This aspect of branding has implications for usability, particularly in terms of labeling and notifications. Copywriting debt covers everything from typos and grammatical errors to poorly-worded instructions and unhelpful error messages.

5. Documentation Debt

It is imperative that a team leaves behind a visual and written history of its thought processes. Otherwise, the only record of decisions is the final product.

Unfortunately, good documentation is a real struggle for many teams to create on their own; growing piles of poorly-maintained product specs can become indecipherable puzzles. Even a pure Lean UX approach doesn’t always translate well to enterprise environments.

As a middle ground, collaborative design platforms (like UXPin) can alleviate much of the documentation burden. There is less risk of design decisions becoming fragmented across different people’s desktops or cloud folders when you can create and house artifacts like user flows and prototypes in one central hub.

Never take documentation debt lightly—it can quickly lead to visual and behavioral debt as the project evolves. Unless teams synchronize all work around updated design artifacts, visual standards may disintegrate in the name of convenience. Even the best design system could be sabotaged due to behavioral inconsistencies.


Like a financial loan, UX debt should be proactively avoided and diligently reduced when possible. Accumulate enough UX debt, and your product just might go bankrupt.

Article No. 233 | November 8, 2007


An addendum to your story at the beginning there —Adobe ended up throwing out Pagemaker to build InDesign from scratch. We were all better off for it. Because debt was removed entirely and design efforts were completely task-based, we ended up with a far superior tool to get the job done. Businesses these days too often are too hesitant to do this for financial or organizaitonal reasons (the integration of Fireworks functionality into Photoshop is an antithetical example).

I must also quibble with the idea that behavioral inconsistency erodes trust. We never want interactions to be unexpected, so they should always follow good UI principles. But if we take a task-based approach to design, then sometimes an inconsistent behavior may be demanded that is highly beneficial to the flow. It's a careful balance to strike.

I will try to avoid those gaps, so my business will be growing fast. Thank you for tips.

Thank you for this article, you helped me understand behavioral debt. It's clear and understable, great job!