User Experience Debt
Technical debt is only half the battle
Technical debt is a pretty widely covered topic in the tech world. It was coined by Ward Cunningham to describe “those internal things that you choose not to do now, but which will impede future development if left undone” in software projects.
Product teams and their designers, in particular, grapple with their own variety of debt that seems to get less attention: user experience debt. UX debt is more user facing in nature than technical debt, but the vicious cycle that creates it is fundamentally the same:
- Product teams take design shortcuts, both intentionally (e.g. an inconsistent user flow that isn’t fixed to meet a product milestone) and unintentionally (e.g. an icon that unexpectedly confuses users)
- When left unaddressed, these shortcuts (“debt”) pile up and become increasingly difficult and impractical to fix (“pay down”)
- Eventually, UX debt begets more debt and the product degrades into an unfriendly, incoherent, and unusable user experience
The perils of subprime
You know you’re a subprime borrower when your team decides to “clean this up next release”. But the next release has a backlog of critical bug fixes, must-have feature requests, and of course plenty of new design shortcuts that emerge in the process. What’s more, the usage data for the last release is showing great engagement and no one has complained yet about the shortcuts you took. Fixing those can’t possibly be a priority right now. Before long, the team is grafting one design shortcut onto another, and the only way to unwind them is a wholesale reboot.
UX debt can be dangerously easy to both overlook and underestimate, making it that much easier to take on and harder to pay down. Relatively easy tasks, like tweaking screen layouts or updating visual assets, can be so easy that they sink to the bottom of product priorities (“we can fix that anytime”). Harder tasks, like refactoring user flows or redesigning navigation systems, can be paralyzing because they have system-wide implications and offer no clear path to make piecemeal progress.
UX debt can also be less visible to internal stakeholders than technical debt. First, technical debt manifests in ways that are immediately apparent and painful to the team, like app crashes or site downtime or productivity loss. Executives set hair on fire when a site crashes, but who’s lighting the match when users stumble through a sloppy flow? Second, UX debt can degrade the user experience in such subtle ways that users aren’t always able to identify or express it, even when a team does the hard work to aggressively integrate user feedback.
Climbing out of the hole
Trite as it sounds, the best way to eliminate UX debt is to not take it on in the first place. Clayton Christensen sums up the insidious dynamic at play in his essay on the “trap of marginal thinking”:
The marginal cost of doing something ‘just this once’ always seems to be negligible, but the full cost will typically be much higher.
Make it a cultural value to avoid shortcuts, technical and design alike, while in the grind of shipping product. Done right, this can flip the internal pressure from taking shortcuts to avoiding them.
When the above isn’t practical, or even desirable, prioritize eliminating the design shortcuts with structural or system-wide impact that are harder to unwind down the road. This involves tight collaboration between designers and engineers to make a joint assessment. “Easy” design fixes can end up involving far more engineering work than meets the eye and vice versa. Be careful to not paint yourself into a corner with product decisions that make incorrect assumptions about what’s easy vs. hard to fix down the line.
When your product does accrue UX debt, make sure to have a backstop that prevents it from piling up past the point of no return. Keep a running list of UX debt items and make sure it’s visible to the product team. Then create dedicated time and space for the team to pay down debt. This could be a fixed allocation of debt tasks every sprint, a dedicated debt sprint every few sprints, or whatever arrangement works best, as long as it’s explicit and sufficient.
Let’s do our part as product teams to recognize and manage UX debt in its own right. Dealing with debt is never fun, but it always pays off.
