Form Design: 11 Patterns For Accepting User Input

I’m often asked what are good books to read for ecommerce. If you’ve been trekking with us for a while, you know I occasionally review books I receive from publishers – so long as I believe they would be interesting for ecommerce buffs. I receive no other compensation than to keep the review copy of the book.

In lieu of writing a “this book is great because this this and this” review – I like to give Get Elastic readers a slice of the book’s content. Sometimes I post a section verbatim from the book (with publisher permission, of course), and other times I take a concept from the book and flesh out a post. Today, I take the latter approach.

The latest title I received is Designing Interfaces by Jenifer Tidwell. Though written for web developers, web designers and usability specialists, it helps for every ecommerce professional to know these patterns. Every web project will involve several of these patterns, and a decision has to be made which patterns to use and which to leave on the table. This book helps you understand what to use and when.

Because improving form design can help you increase conversion, I've taken the 11 patterns for accepting user input mentioned in Chapter 8 and have added some of my own examples from ecommerce sites.

Form Design: 11 Patterns For Accepting User Input

Forgiving Format

Forgiving format allows user to enter data that may have a variety of valid formats and syntax. Common examples are allowing a customer to log in with an email address or user name, or to search by keyword or catalog ID.

This pattern is especially helpful for inputs that are capitalized or hyphenated, or frequently misspelled.

Most importantly for ecommerce, this should be applied to credit card information, telephone numbers and zip/postal codes in checkout. Allow customers to enter them with or without spaces, with mixed case, etc. This requires smart programming that considers all the ways data can be entered, and how to properly interpret them.

Structured Format

Instead of one text field, this pattern uses a set of text fields that reflect the structure of the requested data. This works best when you require input in a specific format, which is well-defined and familiar to the user. An example is breaking up a telephone field into 3 chunks for the area code, the prefix and suffix.

Keep in mind that telephone inputs vary across countries – you may consider forgiving format if you sell internationally through one site.

Another application is for date fields that specify format, such as YYYY MM DD or DD MM YY.

Structured format is also helpful for software registration key input. Chunked keys and fields are easier than long strings of characters to enter without error and review.

Fill-In-The-Blanks

Allowing the user to "fill in the blanks” with fields arranged in the form of a sentence or phrase can, in some cases, have a tremendous impact on conversion. Testing by Vast.com showed this format converted 25-40% better than the old school form:

Ebay's advanced search also uses a fill-in-the-blanks approach.

Use this pattern when you can verbally describe the actions taken in an active voice sentence or phrase. Note that this is a difficult pattern to "localize" without giving thought to culture's influence on the order of the fields. For example, in Japan you may want to ask for the last name before the first, or you may need to arrange fields for grammatical reasons.

Input Hints

Input hints elaborate on what is required from a field and are placed beside or below the input box. This can help clarify ambiguous fields or fields you commonly find users making errors on.

Jenifer Tidwell recommends your input hint be 2 points smaller than your label font, and be as concise as possible.

Keep in mind input help can be overlooked, and are not a substitute for proper labelling.

Input Prompt

This pattern pre-fills a text field or drop down menu and tells the user what to do or type. This solves the danger that the user will overlook input help - it's put right where their eyes are focused.

In some cases, like the Apple Store, the prompt replaces the field label.

A mistake Apple originally made was the input prompt would disappear as soon as the user started typing, and not re-appear if the field was cleared to "start over." This has since been corrected on the Apple Store, but if you use this pattern, make sure you don't repeat the mistake.

Password Strength Meter

You've likely experienced a dynamic "password strength" meter when signing up for an email account or with a social network. Sites that require or highly recommend strong passwords should provide this real-time feedback, rather than letting the user hit "submit," reloading the page and then asking for a stronger password.

Twitter is a good example of password strength feedback. It uses color bars and strength indicators that range from too short to weak, good, strong and very strong, that appear as the user is typing.

Autocompletion

I've written about the virtues of autocompletion on Get Elastic before, (especially the rich kind, the pattern that suggests possible search terms as a user types. You should be familiar with this since the major search engines use this. It helps prevent typos and can help users hone in on more specific terms for better search success the first time.

Autocompletion is even more valuable on mobile devices, where input is more tedious.

Dropdown Chooser

Dropdown menus need no explanation, but note that they are most appropriate for fields where input can only be one in a set of options. For example, color, size, O/S or shipping option.

Also keep in mind, when only one option exists in a dropdown (due to other options selling out), consider a format where the user can see the single option without a menu. Or, if there are a small number of options, consider showing options as buttons that gray out when they become unavailable.

List Builder

The list builder pattern allows a user to configure something using "source" and "destination" lists. They are useful when users are required to select subsets of data. They may use "Add" and "Remove" buttons, or have a drag-and-drop functionality.

List builders are less common on ecommerce sites than in software applications, but you may find some using this functionality in product configurators, for example. You may also find them in bundling situations, where a accessories may be added to a product.

Good Defaults

Prefilled form fields with the "best guesses" at values the user wants are considered good defaults. A flight finder on Orbitz or Priceline that pre-selects the current date and economy travel is an example. Another is using geolocation to prefill a user's country in a checkout form.

Keep in mind that an incorrect guess could lead to an error, as usability experts have found users' eyes jump to empty fields (and they don't read instructions carefully). This is best employed when you're absolutely sure of the correct input - such as filling in city and country based on zip code.

Also, avoid defaulting sensitive information such as passwords, gender, age etc, and don't pre-check email opt-ins!

Same-Page Error Messages

When errors occur, error messages should appear on the same page of the form, rather than in modal dialog boxes.

The biggest problem with modal dialog boxes is the instructions disappear when you return to the form!

Great error handling places a message at the top of the page and proximal to the fields with the errors. Tidwell recommends to make the error messaging short, but detailed enough to explain the problem. Use ordinary language, not "computerese" ExamplesL "Is that a letter in your IP code?" vs. "Numeric validation error." And, "Sorry, but something went wrong! Please click GO again" vs. "Javascript Error 593" or "This form contains no data."

I say this also goes for ecommerce product pages - make sure you're making it very clear what the customer did wrong and where. For example, when a customer fails to select a size, use a pop-up callout pointing to the field.

Even better, prevent the customer from submitting an erroneous form by disabling the checkout button until all is configured, and reporting the error when the user hovers over the button.

In checkout forms, use inline validation to give instant feedback before the user hits submit.

Armed with this information, where can you improve form design patterns on your ecommerce site?

If you're interested in full book reviews of Designing Interfaces, you can find them on the O'Reilly website.