UX Debt in SaaS – The Band-Aid You Need to Mitigate It Without Coding

We’re not going to pretend here you can prevent UX debt. Let’s face it: UX debt, just like technical debt, is unavoidable.

Especially if your SaaS company originated as (or still is!) a high-growth bootstrapped startup – you will know the pain of not always being *able* to make the best design decisions.

Talking about UX debt, under such circumstances, may feel a lot like this:

Yazan Sehwail UX debt quote userpilot

“When your city is getting bombed and someone comes over and tells you you have an ugly bathroom”

Yazan Sehwail, Co-founder and CEO of Userpilot

Sometimes accruing UX debt is the only way to go: when time-to-market is of the essence, you have to launch quickly with limited resources to stay competitive:

competing on features UX debt

“We are not here to craft the perfect UX, but survive in the SaaS space first.”

Andy Shamah, Head of Product at Userpilot

But as with any debt – accruing too much can lead to ugly consequences: the most obvious of which in the case of UX debt is higher churn.

We know giving you run-of-the-mill solutions like ‘keep UX debt/design log and refactor your designs regularly’ isn’t really practical or helpful.

You know what you should be doing in the perfect world, but hey! The world is not perfect and there’s no point in jinxing the reality.

So in this post, we’re going to address the issue in the most practical of ways – and show you how you can mitigate the consequences of UX debt in a quick and easy way, without using your dev resources.

Let’s dive in!


In a hurry? Here are the key takeaways from this post:

  • UX debt is the consequences of making design decisions that help you gain an advantage in the short-term but may result in long-term consequences.
  • For example, not running user tests may help launch more features faster, but result in UX issues and lower customer satisfaction later.
  • UX debt affects high-growth SaaS companies in industries where time-to-market is mission-critical and bootstrapped startups without a design team most.
  • UX debt is not completely avoidable, there are quick-fixes you can apply to mitigate its consequences though.
  • The most common consequences of UX debt include grave UX issues, higher support costs, lower customer satisfaction, and higher churn.
  • Short-term UX debt patches can involve native tooltips and interactive walkthroughs.
  • Use in-app experiences to guide the users through the less intuitive aspects of your UI.
  • Code-free workarounds can 2x your feature adoption despite bad UX.

What is UX debt?

Akin to technical debt, UX debt is the cost of making design decisions that produce results faster short-term, but may have negative consequences long term. These may include poor user experience, higher support costs, lower user satisfaction, and resultant churn, inability to launch new features as well as the need for major redesigns later on.

UX debt occurs as a result of e.g. skipping user testing or ignoring the style guides.

Sometimes, you do it on purpose to release more new features faster:

“I’ve worked on too many projects where ignoring style guides to get a product release in 2 weeks versus 6 months is always more important.”

(A startup founder who wished to remain anonymous)

UX debt increases Software Entropy – as your design becomes more and more complex and difficult to maintain as you tweak and build upon it over time.

It happens more (just like tech debt) in agile environments, where the pressure to meet release deadlines forces you to opt for time-saving design alternatives.

Why does UX debt happen? Reasons for UX debt

First of all, let’s acknowledge this simple fact of life:

Yazan Sehwail software quote

“Building software is simple. Building simple software is difficult.”

Yazan Sehwail, CEO of Userpilot

And the more complex your product, the more use cases you cater to, and the more workflows you have – the harder it will be to connect all the dots and make everything intuitive, smooth, and glitch-free.

Then again – just like with evolving cities – the immediate needs will take priority over meticulous planning.

Sometimes, you don’t even see the impact of some decision 20 steps down the road. Often, moving fast and breaking things is the only way to keep afloat.

As time goes by, and the pressure to launch new features grows, you will be inevitably falling behind with fixing the “old” issues.

Here are, in a nutshell, the most common reasons for UX debt:

  • In startups – since startups often don’t have a dedicated designer from the start, other employees have to wear the hat of the designer and take their responsibilities regardless of whether they have the right qualifications, and while having a lot of other stuff to do.
  • As a result, startups have to take massive shortcuts in the design process.
  • In companies that do have dedicated designers, UX debt occurs as a result of skipping usability testing, not having clear requirements from the product team, poor QA quality, or simply the designer not having the right skills.

