How to Recognize & Manage UX Debt

User experience debt inevitably happens over time. It’s the sum of overdue design and usability tasks derived from things like quick business decisions, design shortcuts, missed opportunities, time constraints, and other factors.

User experience debt is called a debt as it’s similar to real-life debt; we get something in the present, but only pay for it in the future. Until the debt is paid off, interest rates arise as a permanent cost.

User experience debt – along with its close cousin, technical debt – is a design antipattern that reduces the quality of a project. As user experience debt is a less widely discussed topic, besides it’s not always easy to recognize it, in this article we are taking a closer look at it.

Technical Debt vs. UX Debt

There are different types of debts in web development. The most well-known is technical debt that’s defined by CSS Tricks as "the sum of compromises we make when writing code during the development process".

Later in our workflow, we will need to deal with the consequences of these compromises, which means extra work in the future.

Technical Debt
IMAGE: FeatureFlags.io

Technical debt is not about outright bugs, but about the fact that even with the best coding practices it’s impossible to fully future-proof a code, however efficient code optimization can certainly help.

Using antipatterns, coding shortcuts, ineffective architecture, or hard-to-manage dependencies can all add to technical debt, but the point is that even in an optimal, hypothetical ideal scenario it’s impossible to avoid it – as future incompatibilities, needs, and issues are unpredictable. That’s why refactoring is recommended after a while.

User experience debt is similar to technical debt in the sense that it:

  • can’t be avoided (althought it can be reduced)
  • is hard to recognize
  • can jeopardize the success of a project.

User experience debt is a wider category than usability debt, as it’s not solely about how usable a website or application is, but also about the way users experience your product – whether they find it entertaining, helpful rewarding, or whatever feeling you want to invoke in your target audience.

User experience encompasses usability, as a hard-to-use site won’t make users feel comfortable, and the same way, UX debt encompassess usability debt as well.

Unfortunately, there aren’t many online resources on usability debt and user experience debt, but here are some I’ve found useful, and helped me form my views on the topic:

  • Catriona Cornett, the director of Product Design at SalesforceIQ on how to effectively address usability debt (read here)
  • TryMyUI’s blog on how to avoid UX debt crisis (read here)
  • User Experience Professionals Association on their approach on UX debt with a recommendation on how to calculate its volume (read here)
  • Andrew Wright’s explanation and classification of UX debt on nForm Blog (read here)

Among all the possible illustrations I could find on UX debt, this is pretty much the best choice as I think it concisely shows its gist.

UX Debt Pyramid
IMAGE: Andrew Wright’s slideshow: User Experience Debt (slide 12)

User experience debt can be defined as the difference between the experience quality of your current, and optimal product.

UX debt is more subjective than technical debt, as it’s you (or your client) who decides the quality you want to achieve. For instance, you can target the "functional" level for a minimum viable product, but you can also set high (but usually costly) standards by targeting the "pleasurable" level for a premium product – it all depends on your goals.

Technical debt is different in the sense that in many cases poorly managed code simply stops working. With UX debt, there are no such drastic changes, yet this is not only a perk but also a threat as it makes this kind of debt easier to neglect.

How to Recognize UX Debt

To manage UX debt, at first we need to recognize it. There are two kinds of UX debt, intentional and unintentional.

  1. Intentional UX debt is the result of our conscious decisions when we lack money, time, training, or other resources, or when we are forced to follow outside rules. Good ideas we lose in midst of rushed work also contributes to intentional UX debt.
  2. It’s easy to see that intentional UX debt can occur at any time over the lifecycle of a product.
  3. Unintentional UX debt arises from false assumptions we make about our users. More often than not we tend to think we know what our users want, like, or are able to use, and we build our whole site (app, product, etc.) on this presumed knowledge.
  4. A good amount of unintentional UX debt arises at the beginning of the product life cycle, and it naturally increases over time. Unintentional UX debt is much harder to catch, as we need to get rid of our need to justify our assumptions.

So how does UX debt looks like in real life? When users can’t or don’t want to use our site because of poor user experience. They simply don’t get engaged; we can’t catch their attention and interest.

The manifestation of UX debt differs from site to site, but if we have a decreasing conversion rate or an increasing bounce rate in most cases we can suspect that we have accumulated a nice amount of UX debt.

How to Manage UX Debt

There’s no universal recipe to manage UX debt effectively, as many things depends on subjective characteristics, however it’s worth taking a look at how others deal with the issue in order to find our own way.

For instance, Catriona Cornett, the Product Design Director of SalesforceIQ shows the 5 step process they use to manage usability debt at SalesforceIQ.

Let’s see it briefly so that we can assess how well we can apply it to our own workflow.

  1. Define a shared language for discussing usability issues.
  2. Find and gather usability issues.
  3. Organize and classify the usability issues.
  4. Prioritize usability improvements.
  5. Measure the impact of improvements.

User experience is a wider area than usability, but I think the workflow above can effectively applied to it.

Andrew Wright comes with a slightly different management workflow in his UX Debt presentation, and he recommends a 4 step process to deal with UX debt.

  1. Determine if and where UX debt exists.
  2. Compare severity to importance.
  3. Make time to fix it.
  4. Socialize the concept.

Dealing with intentional and unintentional UX debt also require different techniques. Shortcuts we intentionally make, and good ideas that get lost during the process can be managed by note taking, task management, or issue tracking apps.

Unintentional UX debt can be more or less overcome by regularly running user tests, asking for customer feedback, or using advanced techniques like A/B testing to see the impact of different designs.

Applying principles of iterative design can also be useful; we can build our UX debt management steps into every iteration to prevent its accumulation.

Iterative Design
IMAGE: Wikipedia – Iterative and incremental development

UX debt management needs to fit into our broader workflow, with the characteristics of our team, our goals, and the nature of our product, but there are some universal things that’s recommended to follow in all cases.

  1. We need to communicate across our team why we need to deal with UX debt, what are our goals, and how we want to accomplish them.
  2. We need to find tools to track intentional UX debt.
  3. We need to find ways to test our product and get feedback from our users to catch unintentional UX debt.
  4. We need to organize and prioritize our issues.
  5. We need to measure the results our work, as we always need to adjust UX debt management to our changing needs.

Final Words

To create quality products we don’t only need to be innovative, but also to pay attention to things that are not so obvious at first sight, one of these is recognizing and effectively managing UX debt. It’s probably not the most interesting task but it’s crucial, as over time UX debt can be a serious threat to the success of our work.

If we slice UX debt into manageable chunks, and integrate the related tasks into our workflow, we don’t have to do too much at once, we can avoid unpleasant surprises, and maintain or improve the quality of a product in a comfortable way.

WebsiteFacebookTwitterInstagramPinterestLinkedInGoogle+YoutubeRedditDribbbleBehanceGithubCodePenWhatsappEmail