During the product design–development process, it’s natural to accumulate a buildup of excess code, design elements, and unanswered questions, but even more so if you cut corners.
In this article, you’ll learn what design debt is, how cutting corners leads to design debt, why that’s a bad thing, and what can be done to ensure that we don’t incur it.
Design debts are mistakes made during the design process that become expensive to fix later on. Making mistakes during the design process is perfectly normal, especially during the solution phase. Gradual improvement via learning and iteration is just a part of the process, and many mistakes can be fixed without having caused much or any harm; they’re simply identified via UX research or bug reports (if they aren’t discovered internally first), and eventually fixed.
However, some mistakes are so costly that they incur “interest,” meaning they cost more time and money to fix later than if we had fixed them earlier or never had them to begin with. This can leave product teams overwhelmed, overworked, over budget, missing business objectives, and ultimately, losing revenue.
Either way, these are called design debts, although only the ones that incur interest do we typically refer to that way.
The term “design debt” comes from a similar term, “technical debt.” Technical debt refers to a number of bad development practices that result in bugs, incompatibilities, and unreadable code that performs poorly. This ultimately leads to revenue loss, just like with design debt.
However, design debt is caused by two bad design practices — abstaining from design systems and abstaining from UX research.
Let’s dive into both of those.
As a design matures, naturally it’ll accumulate more properties and components over time. Some of these properties will be easy to remember (e.g., font family names), but others not so much (e.g., color codes), and so it’s easy to end up using something different.
Even when duplicating, inconsistencies can occur if we forget to update one of the instances. On top of that, new product requirements can lead us to “quick changes” here and “just a small thing” there, and before long our design can end up with a wild amount of visual and functional inconsistencies.
There are three problems with clutter and inconsistency. Firstly, it makes our design files slow and confusing. Secondly, these inconsistencies make it into the final product as developers translate them to code using design handoff tools — and they too will find it slow and confusing.
Finally, lack of consistency means lack of patterns, which makes it difficult for users to learn how to use our product. Ultimately, everybody gets confused and the business loses money because the team can’t operate the unmaintained design file efficiently and the users can’t use the product efficiently.
The root of the problem is that we don’t want to tidy up our design and we certainly don’t want to create a design system while we know that our design will be constantly changing — it feels like a waste of time to tidy up what we might not even use, particularly in the early stages. Plus, it’s pretty boring and disrupts the flow.
However, we don’t need to solve the entire problem right away. The root of the solution is finding the perfect balance between order and speed, but let’s get into the practicalities of it all so we can see what that actually means.
In the beginning, don’t worry about this until developers enter the chat or until you’ve validated your core solution — whichever comes first. If you’re kicking things off with an MVP (Minimum Viable Product) then these are usually the same thing.
Once you’ve gotten at least a rough idea of which properties and components you’ll be reusing, set up the tokens, styles, and components in Figma (or the equivalent in whichever UI design tool you’re using) needed to make that happen and then implement them to iron out any initial inconsistencies.
If you have any thoughts regarding the logic behind the reusability of any properties or components, note them down. The tokens/styles/components combined with these thoughts can be the jumping off point for creating a design system (later), the ultimate tool for maintaining consistency, reducing bloat, and designing with purpose. Build up this design system gradually, striking the perfect balance between order and speed, at the same being mindful about the visual cues used and where they apply.
Ultimately, you’d tidy up, reuse, and document along the way, causing minimal disruption to your design workflow and creativity. Remember to delete any unnecessary layers too, and don’t worry too much about designing flexible components for scenarios that you haven’t yet encountered.
Although products are rarely ever considered “finished,” you will at some point consider yours “finished for a while.” This is the point at which you’ll want to consider upgrading your design workflow into a more sophisticated DesignOps process, particularly if other stakeholders need to use this design system.
The first step is creating design system documentation to ensure that anybody who participates in design of any kind (this includes nondesigners using design systems to prototype) can not only do so quickly but browse the different properties and components available and understand which ones they need.
The second step is establishing a review process where you (and others) can suggest design system changes, explain what said changes are for and why they’re designed that way, and have nominated individuals weigh in before ultimately merging and finalizing those changes. Figma’s branching features are undoubtedly the best way to do this since no other UI design tools offer such features.
The final step is to establish a process and workflow that enables stakeholders to suggest problems for which they don’t have a solution for that could be solved by making changes to the design system. The best way to handle this from my experience so far has been to write tickets in whichever product management tool is being used — tag the designers who can then use a plugin to pull the ticket into their UI design tool of choice and also tag the developers so they can weigh in from a viability perspective. Contain the discussion within the ticket to avoid overcomplicating things.
If you’ve already accumulated design system debt (or suspect that you have), then naturally the goal is to reduce how much time and money you’re wasting via stakeholder and/or UX audits.
If the problem is that stakeholders are having difficulty using the design system, then unfortunately you’ll need to complete the above steps. It’ll be very long and very painful, but you can at least use stakeholder feedback to address the most confusing aspects first and then commit to improving the design system over time.
If you suspect that visual or functional inconsistencies are impacting conversions, then it’s time to put your research hat on. Start with heatmaps to see if there are any clear-cut mis-clicks or hesitations. This can help you delete components that just aren’t working — A/B test an alternative if you’re not sure what to replace it with.
Next, use visual affordance testing to see if users understand what different components do; this requires you to recruit participants, but provides context. Alternatively, you can use session recordings — this doesn’t get straight to the point like visual affordance testing does, but it does enable participants to put themselves in a real scenario as they talk about the pain points they encounter.
Either problems can warrant deep pattern refactoring, but if you’ve accumulated design debt to the point that you’re experiencing both of the aforementioned problems to a high degree, then it’s worth discussing the benefits of a strategic redesign. This doesn’t mean starting from scratch by any means — you’ll choose the aspects of the design system that you like and perform well and build a new design system using them. This approach is far less anxiety-inducing, awarding teams the productivity to launch this quickly and successfully. This option is better than you might think.
Communicating the value of addressing design debt isn’t as difficult as you might expect either, at least in my experience. Explaining that not having an organized design system will ultimately cause delays is usually enough to get buy-in for a design system. Worst-case scenario is that you assume personal responsibility for organizing tokens/properties/components/notes along the way.
If that doesn’t work, explaining the possibility of poor UX (reframed as fewer conversions or less revenue) should do the trick. There are a number of studies that you can cite that indicate that having/improving a design system is beneficial:
At least half of the design process consists of research, not actual design. Most research methods follow the same pattern: discover a problem using formative research, solve it with design, confirm the solution using summative research. Product teams that skip research and jump right into the design with the intention of saving time and money find themselves in design debt.
By skipping critical research processes, instead opting to take educated guesses (or worse, just guesses), you’re risking not only making the wrong decisions but not fully understanding why they were the wrong decisions or how to get back on track. This can take you back to square one after already investing resources in a failed attempt. For startups, it’s an instant killer and surprisingly common.
There’s no telling how many of these decisions will work out, although the Dunning-Kruger effect suggests that we probably overestimate our abilities. Failure to consider all options, instead assuming that the chosen option was the only option, plays a pivotal role too.
There’s not much to be said about what and how. Simply do the necessary research; don’t skip it and make assumptions. Yaroslav Malymon put together a terrific guide to the different types of UX research and when to use them.
In some ways, research debt isn’t as bad as design system debt. The reason for this is that failure is a part of research — when you’re not improving, you’re learning from mistakes and using that to improve. Blowing almost the entire budget on a failed attempt obviously isn’t as ideal as putting in the research, which saves time and money in the long run; however, embracing failure is the core principle of research so you can be saved.
Similarly to that of design system debt, you’ll want to mitigate the damage with cheap and quick solutions first. Some great options include:
These research methods take a bit longer, but are still quicker than some other methods:
There are a ton of case studies that indicate the value of research that you can cite. That being said, the value of research is so commonly understood that we have to wonder why product teams continue to skip it. Well, the problem is not misunderstanding the value of research but what a designer actually does. Sure, designers are knowledgeable about design heuristics and this enables them to make smart design choices, but this isn’t enough.
So rather than communicating the value of design research, which I’d say is commonly understood already, it should be made clear that designers can’t read users’ minds, and thus can’t design a product that meets business objectives. The perception is that designers do research purely by thinking when in reality they need to be given the time and budget to collaborate with users.
In actuality, businesses generally welcome the idea of research but reject the idea of spending time and money, not realizing that that’s simply not possible. Therefore, getting buy-in for research should be about highlighting the questions you have and explaining why only users can answer them.
If that doesn’t work, then citing studies is still effective. I’d recommend using Drawerrr to identify case studies within your niché or industry. With any luck, you might even find your competitor doing research and seeing results!
The key takeaway is…just avoid design debt. In 2023, research and design systems are no longer considered processes that can be skipped — they are the process. Without them, we’re just mindlessly creating rectangles and content to put in them.
The good news is that reframing the process in this way reminds us that the process is incremental — when building design systems, you’re creating consistency and documentation bit by bit; and when doing research, you’re learning and implementing bit by bit. It’s a series of small changes that in reality doesn’t require even a fraction of the time and money needed to recover from design debt.
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Nostalgia-driven aesthetics is a real thing. In this blog, I talk all about 90s website designs — from grunge-inspired typography to quirky GIFs and clashing colors — and what you can learn from them.
You’ll need to read this blog through and through to know what’s working and what’s not in your design. In this one, I break down key performance metrics like task error rates and system performance.
Users see a product; designers see layers. The 5 UX design layers — strategy, scope, structure, skeleton, and surface — help build UIs step by step.
This blog’s all about learning to set up, manage, and use design tokens in design system — all to enable scalable, consistent, and efficient collaboration between designers and developers.
Learn more →