Is it possible to avoid UX debt in SaaS?

Short answer – no.

Andy Shamah UX debt quote userpilot

“I don’t think it is possible if you want to go fast and break things, but it is possible to minimize the damage if one of the founders or early employees have a good background in design.”

Andy Shamah, Head of Product at Userpiot

Besides, in a lot of companies UX debt is a controlled management concept. As long as it’s still “controlled”, of course.

What happens if it isn’t?

What is the cost of UX debt?

As with any debt – you need to pay the “interest”. In this case – for buying yourself extra time with design shortcuts one day.

The interest of UX debt comes in many forms: ranging from higher support costs and churn, to future design bottlenecks that may require a lot more work than if the workflow was designed right from scratch.

So – before making any decisions that will result in UX debt – think carefully if the advantages of making these shortcuts outweigh the potential future disadvantages.

UX debt is expensive to fix

Fixing UX problems tends to be trickier and costlier than just getting the product launch right the first time off.

Think about it.

Let’s take an example or an average large European city. The city centre is full of narrow streets that were designed for horse carriages back in the day. Most of them will be one way streets. This makes city centers of old European cities an absolute nightmare to drive.

If you were to redesign a city center of an existing city, it would be a huge and expensive operation. Moving the existing tenants (and handling all their opposition), tearing down historical buildings, removing all the rubble…that’s why it’s almost never done (unless war or a natural disaster necessitates it). And you need to work with what you have.

If you were to build a new city from scratch though – it would be a completely different story. Sky would be the limit. You could build the next feat of urban architecture.

Same with software. Starting from a blank page is much easier than changing an already shipped code. You don’t need to familiarize yourself with the old code, spend time debugging or retrofitting other parts of the software.

In general – the more code, and the lower its quality – the slower and more expensive both the work and maintenance get.

But it can get even worse…

Too much UX debt can kill you

Andrew Wilkinson of Flow, a project management app, learned it the hard way. At first, he was smug about Asana and its complicated UX and ugly UI, but as soon it got over its UX debt, the veiled threat of crushing Flow actually materialized:

Andrew Wilkinson ux debt thread
Source: https://twitter.com/awilkinson/status/1376985854229504007?

Great design nowadays became a must not a luxury.

Prospects actually buy products for their design, sometimes even if they lack certain features that the competitor has.

So – another consequence of UX debt is that you could be crushed by your competitors.

It can lead to critical mistakes

Last but not least – if your UX is misleading, it can lead your users to make fatal mistakes (i.e. deleting their data or removing certain content or showing content to wrong users, etc.).

This would of course likely lead them to rage quit your product and ask for a refund.

And yes, spread the news that your tool sucks.

The most common UX sins

What are the most common UX mishaps in SaaS then? Let’s look at a few.

UX debt sins against user testing

As already mentioned, startups often have very limited resources and have to “make do” with the people they have. As a result, their design process is far from ideal.

The healthy process for design would include:

Research => Wireframing => Mockups => Prototyping => Initial usability testing => UX => UI => Copy writing => Final usability testing => Ready for development.

Meanwhile, in startups, the reality is that the design process skips quite a lot of stages and includes just a few:

Wireframing => UX & UI => Ready for dev.

Obviously, skipping half of the steps in the design process results in lower quality output.

UX debt sins against the brand

Outsourcing is often the way to go for early-stage startups, but without proper systems, documentation, and brand books – it can go terribly wrong.

If one of the tabs in the app you’re using looks slightly different than the rest, or one workflow is particularly counter-intuitive compared to the rest – it may be a sign of a UX sin against the brand.

UX debt sins against the vision

Competing on features, rushing into ‘following trends’ can easily result in UX debt too.

A “me too” mindset without a clear vision on whom you’re serving and why may lead to an unnecessary “feature creep”.

