I fill out the form properly, I thought, then click submit. At that point I see a message about my chosen password being invalid because it didn’t contain both upper- and lowercase letters, plus at least one number. That’s a fine requirement, of course, but why didn’t the registration form indicate those requirements? It’s obvious that an email field needs a valid email address, but if you’re developing a site and you know that you’re going to validate a field to confirm that it includes both upper- and lowercase letters, plus at least one number, how about telling the end user that, too? So here’s the first, most important rule of a good user interface:

A proper user-interface sets the user up to succeed.

Whether you’re designing a Web site, managing a group of people, or being a parent, you have to put your users, employees, and children in a place where they can do things well. And by “well”, I mean: they can do things they way you think they should!

Conversely, I just finished doing my United States taxes, which I always do online using TurboTax. I use TurboTax primarily because the user interface is extraordinarily well done. For example, it’ll ask you a seemingly random, strange question, like “Did you roll over the proceeds from a farming operation into a non-work-related 403b?” I might look at that and go “huh?” but one great thing TurboTax does is add parenthetical notes like “This is not common.” Simple and brilliant. And TurboTax has other nice features, like indicating where you are in the process, reviewing the data you’ve entered, and so forth, but the clear messages—right where I’m focusing at that moment—make it easy for me to use the system properly.

It can be tricky for developers, who are theoretically quite knowledgeable about computers, to put themselves in the mindset of an end user, but there here is one simple way to create a successful user-interface: look at what you’re doing on the server side of things. If you’re going to check a password field for a number, put a message on the form saying a number is required. The same goes for a length requirement. If a date will be validated against a given format (like four digits for the year), have the form indicate the proper format, too. The same goes for phone numbers. If a username can’t contain a space, say as much. Set the user up to succeed instead of making them feel stupid for not doing something they weren’t told to do in the first place!

The thinking behind poka-yoke is that a thing–software, hardware, whatever–shapes the user’s behavior in order to prevent or limit mistakes. An example that Wikipedia gives is how the key in an automatic transmission car cannot be removed unless the car is in park: the car tries to prevent you from leaving it in an unsafe state.

As Hoekman said in his presentation, we should be designing Web sites and software using poka-yoke, but often the design and interface of our creations encourages users to make mistakes. Or practically forces them to. For example, if you want a date in a specific format, you could indicate the format required. But a better solution would be to use a pop-up calendar widget where the user selects a date, that then formats that date properly. Even better, program your system so it accepts a date in multiple different formats in case the user doesn’t use the calendar widget. This last notion is part of a general theory of providing alternatives to your users, not trying to lock them into using your site in one set way (again, this is coming from Hoekman).

For more information on this subject, you should check out Hoekman’s site and his books. I’ve not read them myself, but have added them to my ever-growing list of books that I intend to read someday. His first is Designing the Obvious: A Common Sense Approach to Web Application Design. His most recent is Designing the Moment: Web Interface Design Concepts in Action.