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.
- What is design debt?
- Design debt vs. technical debt
- Design debt caused by clutter and inconsistency
- Design debt caused by neglecting research
What is design debt?
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.
Design debt vs. technical debt
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.
Design debt caused by clutter and inconsistency
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.
Learn more →The effects of clutter and inconsistency
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.
How clutter and inconsistency build up
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.
How to reduce clutter and inconsistency in the early stages
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.
Upgrading to design systems and DesignOps
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.
How to recover from design system debt
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.
Getting the buy-in to address design system debt
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:
- GitLab said that the time spent solving real user problems increased from 25 percent to 50–75 percent after building a design system
- Figma’s design system experiment showed that they were 34 percent faster with a design system at-hand
- The Design System Survey paints design systems as successful, especially with established processes in place to help people use and contribute to them
Design debt caused by neglecting research
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.
The effects of neglecting research
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.
How research debt builds up
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.
The different types of research and when to use them
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.
How to recover from research debt
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:
- Redefining functional requirements (this helps to properly address user needs, for product teams that just went completely off-script)
- Reading reviews (these won’t be as thorough as user interviews, but they’ll certainly be your angriest users)
- Conducting a heuristic evaluation (this doesn’t fix a complete failure to address user needs but it can iron out usability problems)
These research methods take a bit longer, but are still quicker than some other methods:
- Card sorting to fix the navigation (this requires participants, but the exercise itself is quick)
- Session recordings to visually analyze what users are actually doing (this lacks insight into the user’s mind but it’s still very useful and doesn’t require recruited participants)
Getting the buy-in to address research debt
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
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: Analytics that give you UX insights without the need for interviews
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.