Also, implementing user feedback without paying attention to your vision may mean you end up adding features that slow your app down and clutter your dashboards without adding major value for most of your users.

Another sin against vision involves building features for the 1% of your power users, and ignoring the 99% – watch this short video by Moe Ali of Product Faculty to learn more about it.

How to measure UX debt?

Similar to technical debt, you can measure UX debt ratio as the Cost of Remediation divided by Development Cost x 100%.

This means you basically calculate how much the redesign will cost you compared to designing the feature/workflow from scratch.

UX debt ratio

If your score is higher than 1 (or 100%) it means it would cost you more to redesign than to build it from scratch. Obviously, no one wants that 😱

Now that you what what UX debt is, how to calculate it and where it comes from – let’s see how to offset it (we’ll look at both short term, and more long term solutions.)

How to deal with UX debt?

Obviously, you don’t want to hear advice that you can’t possibly implement. We all know we should be adhering to design principles in the perfect world. But in the real world – where you need to move fast and break things – you want that band-aid that will stop your SaaS from bleeding customers as a result of the UX debt. Here’s what you can do (with real examples).

Short-term solutions

Having good customer support and success teams would cover for it. But the potential threat here is that you can reach a point where your support/success team becomes larger than your product team.

You can also offset UX debt short-term with minimum engineering effort by being reactive and enhancing the UX bit by bit according to QA reports, or customers complaints. Prioritize fixing what is most painful to the users.

Alternatively – some things can be fixed with zero engineering involvement – let’s look at a few examples.

How to mitigate UX debt without coding with native tooltips – with examples

Native tooltips are the tiny “?”s or “i”s appended to the less obvious elements of your UI.

NPS native tooltip userpilot
Source: Userpilot. Want to build native tooltips like that without coding? Reach out to us!

They can be used to explain and draw attention to features that may be underused because of the way they have been labeled or where they were placed.

We have used it e.g. to explain our “Features” feature…which as you can imagine, may have raised a few eyebrows…(P.S. It’s used for “feature tagging” – so you can tag a feature on your UI and measure its usage without passing custom events in Userpilot.)

feature tagging in Userpilot

How to mitigate UX debt without coding with interactive walkthroughs – with examples

The above example is very simple of course and may not help with more complex UX debt issues. There’s another workaround for that though: interactive walkthroughs.

Let’s look at an example. Postfity, a social media scheduler, had a few important features that were pretty much “hidden” from sight as a result of poor design decisions.

These included features like “post recycling” or “calendar view”. It wasn’t until Postfity analyzed its churn surveys that they realized they had a problem…

…some users were churning, because they haven’t discovered the key features that were hidden by poor design!

While waiting on the devs to finish their sprint before a major redesign could be debated, Postfity’s PMM – Anna – applied a quick fix:

First, she created a slideout that pushed the users to discover the hidden feature in a step by step interactive walkthrough:

hidden feature slideout

After clicking on the ‘show me how’ button, the user was taken to the page in the app where the feature was ‘hidden’:

page change userpilot

Then, they saw a tooltip pointing them to the feature they were missing:

tooltip reuse feature ux debt userpilot

This led to almost doubling the adoption rate of this feature (Anna run an A/B test using Userpilot to find out if the walkthrough had an impact):

Reuse feature AB test results userpilot

Of course, the ideal solution would be to fix the UX issue…but since we don’t live in the ideal world, we sometimes need to resort to workarounds like that. And they seem to be working. Proof’s in the pudding.

road workaround

Long-term UX debt solutions

If you want to minimize UX debt in the long term – focus on building a culture of ownership.

Get all the people in the company to own what they do.

As Arun Raj, Head of Design at Rocketlane told us:

“We don’t fix these UI debts often. We believe that we have set a culture that Engineers should own the features too. They should care. Some people find and fix things on their own and commit the code. It worked for us.”

For the same reason – outsource to third-party companies and freelancers only when you absolutely have to.

And of course – invest in building clear design processes and great design teams.

previous post next post

Leave a comment