Every system needs a way to get its issues worked out. It’s not always the most glamorous work, but designing a good framework for error handling is crucial in helping users avoid frustration and reach their goals while using a product. In this way, I’ve found it to be rewarding.
I recently had the opportunity to work with a team at Facebook on a three-month project focused solely on helping advertisers address and resolve errors found while creating ads on Facebook. Facebook’s system is powerful, albeit sometimes confusing. With all of the different moving parts and the ability for in-depth ad customization, an error here and there when creating an ad is a given.
Facebook’s team discovered that advertisers were entering the ad publishing flow and at that moment finding out that they had several errors that would prevent them from publishing their ads. Can you think of a worse time to be confronted with a list of problems to fix? With the problem defined, I worked closely with their team to reduce the number of errors that appeared at this specific time. To help focus our efforts, we adopted a short, repeatable mantra that would keep us on track.
Errors Should Be Surfaced Well
How could someone possibly solve a problem if they don’t know it exists?
Our users are busy people who have a lot they want to accomplish. We understand their time is valuable, so we help them move through problems quickly and continue on their way. This means that as soon as an error is detected, we make sure the user is made aware. Issues shouldn’t pile up or be surfaced all at once in a summary later in the flow.
It’s also important to make sure the error message is highly visible and easily recognizable. A good rule of thumb is to place the error message next to the relevant field. In the product I was working on, it was common for users to start the creative flow and save things as a draft to finish later or hand things off to a teammate. In cases where ads were left as drafts with open errors, we ensured that these errors were visible at all times, even in overviews or table views. This way, the user knows exactly where they stand when they hit “Publish.”
As it so happens, the best time to let someone know you’re upset about something is also immediately. Being direct about an issue while the problem is still small is key. If you don’t tell them something’s wrong, the likelihood of them being able to fix an issue is pretty much zero. And dropping hints or pouting around the house doesn’t count either. I know it can be tough and potentially awkward, but it’s likely they had no idea they were doing something to irritate you. If they’re a good egg, they’ll hear your concerns and try to do better.
Errors Should Be Easily Understood
How could someone possibly solve a problem if they don’t know what it is?
Three of the most frustrating words a user can encounter when using a product is “Something went wrong.” As an error message, this is beyond useless because it doesn’t say what caused the problem and, as a result, gives the user absolutely no idea how to fix it and move forward. Depending on how important their task is, this can be a complete day wrecker. An ideal error message uses plain language (no technical jargon), is specific about what the problem is, and is delivered in a friendly way.
Clear messaging is just as important in personal conversations. Letting someone know you’re upset by saying, “I can’t believe you, you’re so selfish!” is about as useful as “Something went wrong.” Sure, they get you’re upset (which checks our first box), but they probably don’t have any idea why. A friendly tone goes a long way here too. People are more likely to listen and less likely to get defensive if they don’t feel like they’re being accused.
Errors Should Be Actionable
How could someone possibly solve a problem if they don’t know how to?
If we’ve been able to clearly communicate the error to our users, the final step is to help them resolve it so they can get back to what they were doing. Pairing a clear description of the error with simple instructions on how to fix it allows the user to move forward quickly. If done well, it should also give them some insight on how to avoid a situation like this in the future. If you can go one step further by automating part of the solution, that counts for bonus points.
If we’re willing to extend this kind of help to our users, it couldn’t hurt to do the same for the people around us. If our expectations aren’t met or we feel like we’ve been wronged, why should we make the other person guess how they can make things right? Being clear about how you expect things to change can get rid of a lot of that confusion and produce a result you’ll be happier with.
The main thing I’m getting at here is that good error handling is beneficial for everyone involved. Save both parties a lot of time, frustration, and disappointment by simply being clear about what’s wanted and needed. So, let’s be good to our users! Let’s be good to our loved ones! Let’s be good to ourselves, dammit!