Design debt. Classification and the price.

Published in

Platea Design Community Kyiv

9 min readJan 19, 2023

I want to start this article with the current situation in the world and why this topic is more relevant than ever. Some companies cutting teams and budget and even closing down. The work of the design teams became more complicated in the sense that specialists needed to calculate their time as intelligently as possible, to exclude all possible “unnecessary” activities and move on.

Against this backdrop, the question arose: “What should we sacrifice?”. What can we skip, what can we return to later, and what can we forget? The topic I wanted to describe today is not the prioritization of things (I already have a similar article, you can check it up), but rather the consequences.

What is “design” or “experience” debt? Technical guys are probably familiar with the term “technical debt”, because it’s something that can be encountered quite often in coding. Design debt refers to intentionally or unintentionally accumulated usability issues that are postponed. There is a similar situation with coding, but there is one rather important “but”: problems with usability and, generally, the experience of use do not pass one way or another without leaving a trace for the product. KPIs, support requests, the anger in social networks, etc.; in the same time at coding, technical debt is often not visible to the end user and is more associated with deficiencies in maintainability, testability, understandability, modifiability, and portability.

Design debt can arise from a number of factors, which we will now try to consider in terms of their types and what to do in each case.

Steve McConnell, author of Code Complete, distinguished between a deliberate and an inadvertent technical debt. We will use these concepts for our topic as well.

Deliberate

Without straying too far from the beginning of the article, we can easily imagine a situation where your team urgently needs to move on to open the money flow sooner; situation on the market isn’t good, so you really need to publish your product, and this would override all the possible drawbacks of this approach as well as cover the budget for eliminating the design debt. On the other hand, there is an approach where, for example, the team deliberately ignores the creation of documentation and common interface design standards and simply becomes an assembly line for the production of layouts. I think we can say nothing about potential support, onboarding, or handing over this project. This situation can happen for example if your design team is burned out or blindly follows the customer’s instructions, and you have no other priorities than to close the task.

How do you deal with this? In the first case, it’s pretty simple. If the team takes a deliberate risk, they talk to the customer or the team about the potential design debt they can cover through additional testing or other activities in the future. You should have a clear understanding that the risk is really worth it. There is no stagnation in business; everything moves incredibly fast, and such steps may seem desperate, but they can really trigger the growth or launch of your product or your team.

The second case is more interesting in terms of covering design debt and how it should be processed. Designers should understand the simple fact that there is a pretty good chance that they are not forever on this project; in the future, the team will grow (because you design great things, right?), the speed of learning, onboarding and the working environment are all investments, and the easier it will be to work in this environment, the sooner this investment will start to pay for itself. If you still intend to work on this project, even on your own, think about the users. Even looking at the existing components from a different angle, from a different perspective, search for alternative options can lead to better solutions that end users and the development team will appreciate. I like the analogy with chefs: you have to work clean, you better like the place where you work, and you have to feel comfortable to be there. Don’t forget common sense; understanding what you need and why is always relevant.

Inadvertent

My lovely startups. Imagine that you are lost in the jungle; you move sometimes without knowing where to go, learning in the process and dreaming of one thing – to get to the final point. You may not be aware that you are making mistakes or not following generally accepted patterns. Usually problems arise on their own, and you just deal with them as they come, learning from them. Not the worst-case scenario, I’ll tell you. Is it realistic to do something here? If you’re a designer, you’ve seen too many usability issues lately, or you’ve gotten “thrown” reports with analytics on your desk, and there are numbers there that you’re told aren’t very good. You have a few options for how things are going to work out. First, don’t criticize yourself, you don’t equal your job.

Try to understand how you can solve these problems, whether you have enough knowledge or need help from outside. Consultant and advisor services are always available, someone who has already gone through it will tell you how to construct the work process. You might be surprised, but startups frequently go for it, especially if you explain that the investment in a consultant will be much smaller than a future investment to close the experience gap. If the company or project is not willing to invest in it, but you realize that your experience is not enough to cover something, then the answer is simple: learn on your own. That knowledge will stay with you for life, so sometimes even your investment in it can be an option. It’s not always the knowledge that’s paid for money. I call it “investment” because you can just devote a couple of evenings to figuring something out.

