The myth of the decay of the user experience

﷽

When I started writing this article, I thought I’d be a pioneer. Until I searched for it and found lots of articles covering this topic. Which showed me how important that topic is on the one hand, and that it humbled me on the other.

We all have been in this. Exciting times. We start working on a new product. We do just enough research to get some insights, we want to be fast throw MVPs into the wild, and get real feedback as early and often as possible. Based on our first learnings we eagerly start building the first flows, deeply thought throw and beautifully crafted. Exiciting times. And as our products grow, features are added, new edge cases appear, and our teams expand, things start getting messy. Inconsistencies appear, user journeys feel broken, we lose users. The experience of our new baby drifts apart.

Our colleagues from engineering

There is good news: We are not alone. From our engineering colleagues, we know that they have the same problems. The term which is used, is called Technical debt. It is a concept in software development by Ward Cunningham in 1992 that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. He compares this code debt to financial debt. In this 5 minute video Ward describes the debt metaphor in his own words.

The reasons when technical debt happens, can be quite different. But agilescrumguide.com explains the seven top causes in this article:

Time pressures
Overly complex technical design
Poor alignment to standards
Lack of skill
Suboptimal code
Delayed refactoring
Insufficient testing

What is Experience Debt?

Experience debts reflect the cost of additional rework, as well as possible loss of trust of existing and gaining new users, by choosing short-term functions instead of well-thought-out long-term solutions. In the worst case, errors can creep in at all levels of the user experience.

Top Level: Inconsistencies in the customer journey
Mid Level: Interaction design, Copy, content, and messaging, Information architecture
Bottom Level: User interface, Accessibility elements

The bigger the debt, the more damage will be caused to the business. Or in other words: The costs of frustration is the experience debt that our businesses will pay.

The root causes for the debt

Let’s have a closer look on those seven reasons mentioned above. We can see quite some similarities to our work as designers.

Agile Misunderstood

In the section above, we already saw some points which lead to the erosion of the experience. One bigger reason, I wanted to address seperately is our thinking around ‘being agile’, ‘gaining speed’, and ‘getting data quickly’. While this is not necessarily wrong, we ascribe some things to agile which are not correct.

Low hanging fruits

In almost all product decisions, I have been part of, which feature we build, we decided to go for low hanging fruits. Why? The implementation effort is small. Looking at our impact / effort matrices, that leads often to quickly creating a bunch of shitty isolated shortterm assumed quick wins.

Being hasty with building

Many times our assumptions end up being written code to test with real people. We assume that we a) are right, b) can only learn through fully fletched software, and c) keep building on that written piece of code, even though we should have never done that in the first place. Lowering the risk and validating assumptions can (and should) be done without writing even one line of code.

Not seeing the forest for the trees

Working on a specific feature of a product with your product team day to day makes us operationally blind. We only see our own microcosm and forget the big picture. And mostly we only measure KPIs within the microcosms we are captured in. Measuring this big picture - the overall experience - is harder and a full time job. That doesn’t mean we should leave that out. We need to embrace the challenge and measure the hollistic experience.

Agile ≠ Not having a vision

Based on our learnings we should create a vision what our service / product should and shouldn’t be. The vision is our lighthouse which gives us guidance. Our strategy defines how we will get there. Agile is incorrectly associated too often with not having a Strategy. Only by matching our immediate insights with our long term goals, we can make early and deliberate decisions how to adapt.

How do we reduce the debt?

Avoiding or getting rid of experience debts is not a one time effort. It is something that everyone in the team — or even the company — has to actively and frequently contribute to . The following points are supposed to give guidance how to get minimize or get rid off the debt. It’s not a hard guide, but rather ideas what to think about.

Depending on your current flight level and whether you piled up some debt already, you might want to go one path or the other.

Measuring the holistic experience

Having an overview and benchmarking the whole experience is too often neglected. Mid-size internet companies, which have over 250-1000 people, can have thousands of pages across plattforms. All of those are touchpoints which support our users. Lots of space to mess up the experience. If we don’t have an overview of those touchpoints and their effects on our users, we won’t be able to keep satisfy our users.

Defining design opportunities

One technique of the IDEO design kit that I highly appreciate is design opportunities. Based on our insights we learn in the qualitative research with our users, we create a short list of four to eight opportunities. Such opportunities can have a lasting impact on the quality of the designs. It is as well a very good tool to measure the impact of the designs on our users success.

Sticking to guidelines

In todays design organizations it is not uncommon to see Design guidelines. They are used to ensure a consistent visual appearance and interactive behavior across touchpoints. Mostly the range from being asset libraries to being complete data bases which include animations, copy text , frontend code, backend logic, and even process workflows.

These guidelines are very good tools to mitigate the debt which would appear otherwise.

Iterating continuously

Jeff gothelf gives the perfect example of the magic of iteration, as he talks about the pottery class, which was divided into two groups. Both groups had to create pots. The quantity group would be graded based on quantity, while the quality group would be graded based on quality. In the end, the quantity group produced also the pots with the best quality, because they iterated a lot. While the quality group had only theory.

Iteration is an important factor in order to get red of bigger debts. Mostly we cannot (and maybe should not) do everything at one in one huge task. Rather you do small steps, but many. In product teams this means making the debt visible, communicating the imprtance, and prioritizing it accordingly. Finally it is our duty to sprinkle small tasks into the product development, which help to increase the experience and to resolve UX Debts.

User Testing

Our biggest strength as UX designers are our users. We should give them the power to improve our products. Nothing is more vauable to us, seeing our users reacting positive or being frustrated when interacting with our designs. If we don’t test on a regular basis, involve non-design stakeholders, and prioritize accordingly, we won’t get rid of UX debt.