Sensible Forms: A Form Usability Checklist

Computers are supposed to make our lives easier, not more difficult. As usability-conscious designers, we can make our users’ lives easier by thinking about the way people interact with our websites, providing clear direction, and then putting the burden of sorting out the details in the hands of the computers—not the users.

It’s that last part that we’re going to focus on here. We’ve all heard and read about big usability mistakes time and time again: “Don’t use images or Flash for navigation,” “Don’t use JavaScript for links,” and I certainly hope we’re all applying those lessons in our work. It’s often the smallest usability quirks, however, that create the biggest annoyances for users, especially when it comes to HTML forms. Follow these guidelines, and you’ll be off to a good start.

Use the right field for the task#section2

With so many form elements to choose from, each with distinct advantages and disadvantages, it can be difficult to decide which elements to use in a given situation. Use radio buttons, checkboxes, and select boxes appropriately: for radio buttons or checkboxes, use the fieldset and legend tags to group the elements logically under an obvious heading. This grouping keeps the form manageable to users, as it can be broken down into smaller pieces in their minds.

Jakob Nielsen provides these guidelines for use of checkboxes versus radio buttons:

For fields in which a single selection is required and there are a large number of possible options, consider using a drop-down select box to conserve screen real estate. The barrier between what makes sense as radio buttons and select boxes is somewhat of a gray area and will depend on context. If you wind up with five or more radio buttons, it may be time to move up to a select box.

If the field allows for multiple selections, try your best to avoid using the so-called “multi-select” box. This form element is at best confusing to users and at worst, it makes the form useless to those who do not immediately understand its functionality. If the number of options is so great that it becomes a giant blur represented as checkboxes, consider consolidating some of your options or categorizing them hierarchically to make them easier to understand.

Give them room to type#section3

Equally important to making the right decision on the field type is specifying the right field length. Just because your name is Joe Tod doesn’t mean other users won’t need more space to enter their names. Provide at least 20 characters for each of the first and last name fields. Additionally, don’t make the physical size of the input box cover less area than the expected entry. For text areas, make sure to give the user sufficient room to enter and read their text. Very tall, very thin columns are as difficult to read as a very wide, very short horizontal text area. The exact values will vary depending on their use but we can establish some minimums of 50 characters wide by 10 lines tall to ensure readability.

Shorten your forms and question “mandatory” fields#section4

To make your form as concise as possible, I recommend a two-step evaluation of every element of the form. To begin, ask yourself the following questions about each form element:

One of the most obvious examples of a form element that fails the first test is the salutation. It usually provides us no real benefit to collect this information, so why are we making a user give it to us? Don’t waste users’ time by asking them to provide useless information.

The second test (“should we require this field?”) is a bit more subjective. One example is the telephone number. There are many instances in which a telephone number would be nice to have. However, it’s usually not required to continue the transaction. Put the choice back into the users’ hands.

Mark mandatory fields clearly#section5

Some fields must be filled in to complete the transaction: if you’re selling a physical good, you’ll obviously need a shipping address. As with error messaging, give users visual cues as to which fields are required. Many times, form authors use bold or italic text to signify which fields are required and expect the user to make this association. There are several more explicit options which you can use to draw attention to required form elements. You can use an asterisk, “required” in parentheses following the field, or we can divide the form into two sections: required and optional information. In any case, if you are using any type of symbol or highlighting to denote fields which are required, you need to provide an easily findable legend which notifies the user of the symbol’s meaning.

I advise against using the color red to denote required fields, because red most often indicates an error or warning. As I’ll soon discuss, you should provide strong visual cues to indicate errors, so pick a color that will not be confused with error messages.

Provide descriptive labels for all of your fields#section6

What good is a form field without knowing what you are supposed to enter into the field? Employ the label tag to ensure accessibility is maintained for all users. Also, make sure your labels are descriptive enough that users do not question what is expected in that field. Field names should be clear and concise. If additional information would be helpful, XHTML 1.1 provides the caption tag to add a descriptive caption and provide proper accessibility. For the less adventurous, you can always create small caption text using traditional XHTML 1.0 markup and CSS.

