Checkout Usability: Auto-Detect ‘City’ and ‘State’ Inputs Based on the User’s Postal Code (60% of Sites Don’t)

Typing information in form fields is generally one of users’ least favorite parts of online shopping. While we can’t avoid requiring some information from users during the checkout flow, we should seize every opportunity to minimize the amount of typing required. One such opportunity is to auto-detect both “City” and “State” (or “Region”) based on the ZIP / postal code the user has typed.

In most countries the ZIP / postal code contains enough information to automatically set the “City” name and the “State” / “Region” input – this presents a great opportunity for making the checkout typing flow simpler. In fact during our past 7 years of large-scale checkout usability testing we see that there are two key benefits to auto-detecting city and state, based on the user’s ZIP code:

1. It reduces typing by 40% for a common shipping address.
2. It eliminates typos in the city name and saves users from having to fiddle with long state/region drop-downs.

Despite the significant benefits, our checkout benchmarking reveals that 60% of sites do not auto-detect city and state based on the user’s typed ZIP code. Furthermore, our testing reveals that for sites that do auto-detect, there are 4 UX implementation details to be mindful of.

In this article we’ll therefore present the test findings from our checkout usability study that relate to ZIP code auto-detection, including:

• The benefits of auto-detection observed during testing the past 7 years
• How auto-detection impacts the sequence of the address form fields
• Whether “City” and “State” fields can be hidden entirely
• Why a fallback solution is always needed
• Why the auto-detection should kick in with the last digit

Note: for simplicity we’ll use the terminology “ZIP” and “State” throughout this article – the solution however applies equally to most other western countries that use “Postal Code” and “Region.” At the end of the article we’ll also address the internationalization aspect.

Why Sites Should Auto-Detect “City” and “State” (60% Don’t)

Ever since we first usability tested city and state auto-detection features in 2009, we’ve observed that users have generally been very positively surprised whenever a site auto-detects the city and state input based on the ZIP code they’ve typed. This is actually not that surprising once you look at how much typing it saves the user – for a common shipping address, ZIP-based auto-detection will yield a 40% reduction in the amount of typing:

• 5 fields: Name, Address Line 1, City, State, ZIP, vs.
• 3 fields: Name, Address Line 1, ZIP

Besides speeding up the completion of the form, auto-detection also has the potential to bring delight to users in an otherwise dull typing process. When first running usability tests of ZIP code auto-detection in 2009, it was purely observed to be a “delight” parameter for users – but over the years, as users more frequently encounter such features on e-commerce sites in general, their general expectations have increased. Following the Kano model, what delights users today will be seen as a “standard” feature in the near future, and at some point even disappoint users when absent – a general UX degradation phenomenon explained further in our article UX and the “Kano Model”.

Besides minimizing the amount of typing, auto-detection also means that users avoid typos and misspellings, particularly for the “City” input. During testing, typos and misspellings were quite common when subjects were tasked with typing information into text form fields – for example, a city name – either because they couldn’t spell the word or, just as common, due to simple typos. This resulted in a number of address validation errors, which could have been avoided with auto-detection, as fewer user input fields means fewer opportunities for the user to mistype. (For sites that do not perform full address validation, auto-detection will instead mean fewer potential delivery issues.)

In fact, during our latest study on checkout usability, 30% of the test subjects, across all tested sites, experienced issues that could have been avoided with a ZIP code auto-detection, e.g. difficulty locating the state in the drop-down or typos in the city name input.

Despite these highly tangible benefits, only 40% of large US e-commerce sites employ auto-detection based on the user’s ZIP code, meaning that 60% of e-commerce sites have a competitive disadvantage by not utilizing this powerful auto-detection feature. A feature that a few leading e-commerce sites have now had for nearly a decade. (We’ve tracked Apple’s checkout to have auto-detection since, at least, early 2009.)

For sites that are about to implement “City” and “State” auto-detection – or already have it – we’ve observed 4 implementation details to get right in order to achieve a good UX performance:

1: Have “City” and “State” Appear Beneath the “ZIP Code” Field

Presenting “City” and “State” beneath the “ZIP code” field will initially break the traditional address field sequence, at least for US users where the conventional printed address information sequence is “Name, Address Line(s), City, State, ZIP.” However, the downside of an unconventional field sequence proved negligible during testing (of US address forms), compared to the gains in completion speed, user delight, and reduced typos.

However, one word of caution: having city and state fields expand above the ZIP field, to simulate a normal address sequence, is ill-advised. We generally observe that users have severe issues noticing when new fields are added above the trigger area (in this case the ZIP code field), as it breaks the downwards-focused reading and typing flow used in all western countries.

2: Can “City” and “State” Fields be Hidden Entirely?

