Designing the Obvious: A Common Sense Approach to Web Application Design

Poka-yoke devices are all around us.

Poka-yoke (pronounced POH-kah YOH-kay) is the Japanese term for "mistake-proofing." A poka-yoke device is whatever is used to prevent an error. It's what makes something foolproof.

The Popcorn button on a microwave oven is a poka-yoke device. Stick the popcorn in, push the button, and watch the microwave turn a bag full of little seeds into a night in front of a good movie. No thought required.

The remote for my car locks all the doors at once, so I don't have to wonder if I left any unlocked. My car has a little plastic strap that tethers the gas cap to the car, so I won't accidentally leave it on my trunk and drive off without it properly attached. The keys can't be removed from the ignition unless the engine has been turned off. And I can't put the transmission in reverse unless I'm at a complete stop.

Dryers stop running when the door is opened so no one gets hurt. Irons shut off automatically after sitting idle for a while to help prevent fires. The bathroom sink has a small hole toward the top of the rim that prevents the sink from overflowing.

Poka-yoke devices are everywhere.

Sadly, they don't show up on the Web nearly as often as they should. When they do, though, it's fantastic. Users can get things done without incident. Things go smoothly. You know, the way things should go.

Poka-yoke on the Web

A Web-mail application I use a lot has a built-in memory of what I do with specific kinds of email messages.

For example, every time I got an email from my task-management system that said "Status changed" in the subject line (the email is sent whenever I change the details of a task), I would throw it away by checking the check box next to the subject line, choosing the Trash option from a drop-down menu, and then clicking the Move button. After the first time I did this, however, I noticed that I no longer had to choose Trash from the drop-down menu. After checkmarking a message I wanted to throw away, I noticed the Trash option was being automatically selected for me. All I had to do was click Move to throw the email away.

The people who built the application did this on purpose. They figured that since it's statistically probable I will move a message to the same place I moved all the other ones that were just like it (which all had "Status changed" in the subject line and were sent from the same email address), the application, very politely, remembers that I have thrown all the other messages into the Trash and selects that option for me in the drop-down menu.

It's the tiniest detail, but it prevents me from making the common mistake of moving items to the wrong folder. (It also makes me feel as if the application is reading my mind, which is a little creepy, but that's a different story.)

Let's face it. Most of what's really bad about an application is how many times we mess something up while trying to use it. Good design can cure this. So implementing poka-yoke devices is probably the number one thing you can do to improve your user's experience. Even the worst designs can be improved by eliminating the possibility of errors.

Prevention Devices

There are two types of poka-yoke devices: prevention devices and detection devices.

Prevention devices are those that prevent errors from ever occurring. The hole in the rim of the sink that keeps it from overflowing is a prevention device. The user can leave the water running all he wants tothe sink will never overflow.

Keeping users from making mistakes on the Web is no small task, but there are plenty of things that can be done to minimize most of the potential errors and keep users feeling productive.

Problems are Big, Fixes are Small

When we were creating Dashboard HQ, the initial design went through several small iterations. At one time, the Add Content pane was designed so that the user had to choose which column a new module would go into once it was created. It was easy to forget to choose a column number from the menu prior to creating the module, so we considered what type of error message would best handle the situation. A red text message that appeared in the pane? A little box at the top of the page that faded in to catch the user's eye and tell him what went wrong?

Dashboard HQ makes it impossible to mess up when adding new content.

We quickly realized the best way to take care of the issue was to make it impossible to make the mistake. In true poka-yoke fashion, we simply set "1st column" as the default value, making it impossible to produce the situation that required the error message. Not only was this method foolproof, it also meant we could improve the application substantially without writing a single new line of code. In this case, the poka-yoke prevention device was a single attribute inside of a single HTML element. Five seconds later, it was done.

But we didn't stop there. Next, we removed the code that checked for values in the fields the user should fill out to create a new module. In truth, it isn't necessary for a module to have something in it to exist. It can simply exist. It can just sit somewhere on the page with a default title ("Enter a title...") and no content whatsoever. Users can always edit the module after it is createdin fact, that's the whole point of the applicationso why stop them from creating it?

In just a few minutes of modifying and testing, we completely erased the potential to make a mistake when creating a new module. Users don't need to name the module, add content to it, or choose where it should appear; they can simply open the Add Content pane and click Create. There is no way for them to go wrong.

Not only did we avoid having to write more code, we actually removed code. In doing this, we also kept ourselves from having to debug the error code (which is always an exercise in irony). One less thing to maintain later on. One less potential problem for users. Win-win.

