Design Debt: What They Don’t Tell You About Design Thinking

Design Thinking is fantastic. It’s enough of a set process that teams can work consistently in its framework and it’s agile enough to allow for the flexibility of introducing new product design ideas midstream. It allows for a level of creativity and experimentation that typically doesn’t exist in other, more rigid development processes. 

But there can be a downside to incorporating new product design ideas or features as you’re working on a software development project: design debt.  

Wait, what’s Design Debt? 

Design Debt is when new design elements are added to an application without considering how all these individual elements will eventually fit together. The end result is an app that has some great features and might look nice but lacks a design pattern or clear path of usability for the user. That usually means that important items might be hidden behind too many tabs or that the overall UX is just clunky.

You’ve probably heard of technical debt—the idea that choosing the easiest (rather than best) software development solution now causes headaches down the road as new code is added in.

Design Debt is similar, but while technical debt is a pain for other developers working to untangle cobbled together code, Design Debt has some pretty serious and negative implications for the end-user. Bottom line—your app will need some help. 

Why is Design Debt so dangerous? 

The worst part about design debt is that it’s not something that happens all at once. It creeps up on you, building and building until it’s big enough for you to notice. By that time, it’s a massive headache and a big mess to clean up. 

We recently partnered with a client whose work fits this design pattern perfectly. Prior to working with us, they had worked to further refine their app and to make it as useful as possible. And they were going about that in the right way. They were asking the right questions of their users and understood the problems their customers faced when using the app. 

The design issue was that they never fully mapped out how to best integrate the new features and functions in a holistic way. So, instead, they added a feature here and a functionality there. The end result was that the app contained all that the users wanted and needed, but was visually confusing. No one really knew where to look for the things they needed. The design debt had mounted up, and their users were paying the price.  

How can I avoid Design Debt? 

Plan time in your product lifecycle for designers to take a step back and look at all the individual feature components and see where they might be regrouped or reorganized. Don’t neglect to also plan for the time needed to refactor and move things around. Streamlining or removing feature components can help pay off Design Debt early before too much interest has built up and you’re looking at a rewrite. It’s cheaper to fix it in smaller increments rather than 3 years down the road and it’s a major rewrite for a development team. 

One great way to head off design debt is to take your app through a design audit, something that is a part of our Customer Experience offering. If you’re curious about what other benefits Customer Experience offers, get in touch.

Now, this is great if you’re just starting on your app and have the time to build all these processes into your design. What if you’ve found that you’re already in debt with your current app? Stay tuned for Part 2 – How to best manage design debt. 

Angie Terrell

Reviewer Big Nerd Ranch

Angie joined BNR in 2014 as a senior UX/UI designer. Just over a year later she became director of design and instruction leading a team of user experience and interface designers. All told, Angie has over 15 years of experience designing a wide array of user experiences