The test sessions did not provide any definitive answers on whether it is best to hide or display the city and state fields by default. The safe choice is to permanently display city and state fields since users will expect these fields to be present in an address form. Hence, in this design, the auto-detection simply pre-fills the existing state and city fields, once the ZIP code has been entered.

It is however also an option to hide the city and state fields entirely until a ZIP code is provided. Hiding the city and state fields has the benefit of presenting users with fewer form fields in the default view – making for a less intimidating appearance of the form (see “The Average Checkout Flow Has 14.88 Form Fields – Twice as Many as Necessary”). Hiding the fields does however come at the expense of a slightly less recognizable form upfront, and, hence, is mainly recommended for sites with a slightly more web-savvy audience. Hiding the fields will also always require that the site provides a short message informing users that they have to “Enter ZIP for City & State.”

3: Always Have a Fallback for Auto-Detection

While auto-detection of city and state will initially help the vast majority of users, it isn’t flawless and will occasionally fail, either due to technical issues, or because the database isn’t 100% updated at any given point in time – something that must be expected for short duration, such as when a new city names is added or updated, ZIP codes are expanded, etc. Even though this will only be an issue for a small number of users, these can however be expected to have a near 100% abandonment rate if there’s no fallback option, since they are otherwise forced to submit an incorrect address.

A fallback for the auto-detected city and state values is therefore always needed, allowing users to manually override the auto-detected values. In fact, when conducting a checkout audit for a mid-sized e-commerce client, we witnessed the lack of a fallback solution to be the sole cause for a negative A/B split-testing outcome of auto-detection versus no auto-detection. While we’ve found a fallback to be critical, we have not observed any performance differences in how the fallback is implemented (drop-down, open text fields, edit link, etc.).

4: Why Auto-Detection Should Kick In at the Last Digit

During our eye-tracking tests of checkout flows, we observed that users expect to get immediate feedback when typing information into form fields. Users generally do not click out of a form field just to see if anything happens, and mainly click to the next field when they shift their focus towards that next input.

This user behavior clashes with sites where the city and state auto-detection features require that users leave the field before any change is registered. On such sites we observe that a sub-group of users will start to doubt why nothing happens, while others even overlook that there’s auto-detection available, and some think they have to save or apply their information, etc. At the very least, auto-detection that only kicks in when users leave the field, will frequently cause an interruption if users have progressed and started to interact with the next field in the form – only to then be interrupted by auto-updating information suddenly appearing.

Put more directly, the auto-detection should not just kick in when the ZIP code field loses focus – i.e., don’t just rely on an onblur event. Instead, the auto-detection should kick in the moment the user has typed enough characters to make a meaningful detection. For instance, for a US ZIP code the auto-detection should kick in as soon as users have typed their 5th digit.

(Note how this is the exact same user behavior and form logic required for avoiding outdated error messages when using inline form validation.)

Venturing Into City and State Auto-Detection

During our past 7 years of checkout usability testing we’ve observed ZIP-based auto-detection of the user’s city and state to speed up form completion times, eliminate numerous misspellings and typos, and generally cause user delight. Clearly, this represents a great opportunity to improve the user experience – yet sadly, a staggering 60% of the largest US e-commerce sites still fail to take advantage of it.

Furthermore, during our usability test studies of mobile e-commerce sites, the UX benefits of auto-detection proved even more important than for desktop checkout flows. Mainly as typing out the city name and selecting a state in a massive drop-down is much more taxing and error-prone on the small mobile screen than it is in a desktop checkout context.

If you already have auto-detection of city and state, or plan on venturing into it, make sure to pay attention to the following implementation details:

1. Users must always be provided with a fallback option to override the auto-detected values (as the auto-detection will occasionally inaccurate).
2. Auto-detection should kick in immediately after users have entered the last digit in their ZIP or postal code (and not just when they leave the ZIP code field).
3. The “City” and “State” fields should be shown (or injected) below the “ZIP Code” field – even though it’s an unconventional address sequence.

In terms of implementation, the two most common approaches to auto-detection are either using a 3rd-party vendor, or acquiring a postal database for your key markets and then setting up the detection logic yourself. The latter option means less external dependency but will typically require a larger initial investment and more ongoing maintenance. Regardless of which route you go, it is strongly recommended to treat this as a progressive enhancement so that JS bugs, ZIP-code database downtime, etc., don’t result in a broken checkout.

For sites that sell to more than one country, supporting auto-detection for cities and regions based on the user’s postal code can be complex, and for sites that sell internationally it is often unrealistic to support every single country shipped to. Indeed in some countries postal code are infrequently used, hence all users don’t even commonly know their own ZIP code – e.g. China and select Eastern European countries. Auto-detection should instead be seen as an enhancement of the typing experience that can be applied for the site’s key markets – where it is justifiable to spend the necessary resources required for a robust implementation and ongoing maintenance.

This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” cart and checkout user experience.