UX Debt: How to Identify, Prioritize, and Resolve

Continually prioritizing fast and easy solutions may help us hit release dates in the short term, but over time, repeatedly choosing shortcuts will leave us with mounting experience issues that adversely impact our users. These issues are known as UX debt and, if left unaddressed for too long, lead to costly, time-consuming problems that take effort to fix later on. Agile teams are particularly prone to UX debt as a result of heightened pressure to regularly ship new features and functionality. However, UX debt can accumulate in any project, regardless of the development methodology employed, and too much of it will result in a loss of trust, traffic, and revenue. In this article, we define UX debt and show how it can be identified; we also discuss methods for how to prioritize UX-debt issues and resolve them. While these methods are framed for Agile environments, they can easily be adapted to other development processes.

What Is UX Debt?

UX debt is similar to its technical counterpart, known as technical (or tech) debt. Originally devised by Ward Cunningham in 1992, tech debt refers to the additional time and effort costs that result from launching faster or easier technical solutions, instead of releasing the best approach. It implies that the cost of having to go back and fix problems after launch is always higher than launching ideal solutions in the first place (i.e., the debt is repaid with usurious interest). Like tech debt, UX debt is often incurred when designers and researchers are working under tight timelines or impractical project constraints. Other factors that contribute to UX debt include:

• Skipping user testing
• Disregarding brand standards and style guides
• Design by committee
• Misinterpreting the product vision
• Acquiring or merging with other products
• Poor communication or documentation
• Insufficient QA testing
• Legacy code or delayed refactoring

Why is it more expensive to fix a UX problem later, rather than before launch? For many reasons. First, redesigning and recoding consumes many resources: the team has to refamiliarize with the nuances and details of the already launched features, spend time debugging them, and then possibly retrofit other parts of the software. From a pure software-engineering perspective, coding the UI right the first time is much easier on the developers than having to change shipped code. But there are also user-experience reasons for the extra cost of UX debt:

• Launching a suboptimal design impacts long-term market share, because many customers will give you one try and then give up when the design is too difficult or doesn’t satisfy their needs. Even if you fix their complaint later, the users won’t know, because they won’t resample your site or product once they’ve had a bad experience.
• Users will become accustomed to the bad design. Then, after you change the design, people will be forced to change their habits and hate you for that.
• Changing the design back and forth for any particular component of the overall UX will degrade the feelings of consistency and coherency.
• Your failures will live forever on the internet. Since learning is social, users will continue to be “informed” for years of your missteps by blogs, message boards, video channels, and other sources that discuss the old version. Not only will this outdated information be harmful rather than helpful to your users, it will also scare away new prospects who come across descriptions of the bad design and any awkward workarounds people had discovered and posted.

Any UX debt will incur some of these costs. But the longer the UX debt remains unpaid, the more these costs will mount (think of “compound interest” as an analogy).

An example of UX debt can be seen on FedEx’s website in a carousel that appears on the product page for printed posters. Initially, the carousel displays four related products; however, clicking on the right arrow to view more related products reveals only one additional item. Rather than filling the content area with more images and links to related products, the carousel shows empty white space. A user looking for invitations or similar printed materials may grow frustrated at the lack of relevant products in this carousel. FedEx should add more related products to the carousel or update the functionality to accommodate varying amounts of content. As time goes by, teams easily forget about these seemingly small issues and the likelihood of going back to fix them diminishes when there’s pressure to move on to other priorities. However, these issues do impact users and should be addressed to preserve the website’s integrity.

Though the word debt is daunting for most people, the metaphor does not imply that UX debt should be avoided at all costs. Especially when working in Agile, there will be cases when speed to market and pressure to meet release dates necessitate time-saving alternatives. While certain types of UX debt (such as problems with integration, inconsistencies, and trouble preserving a simple conceptual model that explains and unites the entire user experience) are more likely in Agile, any decisions that will deliberately result in UX debt should be made carefully and collectively. Consider if getting to market faster is worth the risk of negatively affecting user perceptions and the high costs of fixing issues later on. When the answer is yes, the resulting UX debt should be tracked, managed, and, paid back gradually over time so that users don’t notice it and abandon the website or application entirely.

Identifying UX Debt

UX debt includes any ongoing problems in the experience due to launching a fast, easy, or careless solution that negatively impacts users. Whether it is introduced deliberately or accidentally, it’s important to look for UX debt in these areas of the experience that are prone to debt buildup:

