Errors: how "nice to have" can cost you many users & customers.

NICE TO HAVE

In my experience, I've been part of meetings where some decisions lead projects into strategic mistakes.

One example is the "nice to have" concept, where a feature, use case or user flow is considered something that would be a nice addition, but it's not important enough to be developed.

While it is true that sometimes you can't develop everything at the same time, people are quick to downgrade important features to a nice to have, or bells and whistles status. The problem is that many times these alleged nice to havesare actually the difference between your users loving your product, or leaving it behind.

Today I want to explore one important use case that is often downgraded to a nice to have status, even though it makes a HUGE impact in terms of customer experience and satisfaction; I'm talking about error-handling.

Happy path vs. Error-handling

In the process of designing a product, the first natural step is to define the "happy path". This colloquial term refers to the steps that a user would take in an ideal scenario; when everything goes as it is supposed to. Let's take the process of posting a photo on Instagram as an example. In this use case, the broad strokes for the happy path to post a photo are:

Take the photo

Edit / Enhance

Post.

A lot of effort should go into designing the happy path for this scenario. And rightly so, we want to make sure that the experience is as friendly and effective as possible. However, what happens when a user makes a mistake? When for some reason the user wants to go back to retake the photo? or when the signal / connection is lost and the photo fails to upload?

This is where good error handling comes into play.

When everything is going well, users are not surprised, they expect things to work. But when something goes wrong, they might hold a grudge if the product does not help them resolve the issue.

All of the above error scenarios (and probably many more I'm not mentioning) should be thought of and designed with as much effort and attention as the happy path.

Why?When everything is going well, users are not surprised, they expect things to work. But when something goes wrong, their fault or not, they expect the product to help them out in their time of need. If that doesn't happen, they might hold a grudge towards the product (even subconsciously.)

So put yourself in their shoes; things are not going well, stress is building up, you don't know what to do, and you feel helpless.

Two possible outcomes:

The app provides easy and clear solutions; users are able to recover from the error and become grateful. They often regard the product as smart or well designed. Good work! This is one of the best ways to building a trusting, and even loving relationship.

- on the other hand -

The product fails to help recover from an error. Users will be even more frustrated, and direct their frustration (often turned into anger) towards the product's "bad design". In an era where good user experience is widely accepted and demanded, users are quick to identify and point at design gaps.

Don't make error-handling a nice to have.

If effective error-handling impacts UX and user satisfaction so much, I think it should never be a nice to have. It leads me to believe that a happy path is not complete if its error-handling use cases are not accounted for.

But why do people do it?

Why do they make error-handling a nice to have? Many reasons:

Maybe someone advised that error-handling was not that important and left it out of the requirements.

It could also be the case that the team used up all their time on the designing the happy path, and when errors were identified, it was hard to put more time into solving them.

Maybe by not accounting for error-handling early on, the timeline now needs to be pushed (Side note: sticking to a timeline does not always mean more profitability (Blizzard is a good example), it also has a lot to do how happy users are, acceptance rates and return customers).

Or maybe (and sadly) people just don't want to put the effort in, and feel the product will be "good enough" as is.

Regardless of the reason, people will make assumptions that justify downgrading the use case as a nice to have. Common phrases I've heard are:

"Well, I'm sure most users won't make that mistake"

"Users don't care that much, they'll be fine"

"If there is no connection to the internet, users shouldn't be using the app in the first place"

or even things like "Well, if they make a mistake, too bad for them, they can re-start the process".

The most charming speakers might get away with such phrases, but ultimately the success of a project depends on the acceptance rate and satisfaction of users.

Avoiding nice to have re: errors.

To avoid nice to have regarding errors, I'd like to suggest the following:

Before hitting the drawing board, make sure that the team is on the same page regarding error-handling and its importance. This will hopefully focus the attention early on to the different error scenarios, and avoid big changes to timelines and budgets mid-project.

If mid-project you discover an error that can potentially deter user acceptance, or plain anger your users, make solving it a priority instead of downgrading it to a nice to have. Avoiding the problem will just make it bigger once the product goes live. Also, users value great UX in a few places, over having many half baked, error prone features.

If you there is no other option, and you really, really cannot make error-handling a priority before release, well, go ahead and release. But I would advise to make sure to re-visit the issues in subsequent releases to minimize the impact of the errors on your product.

What are your thoughts?

Have you been in a situation where an important feature was downgraded to a nice to have?

When and why do you think it's appropriate to refer to a features as nice to haves?

Hopefully this article helps you plan your next project, or at least provides some insights on error-handling prioritization and what nice to have implies.