Who Do They Think Read Errors, Anyway?

Back in 2004 Jason Fried and Matthew Linderman of 37 Signals wrote Defensive Design for the Web because there was a real epidemic spreading around the Web. Error messages were cryptic, server-generated strings of gobbledygook that didn’t make any sense to the real people visiting websites, and very few large websites seemed to give any thought or planning to failures or error messages. Over ten years later, companies have learned to make error messages contextual, meaningful, and tailored to their audience… right?

Unfortunately, too many websites still have the same problems outlined in Defensive Design for the Web. They just spit out whatever the server, database, or content management software has set as a default (which is never user-friendly, by the way). As someone who’s been guilty of neglecting error messages, I understand how easy it is to launch a site without considering every single point of failure possible. But too often lately, I’ve come across large websites that haven’t given nearly enough thought to their errors and form validation.

Take for instance this error I saw on a pretty popular website not long ago…

We clearly need a refresher on contingency design and effective error messages. Let’s recap some of the key principles of Defensive Design for the Web, which are still just as important almost a decade later.

Where’s the Problem?

Error messages and alerts have to be obvious. They can’t be hidden in regular-sized text or placed at the top or bottom of the page. Make them big and bold. Give errors, warnings, and notices different backgrounds and visual elements to make them stand out. Place the error messages contextually… put them immediately above, beside, or below where the error occurred.

Google not only places the error message right below the problem area, they also highlight the problem field in red. There’s no doubt what was wrong here!

Be Clear. Crystal Clear.

Provide clear instructions on forms. Clearly indicate any required fields. If you require a specific format for the field (like XXX-XXX-XXXX for phone numbers) then be sure to communicate that to visitors. Better yet, disable disallowed characters and add any delimiters using scripting. After all, this is 2014 and we have jQuery now!

Speak English, Not Klingon

Unless you’re ThinkGeek, your visitors don’t understand cryptic error messages, numbered error codes, or debugging output. It might be beneficial for developers, but turn those messages off on live, production websites!

Instead, write for your visitors. Think about who your customer is, and write error messages specifically for them. Wiltshire Farm Foods is a UK e-commerce company specializing in pre-cooked, frozen meals for elderly. Their average customer is over 65 years old, many in their 70’s and 80’s. Check out one of their errors below:

Make sure errors, warnings, even notices are written for your end users. It’s not hard to do, it just takes a little thought. Such a small investment of time up front could have a profound impact on your conversion rate, if you make it easier for your visitors to fix errors and continue on to complete their order or signup.