• User interface (buttons, links, and visual styling)
• Interaction design (movement from page to page, animations, and scrolling effects)
• Copy, content, and messaging (labels, headlines, and written text)
• Information architecture (navigation structures and content classification)
• Accessibility elements (contrast, visual focus indicators, text alternatives, etc.)
• Customer journey consistency
• Omnichannel seamlessness

For example, a press release on Symantec’s investor-relations website contains body copy that is too low contrast to be considered accessible. Though low contrast is not a bug, it is an example of UX debt that could negatively impact low-vision or color-blind users. Per the WCAG guidelines, contrast ratios between text and background colors should be 4.5 to 1 for normal-size text. The contrast ratio between the text color and background color on this page is only 3.2 to 1 and therefore, too low to be considered accessible. Symantec should have selected a body-copy color that meets accessibility standards and must now remember to go back and fix this issue of UX debt.

The best way to uncover UX debt is by getting real user feedback often and in a variety of ways. Though you should always conduct user testing before releasing sprint features, ongoing testing should also happen at least once a month and focus on the key flows and realistic tasks that users frequently do on your website or application. This approach will help you understand the overall health of the user experience and identify the most serious issues. Other user-feedback methodologies that can help you find UX debt include:

• Site-intercept surveys
• CSAT or NPS scores
• Issues reported by customer service

In addition to user feedback, set up recurring time with the entire product team, including developers, to review the overall health of the site or app. Open up the discussion for the rest of the team to bring forward any UX- or tech-debt items that may negatively impact the user experience. Product management can also bring up debt-related issues found by leadership or other stakeholders. If possible, share trends or patterns from analytics during the discussion so the team can decide together if further investigation is needed to identify debt.

Inconsistencies in the UI can be considered UX debt, but not always. It’s possible to have occasional slight discrepancies in the user interface that fit within the brand guidelines and don’t cause problems for users. For example, during an A/B test, there may be some temporary UX issues until the team understands which variation is optimal and whether it should be added to a design system. These types of inconsistencies should not be considered UX debt since the variations are temporary and intentional. (To avoid creating UX debt as a byproduct of an A/B test, teams should ensure that the winning elements are scaled into the design system with full consistency and clear standards for the new patterns or components.)

An example of an informational inconsistency in the UI that does count as UX debt was observed on Amazon. The shipping-for-returns page displayed inconsistent quantities for return items: the user wanted to return 4 pairs of pants, but the text on the page read Returning 2 items and the summary info said Refund subtotal for 3 items. This contradictory information caused the user to question the refund amount and to navigate back to the previous page to double check that the total estimated refund was correct. Amazon’s inconsistency is UX debt and should be addressed to help users move smoothly through the return process.

When actual UX-debt issues and bugs like these are found, their severity, frequency, and location in the users’ journey should drive the issue valuation and prioritization. Though in the following sections we discuss how to track, prioritize, and resolve issues when working in the Agile development process, the approaches and concepts outlined can be adapted and applied to any development methodology and will help you track, rank, and gradually clean up UX debt over time.

Tracking and Prioritizing Issues

Once UX debt items are identified, there are a few ways you can track them for prioritization. Each method has pros and cons, so it is important to choose one that works best for your team and organization. Common ways in which UX debt items are tracked include:

• Adding UX-debt items directly to the backlog for prioritization
• Capturing UX-debt items in a spreadsheet, then adding them to the backlog

Adding UX-Debt Items Directly to the Backlog

Putting UX debt items directly into the backlog can work well for teams that have well-organized backlogs with clear severity indicators and prioritization processes. However, for large, complex organizations that deal with many user stories and product-backlog items, adding UX debt directly to the backlog could mean those items get lost or continually deprioritized in favor of new features and functionality. One user-experience professional who favors this approach said:

“We track our UX-debt items using an epic in our backlog. During backlog grooming, we review the list of technical and UX-debt items, then we collectively prioritize and decide what to tackle in the next two weeks. We do this before we plan for any new features and functionality so we can balance cleanup with new features."

To make sure that UX debt gets the attention it deserves each sprint, create a product-backlog item or a label for UX debt and use the same severity indicators as for other items in the backlog. In this way, all items can be evaluated using the same dimensions for prioritization during grooming and planning. This method will also help teams look back and see how much UX debt was been paid back within a time period.

