Defensive Design

Summary

To summarize, this is a book about user experience, focused on concisely and consistently displaying error messages, warnings, and validation notices that clearly define the issue at hand.

I agree with most of what the authors have to say. Some of it, is just common sense. I’ll try to highlight the key points about defensive design in this article.

Put yourself in the user’s shoes

Some of the things they mention have to do with how users react to the UX you provide. Don’t overwhelm your users with more information than they need. Realize your users don’t know the internals of your application. They don’t know nor care exactly why something went wrong, they care about how to solve that. Be human, technical blabber will drive them away in droves.

Don’t scare your users away from your site by telling them something like “Something went terribly wrong”, try and be helpful instead, mention how to work around the issue, or provide an alternative, or prompt them to try again later. Don’t just tell them that your site blew up. They’ll leave and never come back again.

As a rule of thumb, tell your users what went wrong, but be as general as possible, while still being helpful. The only exception to this should be errors as the result of ill intended behavior, such as manipulating AJAX requests to your site. In those cases, it’s fine to be a little more obtuse.

As a Security Concern

Being too helpful about exactly what went wrong and how it happened, can go a long way in helping a malicious user gain access to your servers. You should never serve end users with detailed error descriptions, stack traces, server logs, or the like. But I guess, this again, is just common sense. Who’s going to serve a full stack trace to the end users of a website, right?

Be nice and generic, yet concise and consistent

Make an effort to display error messages in a consistent way across your entire experience. Keep your error handling logic in one place, and it should be easy for your whole application to handle and display error messages in the same way. Not doing so certainly won’t help your user in thinking your brand is unified and working as a unit.

If each independent submodule of your application displays error messages in a different way, or at noticeably different levels of detail, users will have a hard time feeling your product isn’t merely a bunch of modules mashed together, and probably an unstable mess which will crumble in the presence of the smallest hiccup.

If your error messages are consistent, this will portray a message of unity and cohesion which will go a long way towards building trust towards your application.

Obviously that’s not the only factor in building trust, but honest error messaging is a start.

Be concise. Tell your users what the problem is, and how to fix it.

“Try again” just won’t cut it, the user will become frustrated and not know what you mean by that. Did you mean for them their login credentials were invalid? Did you mean the servers are overloaded right now and they should try again later? Did you mean the username they picked is already in use? Be specific.

Use meaningful messages. “Invalid credentials”, “Username in use. Pick another one”. Explain to your user how to get out of this situation gracefully.

Don’t inflict panic upon your users.

About that…

The book stresses that you should convey error messages in red bold text on yellow backgrounds. I disagree on this count. While you should certainly make your error messages stand out, you shouldn’t make them scary, the user should feel that you are merely informing them about something that can happen on ocasion, rather than sounding so alarmed about it.

OMG! YOU MADE A TERRIBLE MISTAKE!

The psychological impact of such error messaging is negative, you should try to convey your message as a warning, or just a notice, rather than an error that can’t be salvaged. Also, never put the blame on the user. Admit mistakes when internal errors turn up, don’t tell lame excuses.