Let the computer, not the user, handle information formatting#section7

Few things confuse users as often as requiring that users provide information in a specific format. Format requirements for information like telephone number fields are particularly common. There are many ways these numbers can be represented:

• (800) 555-1212
• 800-555-1212
• 800.555.1212
• 800 555 1212

Ultimately, the format we likely need is the one that only contains numbers:

• 8005551212

There are three ways to handle this. The first method tells the user that a specific format of input is required and returns them to the form with an error message if they fail to heed this instruction.

The second method is to split the telephone number input into three fields. This method presents the user with two possible striking usability hurdles to overcome. First, the user might try to type the numbers in all at once and get stuck because they’ve just typed their entire telephone number into a box which only accepts three digits. The “ingenious” solution to this problem was to use JavaScript to automatically shift the focus to the next field when the digit limit is achieved. Has anyone else here made a typo in one of these types of forms and gone through the ridiculous process of trying to return focus to what Javascript sees as a completed field? Raise your hands; don’t be shy! Yes, I see all of you.

Be reasonable; are we so afraid of regular expressions that we can’t strip extraneous characters from a single input field? Let the users type their telephone numbers in whatever they please. We can use a little quick programming to filter out what we don’t need.

Use informative error messages#section8

When I began work on this article, I spoke with my mother, a reasonably “average” home user, about the topic. The issue of form errors was the first thing she spoke, or rather, ranted about. When she tried to order a Christmas present from a website recently, she filled out the form and clicked the “order” button. She was then returned to the form with the words “Credit Card Error” in bold, red text across the top of her screen. Confused, she searched through the form to find any indication of where the problem had occurred. Finding none, she searched again to find the credit card input field. She checked the numbers and the expiration date. She even checked the spelling of her name, but each time she submitted the form, the same error message was displayed.

As it turned out, the problem was that the merchant’s credit card processing system was down. Nothing she could have done with the form would have made any difference. Returning a user to this situation just makes them feel ignorant, and I suspect we can all agree that insulting users is not in our best interests.

There are several steps we can take to better handle errors in HTML forms. First, and most importantly, we can provide more informative messages. Replace cryptic messages such as “Credit Card Error,” with context-sensitive messages:

These error messages are complete and tell the user what has happened. These messages also direct users towards possible resolutions rather than just telling them what went wrong and expecting them to devise their own solution.

The next step we can take to avoid confusing errors is to provide some visual cues as to where the problem lies; don’t leave your users to hunt down the problem areas themselves. With a little CSS, you can modify the original form in a variety of ways so that the user can easily identify the elements which need to be corrected. You can also use CSS to hide the fields that are already filled in correctly and only display those which need to be corrected. We can do this for groups of fields (such as the information required for credit-card validation) by using the fieldset tag.

Don’t return users to an altered form#section9

How many times have you entered your information into a form and clicked the submit button only to find that you left a required element unfilled? If you’re anything like me, I’m guessing it happens more than once in a while. While it might just be the price I pay for skimming the form and trying to get through it as quickly as possible, I shouldn’t be returned to an altered form if I make a mistake.

When I submitted my data, I had checked the box which said I agreed to the terms of service. I had also filled in my password. And, if I recall correctly, I definitely unchecked those boxes that said “Sign my e-mail address up for as many mailing lists as possible.” So why is it that so many times I get a half-completed form back?

This example is really a combination of developer laziness and overzealous marketing techniques. (Though the password un-fill may be a legitimate security precaution.) To the marketing departments out there: remember that marketing is about satisfying customer needs. If a user’s need is to not receive your solicitations, you should respect that need instead of trying to trick people into something they’ve already told you they don’t want. And to developers, make sure you’re populating every form element that the user has already submitted. There’s no reason they should have to re-accept the terms of your agreement or enter their information a second time because of a small typo.

Remember, the more control users have over their experience, the happier they will be using your website.