Sensible Forms: A Form Usability Checklist
by Brian Crescimanno
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
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.
Jacob Nielsen provides these guidelines for use of checkboxes versus radio buttons:



Radio buttons are used when there is a list of two or more options that are
mutually exclusive and the user must select exactly one choice. In other words,
clicking a non-selected radio button will deselect whatever other button was
previously selected in the list.
Checkboxes are used when there are lists of options and the user may select any
number of choices, including zero, one, or several. In other words, each
checkbox is independent of all other checkboxes in the list, so checking one box
doesn’t uncheck the others.
A stand-alone checkbox is used for a single option that the user can turn on or
off.
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:


Is this a piece of information that is valuable to us?
Is this a piece of information that is so valuable that it’s worth denying users
access to (whatever lies beyond the form) if they do not choose to provide it?
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
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
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:


“There was an error in our credit-card processing system. Your card has not
been charged. Please try again later or contact us directly at…”
“There was an error processing your credit card; we were unable to verify your
card number. Please check your name, credit card number, and card expiration
date for correctness. Remember, these must match the card exactly.”
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
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.