Lately, I’ve been working with error messages in Fulcrum, and have realized that writing user-targeted, helpful error messages is difficult. Difficult, but worthwhile.

I just read an article about how to write a great error message which I wanted to discuss.

His three bullets have great ideas.

1. Don’t abuse alerts for upselling or showing superfluous information. People will stop reading the messages that are actually important.
2. Don’t just assume people know about the context of a message. They might toggle between apps and see your message days after it happened. Always include enough information for users to make sense of it.
3. Use a friendly, non-technical, non-threatening tone of voice.

I’ve had some additional thoughts on error messages that I wanted to make note of.

Think Outside the Happy Path

It’s easy to optimize for the nominal case; to make that user experience great. And it’s also easy to half-heartedly approach error messages. In reality, error messages are just as important as, if not more than, the happy-path.

Done well, helpful error messages will make your customer’s lives easier and give them a feeling of satisfaction with your product. Done poorly, your customers will have no idea what to fix, feel defeated, and stop using your service. Think about your own experience with error messages. Most of that would be classified as futile, right?

If you have a trial, this is even more important. The trial is when the customer knows the least about your software that they ever will. This is when they’re most likely to make mistakes or need your guidance. Error messages are a way to help them learn more about your product. To help them gain confidence with it. To show them how your product makes their lives easier than the well-known method they’re already using. It can make the difference between them ditching you all together, or converting to a paid account. That’s a tall order, particularly when it’s a self-service style offering.

The happy-path is the first one considered, designed, and implemented. The error paths come later and don’t get as much love. So most error messages are an afterthought, which leads to them being frustrating and inconsistent, instead of helpful and empowering.

Add in the fact that most software has awful error messages, it’s yet another way to stand out against the competition. In fact, good error messages are another form of good customer service. By helping them with errors, you’re anticipating their needs. And that makes for happy customers.

Modals Are the Worst

Modal error messages like a Javascript alert() are frustrating. They don’t let you interact with the program until you’ve closed the error message. This is problematic because the user has to keep the error message in their head after they close the modal. And then they have to figure out what it was that caused the message in the first place.

An error message is likely best shown inline, alongside the thing that caused the error in the first place. If they needed to enter some text but didn’t, show them that text input, along with a message, and give it a visual treatment to stand out. This gives them a solid context of what to address.

Showing the error message inline also gives you more room to offer advice on how to fix the issue, and to provide links to FAQs or tutorials. You’ve worked hard on that content, so why not link users to it when they could use it most?

Modals are also susceptible to disappearing accidentally. Ever been typing when an error message appears? And then your typing accidentally dismisses the error message before you could read it? You weren’t even expecting this error message, and now you’re not even sure what it was about. Was it something vitally important? Do you need to do something? Did you just agree to something you didn’t mean to? How can you trigger it again to see what you missed? It’s frustrating and potentially dangerous.

Just now, I had an error message where an error dialog displayed on a different monitor than the one I was actively using. That makes an error even more prone to being hidden, missed, or accidentally dismissed. I can’t even write a blog post without experiencing an error message. These things are everywhere!

Consistency Across Experiences

Deciding on a consistent way to display errors is difficult. Adhering to a single approach throughout the entire application is even harder.

Mobile devices have the additional challenge of limited screen space. The most helpful and descriptive message shown in the article was from a desktop. How would that all information be best displayed on a mobile device? And how would you do that without using a modal? Perhaps displaying the messages inline, as I mentioned above.

Error messages can have different conventions between devices and browsers, client side and server side. But that’s an implementation detail. It’s up to the developers to handle error messages in a consistent, helpful, and unobtrusive way. Otherwise we’re doing our customers a disservice.

Choose Helpful Error Messages

The idea of not showing an error message at all is very interesting, and I’d like to see what potential that has. Instead of an error message, could you choose a sensible default and then show them a notice instead? In what cases does that approach not make sense?

Going forward, I’ll be looking for ways to improve Fulcrum’s error messages so that our users have an easier time getting to learning and using our service. We aim to provide fantastic customer support, and this is another way to work toward that end.

As developers, we’re in a position to help change what’s standard. Let’s work to make helpful error messages the standard.