Remove the Possibility of Error

Another thing we did for Dashboard HQ was to write a tiny bit of JavaScript that ensures URLs entered into bookmark lists function correctly after being saved. Upon saving a new bookmark, the entered URL is checked to see if http:// was entered at the beginning of the address. If it wasn't, it is added automatically before the bookmark is saved. If a user enters amazon.com, for example, the bookmark address is converted to http://amazon.com/.

This script ensures that links work properly in all browsers and that the user is far less likely to see an error after clicking the link later. This poka-yoke device required only a couple of lines of code, but saves users from many potential errors.

Traditionally, poka-yoke devices are simple and cheap. If it takes a lot of work to implement one, you should review the source of the issue to see how you can simplify. Sure, it may mean admitting you were wrong about how your application should work to begin with, but after solving the issue, the application will be leaner and less problematic. (Incidentally, when you accomplish this, it's suddenly easy to admit you were wrong, because it's the precursor to boasting about how gracefully you fixed the problem.)

Many problems can be solved without a lot of extra work. Tiny modifications, like choosing a good default value instead of writing error code to tell users they've done something wrong, are quite often all it takes to improve an application, or even a single interaction, tenfold.

The only downside to using poka-yoke devices is that no one will ever realize how clever we were in coming up with them. The user will never see the error that could have happened. He'll point to his own common sense as the reason he can use the application effectively.

But nothing says we can't smile knowingly from the back row.

Detection devices

In our original design for Dashboard HQ, we were going to write code to show the error to the user immediately so he could fix it and move on. This would have been a detection device. In the case above, we chose the more optimal prevention device, but it's not always possible to prevent every error. When things go wrongand they willit's time to rely on the other form of poka-yoke devices, detection devices.

When poka-yoke can't be used to prevent an error, it can still be used to detect the error and notify the user so it can be remedied immediately. In Web terms, this usually comes in the form of an error message.

We've all come across a billion error messages (give or take) in the time we've spent using computers, and we've been trained over time to ignore them (unless they look unusual in some way and happen to catch our attention). Just click OK, we think, and move on. Oh, wait. Was that something important?

Most of the error messages we see are useless. They are written in cryptic developer-speak, tell us something we already know, don't tell us what to do to remedy the error, and don't offer any choices. If clicking OK is the only thing that can be done, we click OK. Then we're back at square one. Gee, thanks for the helping hand.

Quality error pages

Most server setups allow the configuration of custom error pages, but many designers neglect this part of an application. And that's a drag, because error pages can do so much to help users that we're really missing an opportunity by ignoring them. Instead of simply telling users a page cannot be found, we can create error pages that guide users straight to other content so they can get moving again without even thinking about the fact that they just saw an error message.

One of my favorite examples of a bad error page is from an old version of the Federal Emergency Management Agency (FEMA) Web site. FEMA has a disaster assistance program for people who have been the victims of some sort of natural disaster, such as a hurricane. At one time, the online application process for this program contained several key problems.

The process began with an image verification system that displayed highly illegible images of words, which users are meant to type in a text field to verify they are human beings and not automated systems. Users were given three chances to enter the correct word. Upon failing the third time, the resulting error message read:

"We are sorry for not being able to proceed your requests because you have failed our tests."

Not only was this message poorly written (for starters, the word proceed should have been the word process), making it more difficult to understand than it needed to be, but it also offered no way out. There was no link back to the home page, no suggestions about what to do next, nothing. Just a meaningless error message.

And if you were unlucky enough to have had your home wiped out and unlucky enough to have access only to a Macintosh (and this is one of the few times you would be unlucky to have access to a Mac), you would come across another error message informing you that Microsoft Internet Explorer 6 was required to complete the form.

I'm sorryyou want me to download what now?

Internet Explorer 6 doesn't exist on Mac. And according to Microsoft, it never will. Users who didn't know this fact were likely to wander off to try to download and install the software equivalent of a purple squirrel.

The worst part is that the browser incompatibility message didn't appear until after the user managed to get past the image verification system. This message did suggest to users that they call FEMA directly or download the appropriate version of Internet Explorer, but the application should have worked in any browser, on any operating system. (At the very least, it should have told users to download a browser that actually existed.)

What's so hard, after all, about a simple HTML-based form? Forms are all over the Web. Macintosh users use online forms on a daily basis to purchase books and music, sign up for new Web applications, install software, check email, and so on, with as little effort as any Windows user. How is it that FEMA managed to make something so simple so complex? How is it that they managed to break something that works so well on a million other sites?

