jim.shamlin.com

Defensive Design for the Web

This is a book-length manuscript, but is classified here as an "article" because contains very little information and copious illistrations.

1: Understanding Defensive Design

Introduces the concept of defensive design: planning for contingencies where things do not go as planned: errors, no search results, out-of-stock items, etc.

Failure to plan for contingences cause users to give up and bail out, or to become frustrated with the experience. Ideally, a site should help the user back on track.

2: Show the Problem

A "good" error message lets a customer instantly know that an error occurred, what the nature of the error is, and how to recover.

Give an error message that's noticeable at a glance. Seems straightforward, but some sites don't - a search yields no matches, clicking a link loads a blank template, the user is abruptly returned to the home page on error, a form re-loads with no indication of what was wrong with the data the user originally entered.

Use colors, icons, and text to clearly highlight and explain the problem. Simply stated, the message should be obvious to the user: use bold red text rather than the standard body font and color.

Always identify errors the same way. As with anything else, if you are consistent, the user will become familiar with the method of notification. If you're inconsistent, the user will be confused each time a new error is reported differently.

Eliminate the need for back-and-forth clicking. Give the user a method of addressing the problem without having to use the back button to return to the form. Also, when possible, preserve any data previously entered rather than making the user re-enter it.

Also, identify errors all at once rather than one at a time, making the user go back repeatedly to correct each field.

3: Language Matters

Use language the user can understand. Computers throw codes and technical jargon left and right to inform programmers of problems in specific detail. The customer doesn't' need it, can't understand it, and is generally frustrated by it.

Keep it brief: suggested format is to lead with a headline, offer bullet points rather than text blocks, use bold test to highlight critical information, and edit for brevity without sacrificing comprehensibility.

Be polite. While it might in fact be the user's fault that an error occurred, they don't need to hear that. Specifically, don't take an accusatory tone toward an already frustrated user. Kid gloves.

4: Bulletproof Forms

Forms where users enter data are identified as a particular area of concern. Specific advice:

By design, require as little information as needed - long or overly inquisitive forms cause users to bail.

Highlight required or optional fields. Use asterisks, the word "required" or "optional", or bold text to indicate which fields must be completed.

Accept entries in all common formats. Different sites may 'require" data in a certain format. Wherever possible, accept any format and do the clean-up using JavaScript or server-side regular expressions.

Provide samples and hints. Where it is not possible to accept formats due to variations in input, provide users an example of the desired format. Alternately, constrain choices by using select lists to prevent users from making mistakes.

Explicitly state limits. If text is constrained to a specific number of characters or a multi-select to a maximum number of items, tell the user. Programmatic methods of preventing the user from providing too much data (maxlength) may be used, but the user should still be explicitly told (won't have to guess or experiment to find out).

Don't show what should be hidden - if there is only one option, there's no need to make the user select it. If an item is not valid, don't' show it (this may require the user to go through a process of entries if the availability of one option is based on another selection).

Validate input asap. Especially in sequences, identifying an error at the end that could have been corrected earlier (and making the user go back a few screens) is bad. The current preference is to use JavaScript to evaluate input, return an error message right away, and disable the submit button until the problem is addressed.

Buttons are a problem in some cases - user clicks reset or cancel instead of submit and hoses all their input, clicks submit multiple times, etc. The advice is to remove the reset/clear option and disable the submit after it has been clicked (possibly give the user a 'processing" message if there's a long wait).

Save information. For lengthy processes, save the user's input in case of browser crash (so they don't have to re-enter everything later)

5: Missing items

Offer customized 404 errors. Ideally, offer the user more than just an indication that the item is not there ... give them advice as to how to find it.

Redirect near-miss URLs. Consider typos, case sensitivity, abbreviations, and other predictable errors and redirect users seamlessly to the correct location. This includes not only path and file, but also URL (what if someone types four "w"s?)

Use ALT tags for images. That's good general advice, but especially important when images are more than decorative, but have functionality in JS-enabled interfaces.

Offer alternate pages for older browsers. Redundancy is good, to provide users access to basic functionality without the whiz-bang features that people with bleeding-edge software have. Worst case scenario, identify and trap the error, and give the user a clear indication of what they need to do (install) in order to be able to access the site.

6: Providing Help that Is Actually helpful

Answer questions in context rather than making the user click away to a separate page. "Help" with an on-screen pop-up is a good technique. Answering questions on-screen can also be done.

Offer a help section. An on-screen link to "help" in a consistent location should lead to a well-developed help section. If the help content is significant, organize it into chapters/sections and make it searchable.

Provide online utilities for self-service. Community features, such as message boards or chat rooms, help users support one another. An online help-desk blog can enable a user to find an answer without having to call.

Provide alternate help: in addition to on-screen help, consider chat, phone, or e-mail for customers who are still stuck. Respond to these inquiries promptly, politely, and in language the user can understand.

