Paying design debt
How to decide which Design Debt to fix and incorporate it into the roadmap without causing friction.
If your team has already built a common understanding of the Design Debt types, its state, and its impact on the product; the next step is to set up a plan and pay off the excess Design Debt.
The ultimate goal is to create a sustainable strategy for incorporating Design-Debt-related items in teams’ roadmaps to minimize friction and ensure efficiency. The whole process can be divided into the following steps:
- Step 1: Analyse & List
- Step 2: Prioritise & Plan
- Step 3: Pay off & Track progress
Step 1: Analyse & list
The first stage of the process is about auditing your product and processes to spot the Design Debt and gain an understanding of its scale and impact.
Design Debt vs. poorly designed experiences
Correctly recognizing what classifies as Design Debt and what is just a poorly designed experience is key. When focusing on Design Debt, many teams tend to over-recognize it and unnecessarily associate it with too many issues.
According to its definition, Design Debt is built over time by adding multiple layers of changes. It results in introducing, often unintentional, imperfections in experiences and processes. Design Debt is a consequence of innovation, iterating, and growth.
You can think about accumulating Design Debt as adding layers on top of each other over a period of time. They are somewhat similar and, from far, seem to create an acceptable level of harmony. However, when looking carefully, the misalignment and big gaps became visible.
Auditing your product and processes
Work with your team to find out how your product and processes are affected by Design Debt.
- Start with every designer auditing their respective area. Even at this stage, I encourage keeping the whole product in mind and looking for similarities with other spots.
- To identify operational Design Debt, designers should work with their teams to gather feedback about the major good and bad aspects of collaborating with the Design Team. In addition, an assessment of internal Design Team processes is needed as well.
- To finalize the audit, come together as a Design Team to review the audit, calibrate the sizing and discuss the cross-feature issues.
You can start by using a simple spreadsheet containing the following fields for every issue: title, description, size, product area, dependencies (on other teams and features), impact, and urgency.
After analysing all the issues with your team, move away from the spreadsheet and create an official space to keep track of all the Design Debt issues.
I recommend forming a separate backlog (or a separate column within the existing Design Team backlog) for Design Debt issues in addition to gathering them to individual teams’ backlogs. The goal is to analyze Design Debt issues as a whole if needed. In addition, consider labeling them as ‘design-debt’ and with the type of Design Debt (UX, visual and operational) for clarity.
In this phase, the goal is to get to the root of the issue. Always try to think broader and deeper about the cause to avoid fixing the surface-level problem. When in doubt, you can perform usability testing and other types of research to determine the underlying causes.
Size and scope
When auditing Design Debt, your team will encounter all sizes of issues: from small color updates to the whole flows that need redesign. There is no absolute measure for Design Debt — neither for principal, nor interest. The best way I found for estimating Design Debt issues is t-shirt sizing — from S to XL:
- S — small straightforward modifications to existing functionality, no research required.
- M — medium-sized projects that usually involve 1–2 teams (or more teams in a very small capacity) that may require simple research; they leverage an existing functionality or flow.
- L — large initiatives that require cross-team collaboration and research; major changes in flow or functionality are needed.
- XL — extra large cross-team cross-functional strategic projects that require major architectural changes, broad ideation, and complex research. Potentially a redesign of the whole product or its major areas.
The estimation should take into consideration the effort needed (both design and research) and the breadth of areas impacted by the change. The t-shirt sizing applies to estimating operational Design Debt as well. Instead of thinking about the product, consider how the process affects the team and how it engages different levels and functions in the organization.
Step 2: Prioritise & Plan
The second stage is about determining which issues are worth addressing and incorporating them into the teams’ roadmaps.
The impact-effort matrix
The main goal is to identify high-impact items (quadrants I and II) — those that significantly contribute to improving key areas of the product (or key processes), unblock teams to deliver on planned features faster or prevent Design Debt from growing exponentially and blocking teams in the nearest future. Analyzing the impact of the issue is connected to both design and product strategy and should be done within the triad (PM, EM & PD).
- quadrant I: high-impact — high-effort (requires working with the PM and the EM to incorporate in the roadmap as a separate project)
- quadrant II: high-impact — low-effort (could be addressed within the scope of already planned projects or as a small issue easily incorporated into the iteration)
- quadrant III: low-impact — low-effort (check if it could be combined with other items to create more impact)
- quadrant IV: low-impact — high-effort (do not fix)
Related read: Dani Nording proposes an alternative classification: quick win, UX optimization, and redesign.
The client impact matrix
You can use this as an alternative or complementary method. It’s an approach used usually for prioritizing product work but it can give an additional understanding of Design Debt issues. The objective is to find the most impactful project: things that customers ask about frequently, are currently dissatisfied with, and that would solve their major pain.
I recommend ‘The Lean Product Playbook’ for more information about this method of prioritizing.
The urgency defines the relationship between the Design Debt issue and the planned development. It helps understand the possible negative consequences and mitigate the risk.
- Low — no impact on the current roadmap. The issue can be tackled at a convenient time.
- Medium — moderated impact on the planned work. Consider taking care of the issue in the nearest future or together with associated development.
- High — work on the roadmap is highly affected. Fix the issue as soon as possible. Not resolving the problem may negatively impact planned work or cause exponentially accumulating Design Debt.
An issue is the first step in the process of paying off the Design Debt. It needs to describe the problem clearly and help decision-makers incorporate it into the roadmap. I recommend using the template (feel free to copy mine) that includes the following sections:
- required: description, size, product area(s), dependencies, impact, and urgency.
- optional: proposed solution, process, and timeline — that’s great if you can offer a starting point for solving the problem or set up a plan for your team at this point.
Here’s an example UX Design Debt issue that shows how to apply the template in practice.
Deciding which issues to fix
Selecting Design Debt issues to work on is a complex process with many factors that need to be taken into consideration. Generally, the rule of thumb is to fix the Design Debt when:
- the cost of paying off < the cost of maintaining the Debt — the cost of maintaining can be understood as longer development time of new features, the Support Team’s time, etc.
- fixing it now opens new opportunities in the future — developing desirable capabilities wouldn’t be possible otherwise.
In the ideal scenario, we would see the following timelines that clearly show the time saved by fixing Design Debt in the long term:
The final decision comes down to what is more beneficial: maintaining the Debt and continuing with new development or paying off the Debt now and waiting longer for new work. It’s important not to operate in a vacuum: analysis needs to be done from the design and product standpoint as well as from the engineering perspective. Some issues are dependent on existing technical debt or are challenging to fix technically and it’s crucial to consult your engineering partners.
The opportunity cost
Fixing Design Debt always competes for resources with the ongoing product work. We tend to understand the opportunity cost only as missing out on potential benefits (like closed deals or introducing new features and making customers happy) because of choosing to fix the debt at a given time. It’s important to remember that there is an opposite side to this coin as well:
The opportunity cost is not only what we miss out on when paying off Design Debt (like undelivered or late features). It is also what we would experience as a consequence of not paying off the Debt: longer delivery, poor experiences and missed chances.
Incorporating design debt in the roadmap
Paying off Design Debt needs to become an ongoing conversation between business, design, and engineering as much as technical debt is currently.
- short-term planning: identify issues that could be addressed together with the items that are currently on the roadmap. Define how fixing the Design Debt relates to the team and company goals (or OKRs).
- long-term planning: identify big cross-team Design Debt initiatives before planning for the next quarter, and signalize them to PMs and EMs. Consciously choose efforts that impact the goals (OKRs). For the Debt introduced purposefully so far, consider setting the time to fix it. Incorporate smaller Design Debt issues into bigger projects when planning for the next quarter.
Step 3: Pay off & Track progress
To keep an eye on the progress, during the quarter:
- Talk about the progress made on Design Debt issues regularly during Design Team syncs in order to spot any problems early on;
- Regularly update the issues on your Design Debt board.
At the end of each quarter:
- Track the number of design debt issues fixed per team — to make sure engineering and product teams are on board with this effort and weight is spread reasonably;
- Summarise the progress first within your respective teams and then together as Design Team.
Celebrate wins publicly within your company in order to emphasize the impact of fixing Design Debt. It facilitates the culture change towards a more conscious approach and sets the stage for getting buy-in for future initiatives.
- Share insights from the customers who were impacted by fixing the Design Debt — messages and recordings are a powerful tool to communicate the direct feedback.
- Show how paying off Design Debt unblocked items on the roadmap or helped delivered them faster — you can even go as far as demonstrating the timeline comparison with and without paying off Design Debt.
Definition of success
There are 3 categories of impact we’re usually looking to make when starting the initiative of paying off the Design Debt:
- Internal adoption: Design Debt issues are included in the ongoing planning for this and future quarters;
- Impact on the product: paying off Design Debt positively impacts the consistency and UX of key flows — based on feedback from customers and testing as well as observations of Design Team members (spotting fewer cases of inconsistent design);
- Impact on the team: visible improvements regarding the pace of work, internal operations, and speed of design delivery. Progress in collaboration between designers and other disciplines based on feedback from different teams.
Please note that those are general areas of impact for the whole Design Debt initiative. Every smaller issue incorporated in the plans should have specific metrics that are defined and tracked separately by respective teams.
Not covered in this article
- The challenge of getting the buy-in: I will talk about how to convince your team and all the stakeholders to work on Design Debt in a separate story. It’s a topic that needs a lot of space on its own.
- A redesign as a way of paying off Design Debt: I recognize that a redesign of the product can be a valid way to pay off big chunks of Design Debt. As it is a broad topic as well, I will discuss it in a separate piece.