Back
A framework to deal with UX Debt from the trenches
Project
Company
Freenow
Year
2024
Role
Director, User Experience
Team
Marian Wagner — Design Lead
Fernanda Marques — Design Lead
Sara Tahir — Product Designer
Corina Aionitoaie — Engineering Manager
The context
Recent product releases exposed a concerning pattern: a significant number of features were failing to meet the high standards our customers have come to expect.
This decline in quality was eroding customer trust, increasing the risk of churn, and directly contradicting our core value of customer devotion.
This problem manifests in two key scenarios:
- MVP Stagnation: Projects initially launched as MVPs often stagnate. They are never fully developed beyond their initial scope, lacking crucial technical support, ongoing refinements, and scalability considerations. This leads to a subpar user experience as the product remains incomplete.
- Maintenance Neglect: Even fully developed features are not immune. Post-release maintenance, technical enhancements, and the prioritisation of existing features are often neglected. This results in a gradual decline in performance and increased technical debt.
The consequences are far-reaching:
- Technical & Design Debt Accumulation: Teams, under pressure, resort to shortcuts, accumulating debt that slows down future development.
- Increased Incident Rate: A lack of maintenance makes our systems more vulnerable to incidents and outages.
- Suboptimal User Experience: Users encounter bugs, incomplete features, and a lack of polish, leading to frustration and dissatisfaction.
- Resource Drain: Engineers spend valuable time firefighting issues instead of focusing on innovation.
- Missed Opportunities: The focus on short-term delivery comes at the expense of long-term strategic initiatives.
This situation became unsustainable. To deliver high-quality products and uphold our core values, we had to put in place a framework to address these issues head-on. I had a good experience working at Adevinta where I was also part of the definition of how the company defined UX Debt and went through the process of implementing it seeing a brutal impact on debt being resolved and increased happiness of designers in my team. If you want to learn more about that impact, check Victor Sola’s substack article where he talks through the entire initiative. I had proof and made the case easier to pitch!
We made sure we made this initiative part of our UX team strategy, under the Product quality pillar and we teamed up with Engineering to establish a framework that was inspired by the Tech Debt framework already in place.
Our definition
Design debt represents all the user-experience issues that accumulate over time when we release features that create friction for the user.
It can be introduced deliberately (e.g., an MVP shortcut) or accidentally (e.g., an unforeseen usability issue).
What isn’t Design Debt?
- Technical bugs: These have a separate resolution process.
- Performance Issues: These are typically categorized under tech debt.
- New Growth Initiatives or Planned Iterations: These are part of the forward-looking backlog, not debt from the past.
5 Categories
01
Visual Design
Brand cohesion, Design system alignment, aesthetics, and the general look and feel of the product UI. Example: Inconsistent modals and old illustration style
02
Interaction Design
How the product works, moves, and reacts to user input. Example: Two different form fields that are meant to be the same and we’re using two different components for the same
03
Content
How the product communicates with the people using it. Example: Vague error messages that don't help the user solve the problem.
04
Information Architecture
The cohesiveness and intuition of navigation and content structure. Example: A disorganized and deep navigation menu that makes it hard for users to find key features.
04
Accessibility
How the product includes elements like color contrast, focus indicators, and text alternatives for all users. Example: Low-contrast text that is difficult for users with visual impairments to read.
Our framework
Step 1: Identify it
- Perform regular user testing (internal and external).
- Conduct a routine heuristic analysis
- Design-debt hunting session
- Analytics
Step 2: Document it
- Optional for Designers: Create a centralised inventory for you to keep track of all the Debt you’re accumulating in your teams’ domain. This will help you keeping track visually of all the different issues identified, and can help you as a tool to share with the PM and EM the different debt issues in your weekly catch-ups.
- Create a new ticket with Issue Type UX-Debt for the Debt you’re accumulating and add the Debt card in the ticket as an attachment.
- Make sure it shows in the JIRA UX Debt board
- Ensure follow-up design tasks are created and linked to the original epic if the MVP does not meet some design requirements that were agreed upon
The Issue type in JIRA is UX-Debt and should contain the following information:
- Description (input field | open text) - Mandatory
- Severity (select | cosmetic, minor, major, unusable) - Mandatory
- Business Impact (select | Minimal: edge case, Low: non-critical flow, Medium: critical flow, High: all users) - Mandatory
- Effort (select | XS, S, M, L, XL) - Optional
- Feedback source (input field | open text) - Optional
- Squad - Mandatory
- Screen - Mandatory
- Supporting material (drag-drop multimedia files) - Optional
Step 3: Prioritising it
Independent Prioritization for Design Debt
- Separate from Engineering Capacity: Design debt should be prioritized by the product team based on its own merit, distinct from the 20% engineering capacity often allocated for tech debt.
- Recommended Collaboration: Product Managers (PMs), Engineering Managers (EMs), and Designers should meet before the Sprint Planning session to pre-determine which debt tickets will be addressed in the upcoming sprint.
Addressing Lower-Priority UX Debt
- Fix High-Priority First: High-priority UX problems should always be addressed first. These are the ones that need to be discussed and potentially brought to Sprint Plannings.
- Don't Abandon Low-Priority: Lower-priority UX issues, while not critical, should not be ignored completely. Over time, these small annoyances accumulate, significantly degrading the user experience and making the product feel lower quality.
Decision-Making Framework: Impact vs. Effort Matrix
- The classic "Impact vs. Effort" matrix is used to decide what to fix.
- Initial Focus: Prioritize debt issues that have a high impact/value and require low effort to resolve.
When assessing the "value" or "impact" (which can be understood as a "severity"), consider two key dimensions:
Criticality of the Journey/Feature:
- Strategic importance of the journey or feature.
- Percentage of users exposed to the issue.
Blocking and Persistence of the Problem:
- Does the problem block user flow?
- How consistently does the problem occur?
Lobbying & pilot test
We wanted to bring the entire organisation aware of the issue and sign-off the initiative so we defined an RFC that we wrote together with Corina and Sara, plus the help of other people in the Design team either actively contributing and writing or just providing feedback to the document in a Design Crit session. We brought that RFC to our Product Leadership meeting where Engineering, Data, Product and Design leadership meet recurrently to discuss strategy and tactical topics like this one, and got to sign-off the initiative. We got questions around priority, capacity allocation and doubts around the categories but overall nothing that kept us from kicking off the pilot test.
The most difficult part was done, now we had to pilot and see the impact it had, so we organised workshops with product squads to take them through the definition, and we made them reach agreements on how they internally organised their debt boards following our suggestions. They also spent a big portion of the time collecting and talking together as a team how to capture debt, agree on the category, business impact and all the relevant axis. It was fun and engaging at the same time. People were bought into it as soon as they tried out the framework themselves. Here you can see Nina from the Design team leading the workshop with her squad. Great pride as a UX Director seeing our team leading our strategic initiatives and making progress and impact with them.
Impact & final remarks
You might be wondering how we measure the impact of resolving UX Debt and which has been the impact so far. Fair. But.
We’ve just started and in a couple of teams we have solved 15 Debt issues in three months in. That’s just the beginning.
We're all about tackling UX debt because, over time, it can really mess with usability and ruin the user experience. By focusing on fixing this debt, we make sure our products are not just functional but also a joy to use. Sure, you might see immediate results in metrics like how many issues we’ve tackled, but the real perks show up in long term customer loyalty and satisfaction over time.
More importantly, the care for quality, and also how AI is now empowering design teams to ship high quality even further, leaves no room to ignore UX debt anymore. Either you ship quality products or the product will not be set for long term success because another competitor will do the same, but better, as simple as that. So metrics are alright, but quality is often opinionated and difficult to measure.
Back
A framework to deal with UX Debt from the trenches
Project
Company
Freenow
Year
2024
Role
Director, User Experience
Team
Marian Wagner — Design Lead
Fernanda Marques — Design Lead
Sara Tahir — Product Designer
Corina Aionitoaie — Engineering Manager
The context
Recent product releases exposed a concerning pattern: a significant number of features were failing to meet the high standards our customers have come to expect.
This decline in quality was eroding customer trust, increasing the risk of churn, and directly contradicting our core value of customer devotion.
This problem manifests in two key scenarios:
- MVP Stagnation: Projects initially launched as MVPs often stagnate. They are never fully developed beyond their initial scope, lacking crucial technical support, ongoing refinements, and scalability considerations. This leads to a subpar user experience as the product remains incomplete.
- Maintenance Neglect: Even fully developed features are not immune. Post-release maintenance, technical enhancements, and the prioritisation of existing features are often neglected. This results in a gradual decline in performance and increased technical debt.
The consequences are far-reaching:
- Technical & Design Debt Accumulation: Teams, under pressure, resort to shortcuts, accumulating debt that slows down future development.
- Increased Incident Rate: A lack of maintenance makes our systems more vulnerable to incidents and outages.
- Suboptimal User Experience: Users encounter bugs, incomplete features, and a lack of polish, leading to frustration and dissatisfaction.
- Resource Drain: Engineers spend valuable time firefighting issues instead of focusing on innovation.
- Missed Opportunities: The focus on short-term delivery comes at the expense of long-term strategic initiatives.
This situation became unsustainable. To deliver high-quality products and uphold our core values, we had to put in place a framework to address these issues head-on. I had a good experience working at Adevinta where I was also part of the definition of how the company defined UX Debt and went through the process of implementing it seeing a brutal impact on debt being resolved and increased happiness of designers in my team. If you want to learn more about that impact, check Victor Sola’s substack article where he talks through the entire initiative. I had proof and made the case easier to pitch!
We made sure we made this initiative part of our UX team strategy, under the Product quality pillar and we teamed up with Engineering to establish a framework that was inspired by the Tech Debt framework already in place.
Our definition
Design debt represents all the user-experience issues that accumulate over time when we release features that create friction for the user. It can be introduced deliberately (e.g., an MVP shortcut) or accidentally (e.g., an unforeseen usability issue).
What isn’t Design Debt?
- Technical bugs: These have a separate resolution process.
- Performance Issues: These are typically categorized under tech debt.
- New Growth Initiatives or Planned Iterations: These are part of the forward-looking backlog, not debt from the past.
5 Categories
01
Visual Design
Brand cohesion, Design system alignment, aesthetics, and the general look and feel of the product UI. Example: Inconsistent modals and old illustration style
02
Interaction Design
How the product works, moves, and reacts to user input. Example: Two different form fields that are meant to be the same and we’re using two different components for the same
03
Content
How the product communicates with the people using it. Example: Vague error messages that don't help the user solve the problem.
04
Information Architecture
The cohesiveness and intuition of navigation and content structure. Example: A disorganized and deep navigation menu that makes it hard for users to find key features.
04
Accessibility
How the product includes elements like color contrast, focus indicators, and text alternatives for all users. Example: Low-contrast text that is difficult for users with visual impairments to read.
Our framework
Step 1: Identify it
- Perform regular user testing (internal and external).
- Conduct a routine heuristic analysis
- Design-debt hunting session
- Analytics
Step 2: Document it
- Optional for Designers: Create a centralised inventory for you to keep track of all the Debt you’re accumulating in your teams’ domain. This will help you keeping track visually of all the different issues identified, and can help you as a tool to share with the PM and EM the different debt issues in your weekly catch-ups.
- Create a new ticket with Issue Type UX-Debt for the Debt you’re accumulating and add the Debt card in the ticket as an attachment.
- Make sure it shows in the JIRA UX Debt board
- Ensure follow-up design tasks are created and linked to the original epic if the MVP does not meet some design requirements that were agreed upon
The Issue type in JIRA is UX-Debt and should contain the following information:
- Description (input field | open text) - Mandatory
- Severity (select | cosmetic, minor, major, unusable) - Mandatory
- Business Impact (select | Minimal: edge case, Low: non-critical flow, Medium: critical flow, High: all users) - Mandatory
- Effort (select | XS, S, M, L, XL) - Optional
- Feedback source (input field | open text) - Optional
- Squad - Mandatory
- Screen - Mandatory
- Supporting material (drag-drop multimedia files) - Optional
Step 3: Prioritising it
Independent Prioritization for Design Debt
- Separate from Engineering Capacity: Design debt should be prioritized by the product team based on its own merit, distinct from the 20% engineering capacity often allocated for tech debt.
- Recommended Collaboration: Product Managers (PMs), Engineering Managers (EMs), and Designers should meet before the Sprint Planning session to pre-determine which debt tickets will be addressed in the upcoming sprint.
Addressing Lower-Priority UX Debt
- Fix High-Priority First: High-priority UX problems should always be addressed first. These are the ones that need to be discussed and potentially brought to Sprint Plannings.
- Don't Abandon Low-Priority: Lower-priority UX issues, while not critical, should not be ignored completely. Over time, these small annoyances accumulate, significantly degrading the user experience and making the product feel lower quality.
Decision-Making Framework: Impact vs. Effort Matrix
- The classic "Impact vs. Effort" matrix is used to decide what to fix.
- Initial Focus: Prioritize debt issues that have a high impact/value and require low effort to resolve.
When assessing the "value" or "impact" (which can be understood as a "severity"), consider two key dimensions:
Criticality of the Journey/Feature:
- Strategic importance of the journey or feature.
- Percentage of users exposed to the issue.
Blocking and Persistence of the Problem:
- Does the problem block user flow?
- How consistently does the problem occur?
Lobbying & pilot test
We wanted to bring the entire organisation aware of the issue and sign-off the initiative so we defined an RFC that we wrote together with Corina and Sara, plus the help of other people in the Design team either actively contributing and writing or just providing feedback to the document in a Design Crit session. We brought that RFC to our Product Leadership meeting where Engineering, Data, Product and Design leadership meet recurrently to discuss strategy and tactical topics like this one, and got to sign-off the initiative. We got questions around priority, capacity allocation and doubts around the categories but overall nothing that kept us from kicking off the pilot test.
The most difficult part was done, now we had to pilot and see the impact it had, so we organised workshops with product squads to take them through the definition, and we made them reach agreements on how they internally organised their debt boards following our suggestions. They also spent a big portion of the time collecting and talking together as a team how to capture debt, agree on the category, business impact and all the relevant axis. It was fun and engaging at the same time. People were bought into it as soon as they tried out the framework themselves. Here you can see Nina from the Design team leading the workshop with her squad. Great pride as a UX Director seeing our team leading our strategic initiatives and making progress and impact with them.
Impact & final remarks
You might be wondering how we measure the impact of resolving UX Debt and which has been the impact so far. Fair. But.
We’ve just started and in a couple of teams we have solved 15 Debt issues in three months in. That’s just the beginning.
We're all about tackling UX debt because, over time, it can really mess with usability and ruin the user experience. By focusing on fixing this debt, we make sure our products are not just functional but also a joy to use. Sure, you might see immediate results in metrics like how many issues we’ve tackled, but the real perks show up in long term customer loyalty and satisfaction over time.
More importantly, the care for quality, and also how AI is now empowering design teams to ship high quality even further, leaves no room to ignore UX debt anymore. Either you ship quality products or the product will not be set for long term success because another competitor will do the same, but better, as simple as that. So metrics are alright, but quality is often opinionated and difficult to measure.
Back
A framework to deal with UX Debt from the trenches
Project
Company
Freenow
Year
2024
Role
Director, User Experience
Team
Marian Wagner — Design Lead
Fernanda Marques — Design Lead
Sara Tahir — Product Designer
Corina Aionitoaie — Engineering Manager
The context
Recent product releases exposed a concerning pattern: a significant number of features were failing to meet the high standards our customers have come to expect.
This decline in quality was eroding customer trust, increasing the risk of churn, and directly contradicting our core value of customer devotion.
This problem manifests in two key scenarios:
- MVP Stagnation: Projects initially launched as MVPs often stagnate. They are never fully developed beyond their initial scope, lacking crucial technical support, ongoing refinements, and scalability considerations. This leads to a subpar user experience as the product remains incomplete.
- Maintenance Neglect: Even fully developed features are not immune. Post-release maintenance, technical enhancements, and the prioritisation of existing features are often neglected. This results in a gradual decline in performance and increased technical debt.
The consequences are far-reaching:
- Technical & Design Debt Accumulation: Teams, under pressure, resort to shortcuts, accumulating debt that slows down future development.
- Increased Incident Rate: A lack of maintenance makes our systems more vulnerable to incidents and outages.
- Suboptimal User Experience: Users encounter bugs, incomplete features, and a lack of polish, leading to frustration and dissatisfaction.
- Resource Drain: Engineers spend valuable time firefighting issues instead of focusing on innovation.
- Missed Opportunities: The focus on short-term delivery comes at the expense of long-term strategic initiatives.
This situation became unsustainable. To deliver high-quality products and uphold our core values, we had to put in place a framework to address these issues head-on. I had a good experience working at Adevinta where I was also part of the definition of how the company defined UX Debt and went through the process of implementing it seeing a brutal impact on debt being resolved and increased happiness of designers in my team. If you want to learn more about that impact, check Victor Sola’s substack article where he talks through the entire initiative. I had proof and made the case easier to pitch!
We made sure we made this initiative part of our UX team strategy, under the Product quality pillar and we teamed up with Engineering to establish a framework that was inspired by the Tech Debt framework already in place.
Our definition
Design debt represents all the user-experience issues that accumulate over time when we release features that create friction for the user. It can be introduced deliberately (e.g., an MVP shortcut) or accidentally (e.g., an unforeseen usability issue).
What isn’t Design Debt?
- Technical bugs: These have a separate resolution process.
- Performance Issues: These are typically categorized under tech debt.
- New Growth Initiatives or Planned Iterations: These are part of the forward-looking backlog, not debt from the past.
5 Categories
01
Visual Design
Brand cohesion, Design system alignment, aesthetics, and the general look and feel of the product UI. Example: Inconsistent modals and old illustration style
02
Interaction Design
How the product works, moves, and reacts to user input. Example: Two different form fields that are meant to be the same and we’re using two different components for the same
03
Content
How the product communicates with the people using it. Example: Vague error messages that don't help the user solve the problem.
04
Information Architecture
The cohesiveness and intuition of navigation and content structure. Example: A disorganized and deep navigation menu that makes it hard for users to find key features.
04
Accessibility
How the product includes elements like color contrast, focus indicators, and text alternatives for all users. Example: Low-contrast text that is difficult for users with visual impairments to read.
Our framework
Step 1: Identify it
- Perform regular user testing (internal and external).
- Conduct a routine heuristic analysis
- Design-debt hunting session
- Analytics
Step 2: Document it
- Optional for Designers: Create a centralised inventory for you to keep track of all the Debt you’re accumulating in your teams’ domain. This will help you keeping track visually of all the different issues identified, and can help you as a tool to share with the PM and EM the different debt issues in your weekly catch-ups.
- Create a new ticket with Issue Type UX-Debt for the Debt you’re accumulating and add the Debt card in the ticket as an attachment.
- Make sure it shows in the JIRA UX Debt board
- Ensure follow-up design tasks are created and linked to the original epic if the MVP does not meet some design requirements that were agreed upon
The Issue type in JIRA is UX-Debt and should contain the following information:
- Description (input field | open text) - Mandatory
- Severity (select | cosmetic, minor, major, unusable) - Mandatory
- Business Impact (select | Minimal: edge case, Low: non-critical flow, Medium: critical flow, High: all users) - Mandatory
- Effort (select | XS, S, M, L, XL) - Optional
- Feedback source (input field | open text) - Optional
- Squad - Mandatory
- Screen - Mandatory
- Supporting material (drag-drop multimedia files) - Optional
Step 3: Prioritising it
Independent Prioritization for Design Debt
- Separate from Engineering Capacity: Design debt should be prioritized by the product team based on its own merit, distinct from the 20% engineering capacity often allocated for tech debt.
- Recommended Collaboration: Product Managers (PMs), Engineering Managers (EMs), and Designers should meet before the Sprint Planning session to pre-determine which debt tickets will be addressed in the upcoming sprint.
Addressing Lower-Priority UX Debt
- Fix High-Priority First: High-priority UX problems should always be addressed first. These are the ones that need to be discussed and potentially brought to Sprint Plannings.
- Don't Abandon Low-Priority: Lower-priority UX issues, while not critical, should not be ignored completely. Over time, these small annoyances accumulate, significantly degrading the user experience and making the product feel lower quality.
Decision-Making Framework: Impact vs. Effort Matrix
- The classic "Impact vs. Effort" matrix is used to decide what to fix.
- Initial Focus: Prioritize debt issues that have a high impact/value and require low effort to resolve.
When assessing the "value" or "impact" (which can be understood as a "severity"), consider two key dimensions:
Criticality of the Journey/Feature:
- Strategic importance of the journey or feature.
- Percentage of users exposed to the issue.
Blocking and Persistence of the Problem:
- Does the problem block user flow?
- How consistently does the problem occur?
Lobbying & pilot test
We wanted to bring the entire organisation aware of the issue and sign-off the initiative so we defined an RFC that we wrote together with Corina and Sara, plus the help of other people in the Design team either actively contributing and writing or just providing feedback to the document in a Design Crit session. We brought that RFC to our Product Leadership meeting where Engineering, Data, Product and Design leadership meet recurrently to discuss strategy and tactical topics like this one, and got to sign-off the initiative. We got questions around priority, capacity allocation and doubts around the categories but overall nothing that kept us from kicking off the pilot test.
The most difficult part was done, now we had to pilot and see the impact it had, so we organised workshops with product squads to take them through the definition, and we made them reach agreements on how they internally organised their debt boards following our suggestions. They also spent a big portion of the time collecting and talking together as a team how to capture debt, agree on the category, business impact and all the relevant axis. It was fun and engaging at the same time. People were bought into it as soon as they tried out the framework themselves. Here you can see Nina from the Design team leading the workshop with her squad. Great pride as a UX Director seeing our team leading our strategic initiatives and making progress and impact with them.
Impact & final remarks
You might be wondering how we measure the impact of resolving UX Debt and which has been the impact so far. Fair. But.
We’ve just started and in a couple of teams we have solved 15 Debt issues in three months in. That’s just the beginning.
We're all about tackling UX debt because, over time, it can really mess with usability and ruin the user experience. By focusing on fixing this debt, we make sure our products are not just functional but also a joy to use. Sure, you might see immediate results in metrics like how many issues we’ve tackled, but the real perks show up in long term customer loyalty and satisfaction over time.
More importantly, the care for quality, and also how AI is now empowering design teams to ship high quality even further, leaves no room to ignore UX debt anymore. Either you ship quality products or the product will not be set for long term success because another competitor will do the same, but better, as simple as that. So metrics are alright, but quality is often opinionated and difficult to measure.