Many error pages lack the elements that can help users get moving again, and this is where they fail. Many just explain that the page cannot be found and that the user should hit the Back button or head back to the home page and try to find the information another way. This information often comes in the form of bulleted lists that are heavy on text and light on links, and nothing really useful stands out on the page except for the large error message. But the error message is the least helpful part of the page.

Error pages should help users get back on track by offering up links to other pages that do, in fact, exist. Beyond that, they can offer search boxes so users can try to find the missing content another way, continue displaying persistent navigation items so users can jump to the main pages within an application, and even serve up a log-in screen in cases where users have accounts.

All of these things turn what would otherwise be a useless error page into a poka-yoke detection device. They show users that something has gone wrong and immediately offer them a way out. They enable us to create error pages that offer solutions instead of more problems.

Inline validation

Inline validation scripts are one of the best forms of poka-yoke detection devices on the Web, because they catch errors immediately.

Inline validation, handled by JavaScript within a page, is the act of performing real-time checking to verify that an interaction has been completed correctly. In a registration form, for example, inline validation can be used to verify that the user's chosen user name has not already been taken, the email address has been written in the correct format, and the first and last names have been entered. Upon determining that a field value has been incorrectly entered or has been skipped, error messages can be shown within the form, before the user ever has the opportunity to click the button that submits the form data.

Our Property (www.ourproperty.co.uk), a site that tracks the current costs of buying a home in Europe, has the single best example I've seen of well-designed inline validation.

The check marks tell me I'm smart enough to use this application.

Upon entering correct values (or at least the correct type of value), a green check-mark icon displays next to the completed field. When the email address is entered, a loading animation plays while it's validated to ensure the email address is real.

I skipped a required field, but the application told me immediately so I could recover gracefully.

And when a field is skipped, a red X appears to indicate the field was not completed correctly.

These simple interface elements guide users toward a successful interaction. The only thing I would suggest to improve the interaction is to disable the Sign Me Up button until the required fields are complete.

It's important that inline validation be carefully designed so it comes across well. Remember the Milk (www.rememberthemilk.com), a to-do list management application, uses inline validation on its registration form, and does a great job of validating that a user name has not already been taken, but error messages are displayed every time a field gains focus, even when the user hasn't yet had time to enter anything into the field. The result is that users are shown error messages almost constantly while completing the form.

Remember the Milk showed me an error message before I even had a chance to make a mistake.

Validation should only be performed when a user leaves or passes over a field that is required without correctly completing it. When a text field that accepts required information, for example, loses focus, an error should be shown. An error should not be shown if the user has not yet had a chance to enter the correct information.

Turn errors into opportunities

Poka-yoke detection devices usually result in the error messages we're all used to seeingJavaScript alerts and suchbut some companies try to improve on this idiom by putting a positive spin on an otherwise negative situation. This is by far one of the best ways to deal with errors that can't be prevented.

For example, when a user's search on Squidoo produces no results, Squidoo turns the error into an opportunity by displaying a message that prompts the user to create a lens on the searched topic.

I'm one of the first to search for this topic? Fantastic! I'll build a lens and be a Squidoo pioneer!

Squidoo developers recognized that it takes a lot of time to build up a knowledge base of every subject for which users could possibly search, and attempted to find a way to compel users to create more lenses. Smart move. The poka-yoke device in this case is the search engine itself, detecting that no results are available for a topic and displaying a call to action instead of an error message. The result doesn't even look like an error. It's way too friendly to make a user feel like he's messed up. Instead, the user takes a moment to decide whether or not to create a lens on the subject, which is exactly what Squidoo wants to happen.

