Skip to Main Content

Jul 16, 2012 | 6 minute read

3 Often Overlooked Checkout Usability Guidelines

written by Linda Bustos

There are obvious checkout issues to tackle, like required registration, competing calls to action, bloated forms, poor error handling messages and slow page load speeds throughout checkout. But we can’t forget the seeming little things that are just as common and can cause as much frustration, or worse, address errors that result in misdelivered goods.

These tips are excerpted from the 2011 E-commerce Checkout Usability Report published by the Baymard Institute, which conducted lab user tests on the top 15 online retailers' checkout flows.

1. Preserve all customer input despite errors in the form

Issue: customers feel frustrated when information they just provided (like password or newsletter checkbox) is ‘forgotten’ because there’s an error somewhere else in the form.

This is rule number one when dealing with form errors: remember the customer’s data despite errors in the form. In the few cases where a site didn’t do this, it was of great annoyance to the test subjects, one even abandoning the purchase altogether.

An example of how scared customers are of getting error messages. Here a test subject fills in “N/A” whenever he is in doubt about a field being optional or not.

A test subject makes a typo in one field and gets an error message. The subject corrects the error and submits the page once again, only to get a new error message because the site cleared the two password fields when the first error occurred.

Filling out forms is already a tedious process – having to fill out correct fields again because a server system is incapable of persisting the data on errors is unacceptable to most customers.

If your site only ‘forgets’ parts of the form, more specifically the newsletter-checkbox, these customers will feel deceived and tricked as they already indicated they didn’t want the newsletter.

One test subject stated such “deception” would make her leave the store unless this was the only place she could buy the product and it was really important (e.g. a special toy for her kid’s birthday).

Here a test subject unwillingly signs up for Levi’s newsletter because their system conveniently ‘forgot’
that this customer had already unchecked this checkbox before getting an error.

Guideline: always persist all form data despite errors in the form

2. Auto-detect city and state immediately after ZIP code is provided

Issue: customers inevitably end up misspelling fields if they have to write it themselves.

Customers don’t like filling out form fields. This cause many customers to rush through the fields and as a consequence, they often end up misspelling things like their city or state.

Misspelling city or state happened for more than half of the test subjects during testing. Sometimes it was discovered instantly before submitting the form, but on a number of occasions the subjects didn’t notice the misspelling and were presented with an error message by an address validator, or as it happened in a few cases the order was completed with an inaccurate address.

Since data such as state and city is in fact embedded in each ZIP code, you can fill out
these fields for your customers, making their shopping experience more pleasant and decreasing the number of misspelled cities and states in your orders.

More than half of the test subjects at one point misspelled either city or state. One way to avoid this is to fill out both city and state based on the provided ZIP code. A) Walmart doesn’t auto-detect city and state based on ZIP code, whereas B) Apple does – this saves their customers from the extra typing, simplifies their form by having one less field, and lowers the amount of misspellings.

If at all economically and technically possible, try to auto-detect your customer’s city and state immediately after they’ve entered their ZIP code. You should automatically start loading this information as soon as the customer has entered his ZIP code and not only after he has left the field. Also, you should not use a separate ‘Apply’ button

Half of the test subjects flat out complained about it missing on the sites that didn’t offer this feature, and one test subject had a hard time understanding how Walmart could correct the street name he provided (using an address validator) yet they were unable to automatically pre-fill his state and city fields based on the provided ZIP code.

When implementing auto-detection be aware of the following:

  • Sometimes a ZIP code is applicable to a region or multiple cities, in these cases you add the relevant city suggestions to your city field and have the customer pick the correct one.
  • If your customer has already provided a ZIP code in an earlier step, e.g. in a shipping calculator, automatically pre-fill the ZIP code in the current step.
  • You shouldn’t omit the city or state field from your form since people expect them to be there. You should just pre-fill them with the correct data after the ZIP code has been entered.
  • No system is perfect and ZIP codes do change, so always allow the customer to manually change the state and city you’ve chosen, for the rare cases where the system is wrong.

Guideline: auto-detect the customer’s city (or at least possible cities) and state after they’ve entered their ZIP code.

3. Only use drop-down lists when there are less than 20 options

Issue: massive drop-down lists are difficult to scan and can very easily overwhelm customers.

Customers easily get overwhelmed when faced with massive dropdown lists. We had cases where test subjects flat out forgot which way to scroll in an alphabetical list.

Another problem with long drop-down lists is that they are difficult to scan. First, you click the drop-down to even see the options, then you get a list that you’ll likely have to scroll through, typically using a poor UI (depends on OS and browser).

Huge drop-down lists were scanned slowly and navigated with difficulty by the test subjects.

So whenever you have 20+ options consider other ways of presenting the data. Can you use an autocomplete enabled text field instead? This will still ensure that the provided data is valid, yet people won’t have to scroll through a huge list of options. In such case you should however also support synonyms being typed for each option, so if there is ever any doubt of how to spell a word or what to call a concept, you support all common interpretations.

Mockup of a country selector using autocomplete.

Note: a problem with autocomplete-fields is of course that the customer has to know what he is looking for. So only use this as an alternative if the customer knows exactly what he is looking for (a country field is a good candidate since everyone knows the name of their own country).

If you can’t find other ways of presenting these options, then at least make sure your
drop-down list has good sorting and popular matches. Let’s say you have a country-list, then be sure to sort it alphabetically so people can scan the first character of each option instead of reading the entire word. Also, consider duplicating the 5-10 most popular countries and putting them at the top of the list so they are easier to find (but be sure to also have the match in the complete list, so if your customer by habit scrolls down the list, she will still be able to find ‘United States’ under ‘U’).

Tip: We’ve created a (free) script that turns any drop-down list into an advanced auto-complete field. You can find it at:www.baymard.com/labs/country-selector

Guideline: keep drop-down lists to no more than 20 options and think carefully about sorting. If the list gets bigger, consider alternative options (such as an autocomplete) or at the very least include the most popular options at the top of the list.

For more checkout tips (including the major ones), check out Baymard Institute’s ecommerce usability blog and Get Elastic checkout optimization posts. The full 2011 E-commerce Checkout Usability Report can be purchased from the Baymard Institute.