Unless you’re an economist, you might be surprised to hear that money lending — debt — is among our most important inventions. It’s made everything possible from exploring the New World to the industrial revolution and the moon landing.
Debt is helpful for software development, too. In that case it’s about borrowing time: we’re choosing to develop code quickly when a better path is available but would take longer. Accruing “technical debt” supports the rapid iteration and experiments necessary to find product-market fit before (borrowed) cash runs out. Later, it helps to maintain a mad pace in pursuit of growth.
But technical debt, like financial debt, must be repaid. It’s important for developers to take the time to revisit the code and correct it. If this doesn’t happen, developers become increasingly hamstrung by hacks and cut corners.
And there’s the rub. The pressure to move quickly can be so intense that technical debt accrues out of control. The risk of bugs and overall instability increases. It takes longer and longer to build new features.
It happened to Microsoft. It took five and a half years to move from XP to Vista. Jim Allchin, president of Microsoft’s platform products and services group, said that development was “crashing into the ground” because of the “haphazard” way features had been added.
What is Design Debt?
Rapid iteration and experimentation in software incur “design debt” as well. There’s no point in carefully researching and perfecting UX for software that might not succeed. Like technical debt, design debt must accrue. You try stuff, you learn, some of what you learn has implications for what you’ve already completed.
Debt can also accrue naturally over time as the original design becomes unable to handle additional features (“You want to add another tab to the homepage?”). The original UX was designed to create a cohesive experience around a specific set of features. The addition of new features over time breaks that cohesion, reducing consistency and creating a UX that feels increasingly disjointed.
In some cases, design debt is consciously maintained within an existing product because there’s a fear that changing the status quo will upset users. This fear isn’t unwarranted. Users build muscle memory around an interface. They learn to use it effectively to solve problems. Any change, no matter how well designed, will increase the time it takes to solve those problems and can cause a vocal backlash. At least in the short term.
How to Know if You Have Design Debt
The good news is, design debt is a necessary and even good part of designing a software product, because debt is accrued as you learn new things about your product, business and users. Obviously you can’t refactor everything you’ve already done instantly based on what you learned, so you have debt. If you have zero design debt, it’s because you haven’t learned anything recently.
Of course design teams are the experts and can advise on when design debt needs to be actively managed down, but others on the team can also tell it’s become unwieldy when seemingly small changes require massive lifting. The design team can explain rationally why, but it just all seems ridiculously hard. Sales teams are often the canary in the coal mine here, and when demo’ing the product will find that competitors are beating them in an overall sense of professional user experience. Training times and support calls may go up as well.
Design Debt Impact
Just as too much technical debt can slow development, too much design debt can reduce the adoption of new features and slow growth. Existing users find it more difficult and time-consuming to use the product. New users are frustrated by the learning curve. Competitive products with a better experience (even with fewer features) seem more compelling, and churn increases.
Design takes longer because designers have to account for a hodgepodge of features without logical relationships to one another. For example, imagine a product that over time has somehow evolved three different navigation strategies. It’s more common than you might think. Supporting a new feature means UX must remember, spec, and update it in three different places. Moreover, imagine discovering along the way that an earlier feature accidentally was updated in only two areas, and also must be fixed!
As design debt builds, already-slogging designers may start to sandbag. Worried that they’ll never get a chance to come back and “do it right,” designers will be tempted to overestimate timelines and insist on many more revisions to the work than anyone else wants.
Designer’s unhappiness grows with their inefficiency. They would rather do the bigger impact stuff, but instead they’re trying to track down and update every version of the stupid footer, or somehow rationalize two competing features that do the same thing.
Even in the case of an established product whose users complain about any change, it will become increasingly difficult to accommodate new features without changing the design.
How Engineers Deal with Technical Debt
You must service a debt of any kind, or it will continue to grow. The trick is to pay down the debt before interest payments become overwhelming. Marty Cagan describes eBay’s practice of tackling technical debt by allocating a percentage of engineering capacity to something they called “headroom.”
The idea is to avoid slamming your head into ceilings. You do this by creating room — headroom — room for growth in the user base, growth in transactions, growth in functionality…
Product management takes 20% of the capacity right off the top and gives this to engineering to spend as they see fit — they might use it to rewrite, rearchitect or refactor problematic parts of the code base, or to swap out database systems, improve system performance — whatever they believe is necessary to avoid ever having to come to the team and say “we need to stop and rewrite.”
Investing a portion of resources in an ongoing way prevents debt from accumulating out of control. It also helps keep a handle on the cost of dealing with debt, because in most cases predictions about the time necessary to reduce accumulated debt are optimistic. Marty Cagan again:
You might think that rewrite will only take a few months, but invariably it takes far longer, and you are forced to sit by and watch your customers leave you for your competitors.
How to Deal with Design Debt
If designers don’t have the headroom to refactor UX alongside the development of new features, somebody is eventually going to call “redesign!” It may be someone outside the company: an investor or board member with some experience and perspective that recognizes things are a mess and isn’t worried about how it happened.
They’re going to call you on the product being unprofessional, looking dated, or being too difficult to use, and they’re going to be right. Sometimes a redesign will be warranted because of new trends in visual design, but nobody wants to be on the receiving end of an email about how their work over the last few years has culminated in an “outdated, unprofessional, mess.”
Ultimately a complete overhaul is time-consuming and expensive, often requiring the retraining of internal sales and support staff, as well as the re-education of users and inevitable backlash from those same users because they’re unhappy that their cheese moved.
To avoid this, the larger team, not just the designers, must agree the design debt exists and that it’s important to address. Especially product management but also engineering needs to be on board. Executive stakeholders should be aware of the issue as well.
Finally, just like technical debt, cycles must be allocated. Designers can keep a personal prioritized list of design debt, but ideally, this is shared in the same system where the rest of the product team tracks stories or features. Teams can plan ahead by allocating time and resources by keeping the Pareto Principle in mind: 80% of user outcomes are based on 20% of product variables. Using this 80/20 rule as a starting point, teams can start by allocating 20% of resources to address usability issues and adjust accordingly depending on circumstances.
If you have stories or questions about your own design debt, and how you handle and budget time for it, we’d love to hear from you!
Don’t ignore your design debt
We offer strategic services for assessing and tackling design debt.
Get in touch today to get your complimentary consultation.
Originally published at www.designmap.com.
