UX Debt: Borrowing From Your Users

In financial terms, “debt“ is money borrowed by one party from another. The borrower can spend money they currently don’t have with an obligation to pay it back later, usually with interest. So, the borrower is willing to trade off added cost (interest) for immediacy (spending money now).

Debt allows us to buy things we couldn’t otherwise afford with cash, like a house or a car. It lets us invest our future, for example by funding an education or a business start-up. When the equity of our investments exceeds our debts, we come out ahead in the long run. Score!

But too much debt is a Bad Thing. If not repaid in a timely manner, the interest can surpass the debt. This leads to economic ruin. So it’s the management of debt that’s key, not avoiding it entirely.

“Technical debt” is a term programmers have been using for over a decade. The metaphor is simple: in software development, there are quicker ways to implement technology that are often messier and cut corners. There is a trade-off of immediacy over comprehensive system development.

But if left unchecked, these trade-offs ruin the overall technical system. Here’s why: with each future effort, programmers stumble over shortcuts in the system made previously for the sake of speed. This increasingly slows them down, which is like paying interest on a loan. Eventually, new development is unprofitable and not worth it all.

Ward Cunningham first used the metaphor “technical debt” to explain the refactoring work programmers strive to do. See his web page “Ward Explains Debt Metaphor” for more. Be sure to watch the video.

UX DEBT

I’d like to encourage the use “UX debt” as a way to reflect the accumulation of learnings about improvements to the design of a product or service that go unaddressed over time.* UX debt is the difference between the desired user experience and the delivered product or service. Left unchecked, a backlog of UX debt can lead to a downward spiral of negative experiences.

I’ve been using the phrase “UX debt” in my past and present work, and it seems to resonate with people, making the notion of trade-off clear. And the language we use makes a difference. For instance, during a recent product UI review with my ex-colleague, Uday Gajendar, now UX design director at CloudPhysics, we were able to effectively characterize the build-up of neglected improvements as “UX debt.”

Debt – financial, technical, UX or otherwise – is inherently invisible. This makes describing it and quantifying it difficult. The banking industry has very clear means of doing showing how much you owe. The UX field should work on similar mechanisms to make visible the consequences of cutting corners over the long run.

Usability tests and heuristic evaluations catalog issues explicitly. This helps. Other measures include satisfaction surveys, such as SUS (system usability scale) and even feedback from NPS (net promoter scores). While useful (and even necessarily) in some organizations, these activities are “heavy” and time consuming. Alternatively, Lean UX methods seek to more rapidly come up with solutions that apply learnings from users.

The key is acknowledging UX debt and managing it actively. Note that this doesn’t necessarily mean getting everything right the first time, but implies getting UX fixes refactored and prioritized quickly thereafter. Paying down the UX debt is the real challenge, not tracking it, particularly in large organizations.

Keep in mind, the user’s experience is not in a closed system. UX debt is influenced by external forces in the market. Regardless of your industry, your website is one click away from someone’s favorite; your app sits right next to other popular apps (including games) on a smartphone or tablet. From a user’s point of view, their experience with your product competes with all other experiences they have. So, UX debt can shift quickly with user expectations: a great idea two years ago may seem outdated today.

“Just add another tab” or “Let’s squeeze a button on the UI” are signs that you’re incurring UX debt. Such short-term tactics may be OK initially. But at some point the overall design system or information architecture breaks. UX design cannot be continuously thought of like dressing up Mr Potato Head without going back and refactoring the UI.

UX debt accumulates almost instantly. Design must be iterative: it’s about ongoing optimization. And your processes must account for that. Very often Scrum and Kanban approaches are blind to UX debt. So also be cautious of we’ll-get-to-it-later promises. Jeff Gothelf sums it up well in the first sentence of his best-selling book, Lean UX: The biggest lie in software is Phase II.

One tactic is to plan a sprint or cycle in the middle of development reserved just for refactoring. Engineers can iron out their system issues during this time, but keep some resources available to fix known UX problems. Precede this sprint with a usability test, and you’ll have direct input on potential problems and fixes. This is commonly referred to as a design spike. In addition, plan time and resources to re-apply learnings back into the product design after launching. “Build > measure > learn” is a loop the implies starting again with “rebuild.”

With UX debt, the currency that’s borrowed is user efficiency and user frustration – things they own, not us. The cost we’re OK paying is reflected in sentiments like: “Sure, we know how to make our product easier to use and better for our customers, but we’re not going to do it.” It shouldn’t be an “or”: we need to manage technical debt and UX debt. It’s worth mentioning that the two may have overlap. For instance, slow load times may be the result of technical debt that also incur UX debt.

Ultimately, addressing UX debt must be a commitment from the organization. For UX designers, the language we use can help gain support. The metaphor “UX debt” illustrates the impact of short-term decisions on the user experience. Remember: if your user experience goes bankrupt, your company just might too.

—
* see more from Will Evans, “On UX Debt” ; Ben Melbourne, “UX Design Debt” ; Glen Lipka, “The UX of Technical Debt” ; Andrew Wright, “User Experience Debt“