Creating user-friendly error messages

How can engineering teams build error and loading screens that engage and delight users when things go wrong?

As a distinguished engineer, I get to spend a lot of time thinking about how to make things better.

Don’t get me wrong, I like creating new things, but I get way more of a kick out of making existing things better. And lately, I’ve been thinking a lot about how to make the unhappy path happier.

In software development and design, the happy path is the scenario in which everything goes perfectly and the product works just as it should; every single piece of data is available, correct, and delivered within the service provider’s SLA.

Over the last 20 years of being a developer, I can’t count the number of times I’ve been asked to build a feature where the product owners were solely focused on the happy path. When I’d ask what the user experience should be if a call were to fail or take too long, I’d hear the same answers: ‘oh, we’ll just show our typical error screen’, or, ‘we’ll figure that out later, we really just want to see it working ASAP’.

But errors are bound to happen. We all want 100% uptime and 100% accuracy delivered within the timeframe of the SLA, but that just isn’t realistic. At some point, our customers will encounter problems and delays when using our products.

And we all know that when you bolt something on as an afterthought, it never works well or feels like a part of the ecosystem. So why treat error messaging – a core part of any product – as an afterthought?

Shouldn’t error and loading screens be the first things we build? Shouldn’t we be prioritizing these features, perhaps even rethinking whether they’re the right solutions in the first place? Given the inevitability of things going wrong, shouldn’t we be practicing error-driven design and development?

At the very least, we should be taking steps to improve the user experience of our error screens and messages. As engineering teams, there’s so much we can do to make our error and loading screens more exciting. Here I’m going to share some examples, along with my advice for getting it right.

Errors are opportunities to engage users

I remember the first time I was genuinely delighted to encounter an error as a user. It was several years ago, during the first Amazon Prime day. I’m guessing Prime day was way more popular than even Amazon expected because the volume of traffic brought their site down.

But to my surprise, instead of a basic error screen, I was met with a photograph of an adorable dog. There was a short biography explaining this dog belonged to an Amazon employee, and a link to see more pets.

While I couldn’t shop, I had a great time clicking through the photos and I walked away with a smile on my face. And when I chatted to other Prime customers, those cute animals were the talk of the day – not the incident.

Clearly, Amazon didn’t want to have their site crash – I’m sure they’d have preferred to take our money – but there we were (and still are) talking about being happy customers. By thinking creatively and taking an error-driven approach, Amazon managed to turn a frustrating incident into an opportunity.

A creative approach to error screens

I learned a lot about error handling from working in television and building the X1 platform for Comcast. When we encountered errors, it meant our customers couldn’t watch a show OnDemand or stream something on their Digital Video Recorder (DVR).

Just imagine, you get home (or log off) from a long day at work, kick off your shoes (or slippers) and just want to watch last night’s episode of your favorite show. You browse to your recording of the show and boom: an error screen that says it can’t play. Now that’s a terrible user experience.

To tackle this, we completely rethought our terminal error process. Say a user tried to watch a DVR asset and there was corruption on the hard drive in their physical cable box. Instead of showing an error and leaving them to their own devices (probably taking to Twitter to complain – oh no!), we would be proactive.

First, we’d see if we had a cloud-based DVR recording for that same show and stream that. If not, we’d see if it was available in their OnDemand library. We’d do this automatically and seamlessly because the user shouldn’t have to do the hard work – they had a long day already.

If both these routes failed, we wouldn’t just shrug and tell our customers they were out of luck. We’d offer to record the show the next time it was on and alert them if it was added to OnDemand. Finally, we’d suggest a similar show they could watch right now. If we helped a customer find a new favorite show, then we just turned a bad experience into a great one.

The next time you’re about to code an error screen, think about being the person on the receiving end. How many times have you reached an error message asking you to call a phone number, where you will most likely be put on hold? Why can’t the application or website you’re using offer to call you instead?

You know the abilities of your system: could you auto-heal? Could you retry the action on the user’s behalf? Could you automate some if not all of what you are going to ask the customer to do manually?

Don’t neglect your loading screens

It’s not just error screens that leave us with a missed opportunity to do better. We also need to think about loading screens. We see them all the time, on our phones, computers, smartwatches, and televisions, whether it’s dots, a spinning wheel, or a loading bar, and we just sit and stare, hoping that whatever is loading will do so faster.

Recently, I was trying to request an Uber home from work but there weren’t any drivers available. Typically in this scenario I would sit staring at my screen, watching those all too familiar loading dots, hoping a car would become available. But this time, the app prompted me to take a quick coding quiz while I waited.

I was intrigued! I quickly accepted and it turned out they were sharing short tests because they were hiring. I was greeted with what looked like a typical IDE and given various tasks from multiple-choice questions and ‘find the bug’ scenarios to quick code-fixing and line-writing exercises. I’m not sure how they knew I was a developer (we’ll leave that for another article), but it was a really fun way to pass the time as I waited for a driver.

There are so many ways we can make the ‘loading’ experience better for our customers, as well as our companies. Uber used the opportunity to hire fresh talent that they knew were already customers of their brand. Next time you create a loading screen, think about how you can use these valuable seconds of your customers’ time and attention to promote other opportunities.

You could inform them of new features or products, give them a fun quote of the day, or even upsell them to a new tier of service. Why not tell them if it’s going to rain later, and remind them to take an umbrella? You could see if they can solve a quick riddle, play a game of sudoku, or do a paint by numbers for relaxation. Or maybe just show them another cute dog!

Reflections

Too often, we approach error handling screens as something users should never see, so we make them bland and sad. But users are going to see them, and it’s time to start investing in making them quality product features. Start finding new, inventive ways to delight your customers when things go wrong and turn your incidents into opportunities. And the next time someone asks for a demo of the happy path, remind them that the unhappy path is just as exciting.