A guide to choosing a strategy for paying off Design Debt.
Prioritization and adding Design Debt work to the roadmap require a cross-team collaboration and planning combined with a deep understanding of dependencies and risks. Aligning the Design Debt work with the general company direction increases the chances for the initiative to succeed. In this article, I will explore the most popular strategies that enable paying off Design Debt while supporting long-term product plans.
Paying off Design Debt can be approached differently depending on the Debt’s nature, scale and impact. After carefully analyzing the results of the Design Debt audit and connecting them with the other product needs, teams can choose between 4 strategies:
*Facelift, Refresh, and Redesign not only pay off Design Debt but also fix badly designed experiences to support strategic product plans. Paying off Design Debt usually is only a part of the effort.
Design Debt is usually addressed as a big initiative that groups many individual projects. Each of them is defined separately and handles UX, Visual and/or Operational Debt. Results are measured for each project separately as well as for the initiative as a whole.
The main goal of this initiative is to reduce the amount of Design Debt in the product and team’s processes.
Addresses mostly Visual Design Debt by making changes to the UI. During a facelift, how the product looks would change, but its behavior remains mostly the same.
A facelift can also be a systemization effort with small to no changes in the UI for the users, with the sole focus on improving how the interface is built and making updates to the design system.
Improve usability by coherently addressing the UI elements like colors, layout, spacing, text styles, etc.
Facelift needs to be well-tested both in the design phase and after the implementation as it affects many places in the product. When performed recklessly, it may lead to unexpected outcomes and, in consequence, be detrimental to the overall experience.
This initiative includes systemic UI changes (similar to a facelift) combined with UX adjustments for the key product areas and flows. Refresh addresses Visual and UX Design Debt.
The UX and Visual Debt are interconnected — fixing them separately would lead to further inconsistencies and issues with releasing the changes.
Rolling out big UI and UX modifications to the key product areas at the same time creates a lot of room for introducing unintentional or harmful changes. Performing research (both exploratory and usability testing) as well as conducting detailed Design QA can help mitigate the risks. If possible, releasing improvements in multiple stages is worth considering.
Re-creating a product or making significant modifications to its core concepts. During the redesign, teams usually decide to implement foundational changes to solve major UX problems or shift to a new direction. Redesign pays off not only UX and Visual Debt but, in many cases, also Conceptual Debt.
The difference between a refresh and a redesign is that a redesign implies an overall paradigm shift, whereas a refresh introduces improvements only to certain product areas.
There is a strong business case for the redesign — the company is looking to make a foundational change, and this decision is supported by research and hard evidence.
Design debt shouldn’t be the only reason for a redesign, especially if there already is a product-market fit. Redesign may bring an unnecessary risk and move the company further away from its goals.
Fix foundational issues, introduce new UX concepts or support a big paradigm change (incorporate new personas, flows, and functionalities) in order to prepare a product for its next stage of development or support a pivot.
The redesign is a strategy that sometimes gets overused when paying off Design Debt. I would like to emphasize that redesign is a major commitment that brings a lot of risks and that paying off Design Debt shouldn’t be its only goal.
When considering a redesign, we should always first learn whether lower-scope alternatives can bring the desired results.
Having a clear vision for the future and an awareness of what is not working currently is key. Without an understanding of the direction in which we want to lead the company, it’s hard to evaluate a need for redesign.
Redesign is not a substitute for a product vision. It may be a tool that brings this vision to life.
Before committing to a redesign, establish:
It sounds very basic but, in reality, it’s surprising how many teams don’t know the answers to these questions. When defining the problems, always keep on asking to discover the underlying reasons. For example:
Our app looks outdated — why? — because of colors and busy layouts — how do we know that? — feedback from user testing and missed sales deals — what people are saying? — that the app is not mature and doesn’t provide a high enough level of security — why is it important to solve? — security is one of our customers’ main concerns.
The problem of colors and layouts turned out to be the problem of trust. With this information, it’d be easier to choose the strategy and inform the decisions along the way.
Various stakeholders can have diverse definitions of success for the redesign.
It’s crucial to align goals and expectations across the team before the work starts. Without defining how we expect to affect the key metrics, there is a lot of room for misinterpretations, mismanaged expectations, and in consequence, disappointment.
The rule of thumb is always to choose the smallest effort that can bring progress. Smaller projects seem less impressive than one big initiative, but they usually lead to more sustainable and predictable progress.
It’s important not to ‘ego plan’ and be realistic about what strategy aligns best with the current needs and can be successfully executed.
