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.
Use the right field for the task
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
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
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
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
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
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
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
Ultimately, the format we likely need is the one that only contains numbers:
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.
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
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
Don’t return users to an altered form
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.