Login screens are a particular problem area: users may forget their password, or type it incorrectly. Offer links to find a lost password, or consider a "three strikes" approach (three mistakes, and it's sent via e-mail automatically).

7: Get Out of the way

Don't disable the back button. Don't do it on purpose, and be aware of places it may happen unintentionally (like auto-forwards). If the back button will cause an error, and it will be inevitable, provide a link to the previous step and make sure the error is trapped gracefully.

When errors are encountered, provide straightforward messages and avoid excessive design elements. Avoid unnecessary clutter, and don't' get cute.

Don't force registration. It's a bad idea in general, even worse when a user is asking for help.

Don't block content with ads. This is another idea that's good general advice, but all the more important when it comes to error screens or choke points in the site.

Eliminate unnecessary navigation during multi-step processes. Since your intention is for the user to go through the screens sequentially, links to other pages are not needed. Removing them will keep the user on track until the sequence is completed (and the re-appearance at the end will underscore the fact that the user is done with the sequence).

8: Smart Search Engine Assistance

Search engines are another problematic feature that's often more frustrating than helpful. Here are some tips:

Offer a clear explanation when there are no matches. Especially, don't go to a standard results screen with "zero matches"

Anticipate common errors. In addition to catching typos, consider synonyms, singular-plural, punctuation, case-sensitivity, hypenation, abbreviations, spelling errors, and language variations. Sing search logs (terms entered and results found) can help identify common problems.

Enable users to filter long lists of results. Too many search results means the user still ahs to find what he's looking for among a vast number of items. Allow the user to sort the results, or search within results, or list results by category, or otherwise trip down a long list.

Enable users to expand criteria for too few results. Explain the reason the user might have found no matches, and provide hints to enable them to better find what they're looking for.

Don't rely on advanced searches. Even sophisticated users generally type a word or two and tap "enter." Boolean logic, enabling the user to select specific criteria. Etc., may be helpful to some, but excessive features can intimidate users. Also, sue of these features should be optional - don't force the user to select a category.

9: Out of Stock

In shopping sites, its' not uncommon for items requested to be out of stock. Some of these principles may also apply to non-commerce sites (missing press release, content page, etc.)

Be up-front about availability. Don't let them be surprised about an item being out of stock after placing their entire order. Where possible, integrate with inventory and provide a clear notice. If you wish to list items that are currently out of stock, place them at the end of search results.

Provide information about backorders. If an item is temporarily out of stock, indicate as much, and provide an estimated date when it will be back in stock. Ideally, the item can be ordered to be shipped when it's in, rather than forcing the user to return later and place a separate order.

Offer e-mail notification. If an item is backordered, do not force customers to return on their own and check for it to have come in. Allow them to request an e-mail notification.

Show similar items. Simply stated, if the item the customer wants is not in stock, they may be willing to order a similar item that you have in inventory. Facilitate this.

10: The Contingency Design Test

Most user testing provides a script to guide them through the process without encountering errors. Some give users a task to perform and allow errors to happen accidentally. A better approach is to try to break things by compelling users to do things that are wrong and seeing if they can recover.

The authors provided a long list of things to test or consider - preserved the list (below), but the explanation for each is redundant to the material covered in the notes above.

Forms

• What happens if a required field is left blank?
• Can mistakes be corrected without having to navigate backward?
• Is it clear which fields are required vs. optional?
• Can the user format information such as credit card or phone numbers in various ways?
• Can select objects be used to avoid input errors?
• Is it clear to the user what he must enter in each field?
• Are character limits for text fields indicated?
• What happens if the user enters too much data in any field?
• For multiple selects, is the number of required entries indicated? Is it trapped programmatically?
• Are options that are invalid due to previously entered data still displayed?
• Are e-mail addresses, phone numbers, etc. entered as valid data
• Do the state and Zip code (also, area code or whatnot) a valid match?
• If the submit button is clicked more than once, what happens?
• Is a reset or clear button provided? Is it needed?
• Si it possible to save one's progress and return later? Is this done automatically?
• Does using the "back" button cause a breakdown in a multi-step process?
• Are links and navigation elements that would cause the user to exit a multi-step process eliminated for the duration of the process?

URLS

• Is there an effective 404 error message?
• How does the user recover from a 404 without using the back button?
• If an URL is entered that is slightly wrong, is the user automatically redirected?

Help

• Is it easy to find answers in the help section>
Is it easy to find answers in the help section>
• Are self-help options provided (online tutorial or discussion board)?
• Are other help options (phone and e-mail) provided)?
• When a message is sent to a help e-mail, is the response prompt?

Login

• If the user makes an error logging in, is assistance provided?
• Is it clear and simple to request a lost username or password?
• If the user attempts to create an account with a username that is already taken, how is this handled?

Searches

• is the rationale for search results explained?
• When zero matches are retrieved, is this handled elegantly?
• Can the search engine gracefully detect and correct typos, misspellings, and such?
• When many results are returned, can the user filter them further? Is the user advised to better conduct their search?
• When few results are returned, can the user expand the search? Is the user advised to better conduct their search?
• Is the default search a simple one, or does it require the user to make a lot of sophisticated selections?

Unavailable items

• At what point can a user tell that an item is not available?
• Is it clear whether the item is discontinued or simply temporarily unavailable?
• Are details about unavailable items accessible at all?
• If the item si currently out of stock, is a reorder date provided?
• Can the user pre-order items that are currently out of stock?
• Can the customer request an e-mail notification when the item is available again?
• Does the site provide similar items as alternatives to one that is unavailable?

Conclusion

Some additional ways to identify opportunities for defensive design:

• Site statistics identify where users drop. Use custom logs fopr search engines and shopping carts to identify their specific problems. Statistics about use of help and FAQ sections is especially important.
• Customer support inquiries indicate weak points. If you're not recording these and examining the data regularly, you ought to be
• Solicit feedback so users can tell you directly - soliciting feedback in places where users are most likely to have problems (error screens, search results, etc.) is especially valuable.
• Getting a second opinion from other developers or firms can identify things the in-house guys are missing. It may be necessary to pay for expert help/reviews, but it's worthwhile.
• Assign someone the ongoing task of proactively seeking out problems. Give them the responsibility to keep on top of it, the resources they need to do so, and the authority to get corrections implemented.
• Keep a list (database) of common issues and errors
• Proactively apply these standards as part of a testing procedure separate from usability