Previously posted on https://blog.squadlytics.com/we-need-to-talk-about-experience-debt
Do you remember the frustration felt when, during a demo, stakeholders would point out all the imperfections in the UI while ignoring the hard work you've done? Do they not know the sacrifices you had to do to get there?
[Narrator's voice]: "No, they don't."
Technical debt is something that naturally occurs during software development. Things get more complicated, product managers change scope, people get sick... There are many reasons why all of a sudden you can't do all the things you planned, and we end up putting a bunch of tickets back on the bench at the end of a sprint. There are ways to manage technical debt, but it is bound to happen no matter how hard you try to prevent it.
But, here's the thing. Even if you don't like it, you can quantify it. Because you can see that pile of stories and tasks in your backlog slowing growing into a creepy monster. These are all the features, improvements and refactors that are side-eyeing you every time you're planning the next iteration, trying to cause you enough guilt for you to drag them in the Todo column. You ignore them, try to shove them down the backlog - out of sight, out of mind - but inevitably you'll have to face them.
Experience debt, the invisible beast
Now, let's consider what happens when a feature is implemented. But we cut corners on how it feels like for the user. The image on top of this post is an example of that. It's what you see when you're loading Squadlytics in your browser.
It is a loading screen, and it sucks. But when we were building the app, we had to downsize the scope of some things to meet the deadline. So we ended up with what you see above because:
- This is seen only once on the first load of the progressive web app.
- Having the rest of the product working fine was more critical.
- Technically, it's correct.
So we completed the tasks, and closed the story.
And here is the difference between technical debt and experience debt. Technical debt is highly visible to us because it's all the tickets that we did not close. It usually does not require extra work to be surfaced as it's already in the issue tracker. But when it comes down to the user experience, we need to make the extra effort of capturing it somewhere to make it visible to the team. And this is paradoxical because customers won't ignore it, they will tell you right away.
We see technical debt in our backlogs. Our users see experience debt in our products.
A way forward
I don't have a magic bullet to solve that problem. I've seen teams empowering designers to raise UX issues as bugs. I've seen sprints focused on fixing interactions in the product, the design, iconography. I've seen companies organizing periodic reviews of the onboarding experience.
What I know though is that the people using your product will not ignore experience debt, and we need to do the extra step of capturing it so that it can be more visible to us.
Please share in the comments how your team is tackling this problem. And in the meantime, I'm going to create a ticket to fix our loading screen.
Top comments (2)
I've never heard the term experience debt but it perfectly describes the issues with one of my apps at work. Going to include this concept in my replatforming/rewrite proposal
This is a term I made up, but I'm sure it's used in some places. The fact that we don't have a good way to classify UX debt is a problem in this day where even B2B mammoths have to offer a great experience to compete. We think a lot about managing technical debt but UX gets pushed back most of the time.