Desing debt in current market situation

With shrinking budgets for everything, try to convey the concept of design debt to your project manager. Explain that there are things we can temporarily postpone, but in the future we will have to cover them and what are the consequences of not covering them are. Perhaps this option will be more appropriate. There is nothing strange about it; it’s business. You establish yourself as an expert, warn about the risks, and your managers will be clear about the final picture. They may refuse to do so, or vice versa, if they understand that it is better to conduct one more round of testing rather than limit the product in the future. Be flexible, understand the client and the time constraints, think about what you can do about it, and be sure to convey to the team the fact that sometimes making concessions about something doesn’t make it go away. Also, I want to say that it’s not as bad as it sounds. Sometimes the restrictions help uncover some things, recognize them, see if they’re necessary in general, hear what the users say about it, and then move on. Take it as a challenge and try to make your product better even in this situation. This attitude will make you a world-class designer, don’t even doubt it. Remember — communication is the key to everything.

Design debt repay

Okay, let’s talk basics about how to avoid having to redo the product in the future. How to keep documentation and what needs to be done? One lyrical digression: I won’t be able to cover all the cases; they will be unique to each designer, but I will try to give you some thoughts to help you think in the right direction.

Layouts

One of the most common problems is layouts. The gap between the designs and the actual product is too big. You may have problems with styles, functionality, and relevance here. Try to understand why the backlash is large; perhaps the technical team is not able to implement what you have in mind. Then it is worthwhile to just approve the final look of the conditional component and leave the leeway to correct the code. That will help development and testing understand what’s going on in general.

Handoff

I don’t like that word or the meaning that goes with it. Because a lot of designers think of handoff as something you have to transfer and forget about. But it’s not. The key thing that will help you 99% of the time is to talk to the developers. Focusing on globally accepted rules is cool, but it’s even cooler when the work is organized in a way that makes everyone comfortable and easy to work with. Find out if the development team needs styles and in which form, and then make the decision to create them. Talk through the naming and the design transfer tool. That is the whole secret of handoffs, which will help make the process work better: TALK WITH YOUR DEV TEAM.

Usability

That is a point at which it is difficult to give specific recommendations because all products are built and tested differently. So a simple tip that will help you save time, understand whether there is a need for testing and type of it, whether there is a budget for it, and most importantly, what goals and objectives you will cover with testing. Because doing usability testing, for example, without understanding the exact purpose will not always give you the desired result. Testing is important and necessary, but please understand why you do it and for whom(!).

Design debt repay — personal recommendations

According to personal experience, the moments I described above occur in 95% of all cases, of course, there are exceptions, such as accessibility or a problem at the design system level. Unfortunately, making specific recommendations is difficult because I need to understand the concept of the problem, but there is one recommendation that will help you understand whether you have a design debt. Conducting audits. As an immediate disclaimer, these recommendations are better for cases where you do not know for sure whether you have it or not, because if you have deliberately allowed something, you should surely understand how to cover it and not to spend extra time (but still you can do that). Performing a design audit helps you understand what’s with your layouts, styles, documentation, various statuses, and production. If necessary, make a pipeline of changes, approve them with the client, and get to work. I don’t think you’ll have any trouble finding information about doing this activity on the Internet. I hope that someday I’ll get around to writing about it.

Conclusions

I hope we’ve cleared up the wording. Moving on to practice, things get a little harder. After all, how could you possibly cover or describe all design or experience debt? It’s iterations of testing, interviews, and hours of design team work. Believe me, even if you start thinking about this concept or start intentionally applying it, it can improve your product. Share your thoughts with the customer or team, and explain to them that during the rapid growth we missed an iteration of flow testing that now has problems and you can fix them with the XYZ method. Keep your debt documentation as simple as possible, and don’t let it get out of hand, it could be hazardous to the entire product and require a significant investment to resolve. And remember the simple truth that you are not the only one facing this, it’s ok. Try to realise where you are, or if you made the decision consciously, what activities can help you close the debt.

Everything is about balance.

I’m curious about your experience with design debt. Share if you’ve encountered this concept and if you’ve been able to do something with it or not.