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 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 ideas or features as you’re working on the 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 elements will eventually fit together. The end result is an app that has some great features and might look nice but lacks a 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) 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.
In short, Design Debt occurs when new design elements are added to an application without considering how all the disparate elements will eventually fit together. The end result is an app that has some great features and looks great but lacks a clear path of usability for the user. Maybe that means there are important tabs hidden behind four or five clicks or information that is necessary to the functionality of the app that isn’t clear. Bottom line—your app will need some help.
Why is it 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 did some work for a client that fits this 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 problem 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 it?
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 User Experience 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.
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.