Expect The Unexpected - Planning For Errors and Unusual Uses
One of the things I discovered with my own children, and other people’s kids is that they rarely play with their toys the way they were designed. I’ve seen my niece cram a Barbie doll into a toy baby stroller. I have seen boys turn toy hammers into toy pistols.
Adults are the same, otherwise we wouldn’t need warning labels. Somebody obviously tried to use a hair dryer in the shower once to necessitate having a warning about it. It’s the same with web user interfaces, tools, and electronics. While you can’t plan for every possible crazy thing a person could do with your interface - you need to escape the expert user bias.
The expert user bias come from designers who have a high level of expertise in their field who forget that their users don’t. I saw this all the time in financial services with web-based text that was confusing unless you had a broker’s license.
The first thing all human experience designers must understand is that your users do not know what you know. Even if you are designing for an expert audience, you will have insights from the design process itself that they will not.
I am not always advocating a dumbed-down interface, but usability testing is a good thing. I have seen applications that designers thought were very reasonable get hammered by users in usability who could not even figure out what they were looking at.
The next thing is to take a lesson from software programming and always plan for errors - both internal and user generated. There’s a story of a Navy battleship that had to be towed back bacause it’s computer system had a ‘divide by zero error’.
You need to also plan for users using your stuff in unreasonable ways.
By and large - most error handling is intrusive, abrupt, and jarring for users. With a little planning this is mostly unnecessary.
As an example: I created a typical web application where people needed to enter numbers on a form. I wrote a little bit of code to prevent people from even entering invalid characters. Your phone number can’t be “aw3dfer4″.
Many web sites still allow you to enter invalid stuff and either pop open a modal window with an error message, or return from the back end with an error message. You then have to hunt for the field in error and correct it, then submit again. Yuck.
Your users will appreciate a more gentle approach to error handling.
A pet peeve of mine are web sites that require certain things from users without specifying them. For example, a password field that requires a certain number of characters must at least have a label that specifies that. Then, if I screw it up, you shouldn’t let me submit the form.