Google puts this technique to work as well. When a user runs a search that appears to contain a misspelled word, the first item in the search-results listing is an attempt to clarify what the user was trying to search. (Of course, what actually happens on the Google side to detect misspelled words and suggest alternate spellings is much more complicated, I'm sure, but my mental model is that it just knows I misspelled a word.)

Yes, actuallythat's exactly what I meant. Thanks! Click.

Google Suggest (labs.google.com/suggest), on the other hand, blurs the line between the two types of poka-yoke devices by putting both to good use. It detects what the user is attempting to search so it can keep potential mistakes from occurring, and then prevents them by helping the user enter the correct search terms before the search is run. When the user begins entering search terms, a list of words and terms that are likely to match what the user is looking for appears, so the user can choose the desired search term and avoid common misspellings.

Google Suggest helps me spell correctly, type faster, and find common search terms, all without making a single mistake. Nice.

An example from home

I use poka-yoke on my own site as well, to ensure users can properly use the Adobe Flash plug-in to view the content of an eReader application I created to highlight some bits of interface design advice I call "The Web Commandments" (www.rhjr.net/eReader). When a user comes to the page with a version of the Flash plug-in installed that is older than the version required for the eReader application, error-handling code kicks in to manage the entire experience of upgrading the plug-in version and viewing the content.

The alternate Flash content helps users get started with the upgrade process.

First, the page detects the version of the Flash plug-in installed in the user's browser. If an old version is found, in place of the eReader application an alternate Flash (.swf) file is loaded that prompts the user to upgrade the plug-in. If the user proceeds with the installation, her browser is reopened automatically (in some browsers) to the same page once the installation is complete and she is shown the eReader application. If the user cancels the installation or it fails for some reason, the alternate Flash content offers links to other areas of the site so she can move on, as well as a way to retry the installation.

If no Flash plug-in is present (or the version of the plug-in is old enough that the alternate .swf file won't display), alternate content is shown that lets her know what went wrong, tells her how to get the plug-in (along with an image of the content she would be seeing if the plug-in was installed so she knows what she's missing), and offers links to other areas of the site in case she doesn't want to bother with the installation.

When JavaScript is disabled, users are offered a link to the blog and a note asking them to enable JavaScript.

If JavaScript, which is required to run the version detection scripts, is disabled in the user's browser, she is told that JavaScript is required for the page, and is asked to enable scripting in her browser and refresh the page.

Of course, if nothing goes wrong, the user sees the Web Commandments in all their glory and never knows about all the processes that took place to ensure the content would be shown.

Finally, the About the Web Commandments link, which hides and shows (via a toggle function) an area of the page used to display the description of the document currently loaded into the eReader application, appears only if the eReader application is displayed correctly. If alternate content is being shown, the link is never created. This little magic trick is achieved with the combined use of Flash and JavaScript. The eReader application itself checks the loaded XML file (which contains the text and image references for the Web Commandments content) for a description element. If the description is found, it is parsed by the eReader application and passed to a JavaScript in the page.

JavaScript enabled? Check. Correct version of the Flash plug-in? Check. Show the content!

The About the Web Commandments link doesn't show up unless the Web Commandments show up first.

The JavaScript, in turn, dynamically writes the HTML it needs to display the description and the About the Web Commandments link.

The JavaScript is a poka-yoke device. Without it, if no description was found in the XML file, the link would show and hide an area of the page that was void of content, thereby making the link appear broken. With the JavaScript, users never see a broken link.

The Flash detection procedures that run on the Web Commandments page detect potential issues and offer appropriate error messages that try to get the user back on track. They also prevent a much worse error from occurring by displaying the alternate content. Without this, some users would see a blank, white box (meaning a Flash plug-in is installed, but is too old to display the content) or a rather poorly designed browser prompt that tells the user the plug-in is missing and offers a way to install it. Yes, the browser prompt offers a way to install the plug-in, but at the time of this writing, the dialog box displayed by Internet Explorer to start the installation is labeled "Security Warning." This is not something you want to your users to see. Remember, error pages and messages should help the user move forward. Security warnings are not the way to go.

Feeling smart

Detecting errors and guiding users to deal with them immediately is much less aggravating than waiting until they click a Submit button or make a mistake. At that point, it's far too late because the user already has an expectation that the next thing she sees will be whatever comes next in the process. If she is shown a registration form a second time, this time with errors, her expectation will be broken and she may lose confidence in her ability to complete the form correctly the second time. If she searches for something that has no results and sees an error, she can lose confidence in her ability to search well within that particular search engine. If she loses confidence in herself, she's much more prone to stop using your application. Inline validation and other methods of implementing poka-yoke help ensure errors are dealt with before the user's confidence is diminished. Our goal is to make her feel smart. Smart enough to use our application. If we help her feel smart, she'll like us a whole lot more.

Whenever possible, errors should be prevented instead of detected. The code required to perform inline validation is not always easy to create, but it's far better for the user than tossing up JavaScript alerts and the like after the user has been given hope that things will go smoothly. Displaying errors after this point is, well, too little too late. If the errors cannot be prevented from ever occurring, applications should at least be courteous enough to detect them as they occur so the user always knows exactly what's going on and can remain productive. The application should also make a decent attempt to get the user back on track by spinning the error message as an opportunity rather than an error.