What will improve the product experience the most: a new feature or making an existing feature usable? Quite often, the latter choice is best, since a feature that people can’t use might as well not exist. Thus, fixing something that doesn’t work for users has the same effect as adding a new feature, in terms of what customers actually get to use. Therefore, UX problems with existing features could and should often get assigned higher priority than new features. Moreover, features are usually implemented in order of expected benefit, so that an old feature is likely to be intrinsically more valuable than a new feature, if only the old feature could be made to work for users.

Organize and Prioritize in a Spreadsheet

For teams with many UX debt items or complex backlogs, prioritize issues in a spreadsheet before adding them to the backlog. This method will protect the team from getting overwhelmed or ignoring long lists of product-backlog items. It will also help the product owner prioritize issues accordingly and add to the backlog only those UX-debt items that make the most sense for the product vision, users, and team workload. The following factors will reveal the biggest pain points in the users’ experience and should be included in the spreadsheet:

• Description of the issue from users’ standpoint (how is it affecting them?)
• Where in the experience it occurs (awareness, consideration, conversion)
• Frequency of occurrence (how often does it happen?)
• Who reported the issue? (user, team, stakeholder)
• Level of UX and development effort needed to fix the issue (low, medium, or high)

Score each issue by assigning a value to the experience area, frequency, reporter, and level of effort to fix the issue. Then, use a prioritization matrix in the form of a scatter plot to see where the issues fall on the dimensions of user value and effort to fix. This visualization can help you rank issues and communicate progress in cleaning up UX debt back to stakeholders and leadership over time.

Though the costs associated with going back and fixing issues will always be higher than launching with the ideal solution in the first place, it is still important to weigh all of these factors when prioritizing to avoid wasting even more time, effort, and resources when cleaning up UX debt. One user-experience professional who favors this approach said:

“We added our UX debt to the backlog, but it got lost and overlooked amidst all of the other competing priorities. By organizing items in a spreadsheet first, the product owner, lead developer, and user-experience designer can review them together and determine a few items to add to the backlog for the coming sprints. It feels more manageable to pay back our UX and tech debt over time.”

The most important consideration to keep in mind is that UX debt and technical debt should never be disregarded altogether. Many Agile organizations tend to prioritize tech debt over UX debt, but focusing on one type of debt over another will only lead to more problems for users and more expensive fixes in the end. It’s also important to realize that the two types of debt often go hand in hand. Don't completely abandon UX debt in favor of addressing tech debt, or vice versa. Prioritize efforts that aim to reduce tech and UX debt at the same time. It's more efficient and ensures you won't dig yourself further into debt by focusing on one type while abandoning the other. This approach will also help the product maintain full trust and credibility with users.

While the high-priority UX problems should definitely be fixed first, the lower-priority ones should not be abandoned completely. As the years go by, cumulated layers of barnacles will slow even the mightiest ship, and the user experience will feel like a lower and lower quality product, as users encounter small annoyances every step of their way.

Resolving UX Debt

Paying down UX debt can feel daunting at first and will take time, but there are a few ways to resolve it while still making overall improvements to your digital products. One approach is to dedicate a specific number of story points to fix UX debt during each sprint or every other sprint. The number of story points can fluctuate over time depending on the team’s workload, but try to address at least one or two UX-debt items per sprint, preferably more if bandwidth allows. Use easy-to-understand visualizations, evidence from user testing, and clear explanations of what was accomplished in each sprint to help leadership and executives understand the progress made and why it’s important.

Another approach is to plan a quarterly sprint dedicated to cleaning up tech debt and UX debt. The team should collectively decide what areas to focus on in the cleanup sprint and, at the end, show what was cleaned up. If an entire sprint isn’t feasible, some teams will take a day (sometimes referred to as a cheese day) rather than a full sprint to address as much UX debt as possible. Approaching resolution in this manner gets stakeholders and leadership on board with addressing debt items frequently, especially when progress can be demonstrated and communicated in terms of user and business value generated.

Conclusion

UX debt isn’t always avoidable but teams can organize and collaborate around how to address it. Include all of the right people as early as possible to discuss the risks of a premature or haphazard launch and develop a cadence in looking for less-than-optimal experience elements. Conduct regular user testing and heuristic reviews of the experience to ensure new UX-debt issues are found and prioritized. Leverage data, such as the scores used in severity plotting, to make the case for why certain issues warrant resolution over others, and show progress in debt-cleanup efforts. Acknowledging and formulating a plan for paying UX debt back over time will help you resolve it, before your users start to notice.

For more information on how to identify, prioritize, and resolve UX debt, take our full-day training course, Lean UX and Agile.

Reference

Technical Debt Wiki