The one where we forgot all about erro(r)s
Written by Mario Ferrer & Sergio Vila
Season 1, Episode 22
FADE IN: INTERIOR, DeliverOuch!™ OFFICE — MORNING
One of the programmers at DeliverOuch!™, the world leading app in food delivery, approaches a guy from the design team while he’s sipping on a cappuccino at the fancy and extremely cool company kitchen area.
Programmer: Hey man, we just implemented the error handling system and we need something to show on the screen when an error happens.
Designer: Ok, let me know how can I help.
Programmer: Well, we just implemented 3 different types of errors: a server-side error, a client side-error, and an error we show when a user makes a mistake filling out a form.
The designer takes another sip from his cappuccino. He only understood a couple of words of what the programmer said, but he just nods nonchalantly.
Designer: Interesting. Just to make sure I’ve got it all. What’s the difference between a server-side error and a client-side error?
Programmer: in a server-side error, the server crashes and all the info users send through the app gets lost. In a client-side error, the info users entered is still on the device and they can try to send it again. A client-side error may be due to a connection error, not enough coverage on the user’s side, or an error in the format of the data they entered. However, we can’t tell which one it is because the backend we spent 5 months programming was not designed to support that. That’s why we need you to design one error message that fits all.
Designer: I see… ok, let me know if I understood it well. So you said that we need to tell users that there was an error but we can’t tell them what caused the error or what they can do to fix it?
Programmer: Yup. Well, you can tell them whatever you want, but we can only show one message that should cover any of the three types of errors at the same time. It’s just a few words, it should be super easy for you.
Designer: Ok. Let me talk with the UX Writer. I’m sure she will love the challenge.
Later that day, the designer takes the UX Writer into a meeting room and explains to her what they are supposed to do. The UX writer starts yelling and cursing: “But… THAT’S IMPOSSIBLE!”, She says. The designer looks at the writer as they both begin to rock back and forth in a puddle of their own tears.
It all came down to this:
“Uh-oh! Something went wrong with your order…”
CUT TO: INTERIOR, HOUSE — EVENING
Mister X arrives home after a hard day at work. He’s so tired that he throws himself onto the couch. He’s hungry. VERY HUNGRY and in no mood to start cooking. What a dilemma! A friend told him about DeliverOuch!™ that cool new app that brings you food to your doorstep.
He takes out his phone, gets the app from the app store, and opens it.
Mister X: I’m so hungry, good thing this app will get me some food quickly. Oh, wait… first I need to create an account. Ok, that makes sense. They need to know who to bring food to.
His stomach rumbles while he fills out the form to create an account. That was easy-ish. He just had to type his email and choose a password and check his inbox to validate that the email he used is actually his email (you know, there’s a lot of evil people out there). After some taps around, he’s finally in!
Mister X: Great, now let’s grab some food! hmmm… Ok, I think I’ll have some sushi. Yeah. I’ll get some of this, and that, and this. Ready! Now what? Oh! Right… my address, my credit card number, when I do want to receive it? As soon as possible! any notes? Yes, I’m allergic to gluten and seeds… Done! It took some time but it’s always better than cooking. I’m sooo hungry!
Mister X’s stomach rumbles again as he taps on the “place your order” button. He can’t wait to get his food. “This is awesome!” — he thinks.
All of a sudden a message pops up:
“Uh-oh! Something went wrong with your order… ”.
Mister X is confused. Something went wrong, but he doesn’t know what happened. The worst thing is, he doesn’t even know what he’s supposed to do. He taps on the “Ok” button, and the error message disappears. All the info he entered is still there, and everything looks fine. He taps on the “place order” button again, and after a while, the same error pops up:
“Uh-oh! Something went wrong with your order… ”
He’s quickly going from hungry to hangry. Mister X cancels the order and starts over again. He’s confused, and he knows the alternative is cooking. And he doesn’t want to cook.
Mister X: Maybe it was my fault. I will start over again.
He does all the steps again: the sushi, a side dish, something to drink, dessert, my address, my credit card number, when I want to receive it, I’m allergic to gluten…
He taps on “place your order” and…
“Uh-oh! Something went wrong with your order… ”
Mister X curses and throws his phone on the couch. He grabs his coat and walks to the nearest takeaway restaurant three blocks down from his apartment.
FADE OUT
DESIGN DIRECTOR’S NOTES
Let’s be realistic. We all make mistakes every day, and we’re surrounded by apps and products that don’t always work as we expect. That’s not because humans are necessarily stupid, it’s human nature to make mistakes, and that’s how we learn. However, we learn much faster when errors are clear.
On the other hand, machines never make mistakes; they make errors. Now, here’s where it gets interesting. If we agree that humans make mistakes every day, and those same humans are the ones creating machines and coding software; imagine the potential number of errors we see in a day.
When teams face the design (or re-design) of a product, the goal can’t be to create something that is error-free. That my friends, is impossible. Instead, we should assume our humanity and the fact that it’s not possible to make everything perfect. Believe it or not, most product teams still think that their goal is precisely that, to create the most robust, never-failing, “perfect” app. When teams design following that goal, errors are considered corner cases and the proposed solutions are always afterthoughts.
Not anticipating what kind of mistakes a user can make or not considering how errors are handled will create situations where users may feel stuck or even worse, they may feel stupid. That creates stress and guess what, our brains are designed to avoid stress. If you don’t tell your users what went wrong and if they don’t understand what happened or what they are supposed to do when an error occurs, they will get stressed and run away from your product.
We are building the backend. We don’t need design.
Dirty little secret: YES, YOU DO!
We’re sure you’ve heard this a lot of times, but we’ll tell you once again: include designers and content specialists early in your product meetings. If you don’t plan how you’re going to talk to your users, which content you’ll be providing them, how they’re going to interact with that content, or even how you’ll tell them that something went wrong; how are you going to build the system responsible for storing and manipulating the data enabling all of those?
If you talk with the design team after implementing, you’ll most likely end up applying patches, taking last-minute design decisions to minimize tech problems, or even laying on your users the burden of dealing with situations that the app should handle.
Including design and content too late in the process results in situations similar to Mr X’s story. The development team took decisions assuming that users would know how to manage errors without taking into account the context in which the app is used or explaining to them what to do if something went wrong.
How to write better error messages?
Our friends at UX Design World posted a great article we highly recommend if you’re on the mission of designing and writing error messages.
They have a thorough checklist:
- Be clear and not ambiguous
- Be short and meaningful
- Don’t use technical jargons
- Avoid negative words
- Give direction to users
- Avoid uppercase text
- Be specific and relevant
- Provide appropriate actions
- Use a progressive disclosure approach
- Use proper placement
- Be humble, don’t blame users
It seems like some products are designed to sound like a grumpy old teacher: “This email is incorrect!”, “We’ve warned you three times!”, “Don’t do that again.” — that’s why we’re big fans of the last item on that list: Don’t blame the user.
Be humble when you approach designing error messages. Think about what people are going through while using your product. That empathy will help you write messages that sound like a person is behind the design, instead of a robot spewing phrases like: “Unknown error.”, “Exception processing message 0Xaaaa5675F.”, “The core system DLL file is corrupt.” You get the idea.
Be polite when you write, use humor when possible, describe the situation to your users and what they can do to recover from that error. Do what you would normally do in a conversation when you’re trying to help a fellow human being. We know writing is not an easy task, that’s why you can start your first draft as if it was a conversation. That will give you a better idea of what type of error message is helpful and doesn’t sound like a quote from a lousy space movie.
Too many error messages are also stressful
If you got this far, it’s because you care about errors and you agree with us that they can help you improve the product’s experience. Just be sure that you don’t overwhelm users with a lot of messages about things that go (or may go) wrong.
It’s like trying to enjoy driving a super fancy race car with someone sitting next to you who’s yelling all the time: “Be careful!”, “Don’t go that fast!”, “Remember to stop when you get to a red light!”. It might be helpful in some specific situations, but overall it will make you feel stressed and will completely ruin your driving experience.
When something goes wrong, be specific on what happened and offer suggestions to users on what they should do to solve the problem. Try to anticipate the mistakes people do whenever possible. Observe your customers using your app and take notes of any possible mistakes they make. Another option is to talk to them and see which problems they typically encounter when they use similar apps. Take error design seriously and don’t leave it to the end of the process. Having a way to help people recover from errors will make users feel in control, they will want to explore further, and come back to use your app again.
Final thoughts
We all make mistakes. A lot of them. Every single day. Instead of trying to design products that are error-free, embrace the mistakes and design for errors. Watch people using your app or any other product similar to yours. Observe where they fail. Take notes. By designing for errors, you will improve the experience of using your product and make your users happy.
We recommend that you read the following articles. The authors are way smarter than us…
- The psychology behind UX: 9 things you should know by Queble
- How to write good error messages by UX Design World
- How to write a perfect error message by Vitaly Dulenko
- How to: Error messages by Oliver McGough
- Designing for errors by Suraj Srinivasa
Designfeld is a comedy series about a UX Designer and his fellow UX Writer, in their struggle to find… they don’t even know what they’re struggling to find, they just want to share their views on Design and why it can get quirky sometimes.
