By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
by Outdraw Design
Notify me!
About the authorOutdraw Design
Facelift, Refresh, Redesign

Facelift, Refresh, Redesign — strategies for paying off Design Debt

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.

4 strategies

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:

  • Project(s) — the most straightforward approach based on planning and executing a project or multiple independent projects whose only goal is to reduce the amount of Design Debt;
  • Facelift — an initiative focused mainly on globally changing or correcting the UI;
  • Refresh — includes systemic UI changes together with UX adjustments for the key product areas;
  • Redesign — a large effort that changes foundational concepts, flows, and overall experience.

*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.

1. Project(s)


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.

When to choose

  • Using this method should be a default choice. Unless there are clear reasons to plan for a bigger effort (facelift, refresh or redesign), teams should execute independent Design-Debt-focused projects.
  • Projects can also be used in combination with a facelift, refresh or redesign to address Design Debt issues that are not interconnected and can be delivered separately.


The main goal of this initiative is to reduce the amount of Design Debt in the product and team’s processes.


  • Executing separate projects require coordination between the teams. This brings the risk of creating inconsistent work and encountering communication issues.
  • Paying off Design Debt using individual projects can be a long effort, and it needs to be prioritized carefully and advocated for. Otherwise, the focus may quickly shift from Design Debt to the ongoing product work, leaving Design Debt problems only partially solved.

2. Facelift


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.

Choose when…

  • The interface has a lot of visual flaws that need to be addressed all at once to ensure consistency and best results;
  • There is a significant amount of Visual Debt in the design system or components library;
  • UX and Operational Debt are independent enough from the Visual issues and can be handled separately.


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.


3. Refresh


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.

Choose when…

The UX and Visual Debt are interconnected — fixing them separately would lead to further inconsistencies and issues with releasing the changes.


  • Bettering the user experience by refactoring problematic areas of the product — fixing a broken user interface without changing the core functionality;
  • Improving usability by coherently changing the UI elements like colors, layout, spacing, text styles, etc.


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.

Post-it note: note to self-throw it all away

4. Redesign


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.

Choose (only!) when…

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.


  • Not finishing the redesign — running out of resources, a change of priorities, or overcommitting can put the project at risk of leaving it half-done and ending up with more problems and Design Debt then initially.
  • Focusing on the wrong thing — using resources for the redesign at the expense of the ongoing product development needs to be supported by strong evidence. Teams need to be certain that redesign is the most valuable thing they could be doing.
  • Disappointing the stakeholders — redesign may impact a company differently than some individuals anticipate. Having a clear vision and alignment on objectives should mitigate the risk of overpromising and underdelivering.
  • Angering the users — it’s a known phenomenon that users, at first, react poorly to a new solution and then gradually build appreciation for it. If users remain unhappy, the redesign fails, and a company may end up losing existing customers or having to revoke the changes (like Snapchat in 2018).
To redesign or not to redesign

To redesign or not to redesign?

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.

Know your ‘why’

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.

Define the problems

Before committing to a redesign, establish:

  • what problems you’re trying to solve
  • what user needs you’re trying to meet
  • what business requirements you’re trying to fulfill

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.

Align the expectations

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.

Bias toward the smaller scope

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.

Get notified

Sign up to get notified about updates and new articles!

Thank you for joining us!

We will keep you posted about Design Debt 101
Oops! Something went wrong while submitting the form.
Refresh the page and try again.