A weekly reflection of what I have learnt this week as a Digital Product Designer

This week I spent time working and wrapping up the second sprint of work with a new client. During this time another designer and I spent a day refactoring the UI elements we had already created in sprint one to improve them for the next phase of work. This process is pretty standard in Product Design as it follows the holy grail of the Lean UX approach — Create, Build, Test, Iterate. Though it’s great to work like this, as constantly improving our work and pushing the standard of our output is important it also creates problems for us. This problem is called Design Debt.

Design Debt is a concept based on Technical Debt in development. The idea is that at the beginning the Design is fresh, new, a right for that moment. However, as we create iterations and make improvements sometimes old elements of Design get left behind or not brought in line with the improvements and this is what we call Design Debt. During this article I’m focusing purely on the UI aspect of Design Debt, UX will have Debt too, if anything I would say Debt in this area is far more prominent but that is an article for another time — in the meantime, I’d recommend this article by the Neilsen Norman Group.

Iterating a Design over time is probably one of the main causations of Debt in our work but this debt can also be created due to new elements being created that weren’t needed or thought through before. For example, say you have started a new project which was a one-page website and the only requirement was an email sign up form, you design the form and you pass it over to your developers to create. Then a month later this website is going to expand to have a login page too, you’ve now decided that actually due to this expansion and testing over the last month you’d prefer your input fields to have the labels above the input box rather than inside them. These micro-changes are fine but when they aren’t applied to the previous work can create the debt or worse you can have two styles in one file which creates confusion for future designers working on this project.

Another way that Design Debt occurs is through tight deadlines. We all know that having a difficult deadline can turn the most organised and perfectionist designer into the proud owner of a chaotic Figma or Sketch file. Being messy is fine when the work needs to be done, it has to be done, and our clients aren’t paying us for beautifully named layers and well-defined components or symbols. However, by rushing through the Design process and making without too much thought we run the risk of actively making things worse. We may create a secondary button, when in fact we have a style version already or we have something similar as we’re so focused on the deadline and getting the work done, we look towards making quickly, as spending time assessing what we have already may seem like it would slow down our workflow.

Another area which Design Debt is created is through bad communication in the team. This is similar to the above, in that it’s based around making use of our time effectively. In design teams many of us will work on more than one project, that means picking up files we are unfamiliar with and making assumptions on what has and hasn’t been done. If the previous designer hasn’t documented what Design decisions they’ve made and why it can be difficult or near impossible for a future designer to ensure they aren’t creating any Design Debt due to misunderstanding.

I’m sure I don’t need to say it but, Design Debt is bad. Not only does it pile up incredibly quickly, but also impacts our work until we’ve fixed it. Design work that contains a lot of Debt is incredibly inconsistent, it looks bad, and will ultimately create a poor user experience. Debt occurs when the designers try to save themselves time or avoid aspects of the hard work/decision making but by doing so they are putting the burden on either the development team or the user.

One of the first ways we can prevent Design Debt is by just slowing down! A lot of designers want to go steaming in and get to work creating the most beautiful piece of UI anyone has ever seen. Obviously that’s great and we can appreciate the enthusiasm but if you’re picking up existing work, or either creating a UI from scratch there are some basics that should be covered upfront to prevent a lifetime of pain from Design Debt later on.

The beginning of the project is the most important area where we can prevent the Debt build up. The start of the project is where any decisions made are the ones that will have an effect throughout the entire Design and ultimately the product. From previous experience, once something is signed off in the Design and ends up in the build you’re going to have a really difficult time convincing everyone involved why it should be removed or changed.

In all Design, we have the basic elements—type and colour. Every Design project in the world is created by these two things at a minimum. That means when you are setting up your Design file for the first time, or taking ownership of someone else’s, spend the time looking at the colours and ask yourself or the owner what the primary colours are and what they are used for. Also, look at the type used, is there is a type scale? Is there an obvious or consistent use in type used on headings or the body text.

If you’re creating a design from scratch this is the perfect time to set up some rules around colours and turn these into styles. I’m not talking about setting up an entire design system from the get-go, but I am saying that ensure your colours and type are consistent from the beginning is very helpful.

Another aspect to making sure you start on the right foot is to make sure that your colours and font are accessible. I’ve spent time trying to make historic designs accessible and this process in itself is fine, but if you’ve spent 6 months using a colour that was the perfect shade of pink, to then have to change it to something darker because the text on top of it doesn’t pass accessibility, it’s very annoying, especially if your file isn’t set up with colour styles. You’re best getting this groundwork done first, not only will it make your users life easier if they have accessibility issues but it also feels great to say to the client or the developers that your website design is accessible before it’s even built.

This may not sound like prevention but it kind of is. It’s easy to get swept up with the excitement of making and designing and before you know it six months have passed and the project has finished and the final site is built and this build may be swamped with design hangovers. This is where we need to manage our projects a bit better and look at them in a shorter time frame such as weekly sprints.

Ideally, if you’re picking up a project it would be best to look at what already exists and familiarise yourself with the design decisions that have been made. If you and the team have been creating UI work that week, make sure you schedule some time in perhaps the day before the end of the sprint to look through the Design work generated and actively look for Design Debt. Ask yourself if there is anything new that didn’t exist before such as button styles or new card components. Question yourself and the file, look if there are elements that are the same but slightly different, are there any inconsistencies that could be dealt with before this sprint finishes.

We all know that we have good intentions that we will fix or resolve design conflicts but we rarely get the time do so this lengthy piece of work at the end of a project, and unusually would a client be willing to pay for us to clean up files. But also sorting out Design Debt in one chunk of time is an awful task to do, but by spending weekly time doing a clean up we can prevent a huge unmanageable Debt pile up. One of the best ways to deal with Debt is having a Design System or as we call it a single file of truth but I understand how in realistic circumstances this can be difficult, time-consuming as well as unnecessary to create.

This has been a really quick run-through of how we can preventing Design Debt in our work and I understand that the issue can be wider and more detailed than this — resolving it will always be an ongoing battle. But it’s something as designers we should be mindful of as it does streamline our process if we can get on top of it, but it will also ensure we provide a consistent and better User Experience.

If you want to read more about how do deal with Design Debt I really recommend these articles:

Invision: How to Tackle Design Debt

.GOV: Tackling Design Debt on GOV.UK

Austin Knight: Design Debt

How have you dealt with Design Debt? Is a Design System the only way to combat Debt? Does Design Debt not matter? Let me know your thouhts!

If you want get in touch you can find me on Twitter as @LizHamburger

#WhatLizLearnt