As someone who comes from a technical background, I had to spend a lot of effort learning to get comfortable with Design debt, or UX debt if you like. When working as a Developer you take pride in introducing as little technical debt as possible and quickly learn how much debt is too much debt. When it comes to Design debt however it’s not only okay, but actually encouraged. If you’re not sure what I mean but are intrigued, keep reading where I’ll describe what Design debt is to me, why it’s okay and how to manage it moving forward.
What is Design Debt?
Design debt is the notion that we have a design that works well, but may not be optimised for certain types of people or use cases. For example we may have covered an application being used on desktop, but opted to skip mobile optimisation or an application works well for day shift workers but hasn’t yet covered night shift workers in the same context. More work can be done to ensure we’ve made our work mobile friendly or takes into account night shift workers, but the debt manifests when we decide to push ahead with a release or prioritise something else.
Why is Design Debt okay?
There are three main reasons I like to use to remind myself why some Design debt is okay.
Sticking to a Human-Centred Approach
For a lot of newcomers, and even for some experienced professionals, you can forget that at the end of the day we are designing for humans. It’s not always practical and feasible to learn absolutely everything we can about the target users before starting to craft designs, but we can’t leave it till the end either. By taking an educated guess at first with some lightweight discovery activities we can come up with a candidate design, before evaluating that design on it’s merits with people before going back and adjusting our designs. This way we encourage the iterative process that gels well with Agile principles and allows us to distill in changes based on insights and learnings bit-by-bit.
Your work will never be finished anyway
Even if you’re only on a project temporarily or you think you’ve cracked the most optimal design, the wider social context changes as time passes. Fashion trends come and go just as what designs will make sense today versus tomorrow. Technology is also a great push factor that can alter the realms of what’s possible, allowing previously impossible or impractical designs to be achievable. Take for example smartphones altering how websites are consumed, where they are consumed and even the home screen interface going from skeuomorphic in 2007 to flat design in 2013 on iOS. Plan for things to change.
The Pareto Principle: 80/20 rule
Some of you may be aware of this principle; in short we can say that 20% of the effort will produce 80% of the results as a rule of thumb. If we focus too much on the remaining 20% of the experience we’ll spend far more time for far less results. Combined with the fact that you’ll never finish your work anyway, some prioritisation will keep the Return On Investment (ROI) value high. For example, if we spent all our time optimising our work to meet 100% of users we’d both never get it out there and could spend significantly longer than is necessary. I know I’d rather spend 6-12 months on 80% of use cases and get my product out there compared to 3, 4, 5 years or more to hit the impractical 100% of use cases.
Putting it into practice
Day-to-day we like to track our projects by using JIRA software. Just like bugs and defects that you capture and track in a software project, design debt can be captured and tracked in tickets in your backlog. I find it useful to also have a higher-level picture of the users and use cases, either with a diagram or spreadsheet, just to review what we have and haven’t designed for. As a designer this should be understood as a fluid document that can change as time goes on, and convey our progress quickly. I haven’t prescribed anything specific because what might work for me will be different for someone else. Find what works for you, your team, your problem domain and the tools available. You’ll know it’s working when you use it often!
Conclusion
If I haven’t convinced you, then I think you will benefit from trying this in practice. Design debt is when we intentionally put some users or use cases on hold, or deliver a portion of the experience. By doing so we: allow ourselves to test with real people and usually get better results anyway; accept the fact that our work will never be done, and prevent ourselves getting hung up on the “perfect” design; and finally do ourselves a favour by producing the biggest, most valuable work first, get it into the hands of people sooner and allow us to review priorities later down the line. Don’t forget to record your debt in the tool that you use as a first-class citizen, just like any other piece of work you do, and prioritise and track it accordingly.
