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:
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:
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.
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:
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.)
30% of test subjects experienced issues that would have been avoided with ZIP code auto-detection
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:
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.
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.”
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.).
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.)
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:
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.
Join 25,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
I think the accuracy of ZIP to City/State matching is overstated in this article. 42% of U.S. ZIP codes map to more than one city. While that number may be much lower if you have a primary city/state for each ZIP that the majority of people in a ZIP match to, it’s still a concern. A third-party service that looks up street address and ZIP might also improve accuracy significantly. But I’m not sure that exists and it has the concern of relying on a third party service for availability/speed.
While I see the obvious benefits of reducing typing and UI element interaction for the user, I wonder if the % of incorrect auto-detection events hurts conversion rates more than this article lets on. Is there A/B testing referenced that I missed showing that auto-detection improves conversion rates?
Hi Eric, good concerns. As David points out some sites use a city drop-down to display multiple matches. The way most sites deal with these city drop-downs (for presenting multiple values) and at the same time account for a safe fallback is always having an “Other” option in the drop-down which turns it into a open text form field. I’ve updated the article with an example of this from Apple – you can see it under section “3: Always Have a Fallback for Auto-Detection”.
Also note that while ZIPs often have multiple city names attached, several of the “secondary” names often aren’t preferred by the postal services. The ZIP code 75205 which Walmart and Apple in this articles detects to “Dallas, TX” also have “HIGHLAND PARK”, “UNIVERSITY PARK”, “VILLAGE” city names attatched, but USPS own ZIP lookup tool advise user against using these “secondary” cities as mailing addresses:
For your question on incorrect matches hurting conversions we do not observe this to be the case during testing – as long as a fallback is always available so users can override the auto-detection. For specific A/B testing: we can’t share client-data, “only” our large-scale usability test findings (those presented in this article).
I have seen Mr. Wilfong’s issue come up, but the form field became a drop-down, with the multiple cities listed. It seems like that option would work very well as long as
1. The options were listed in order of population
2. The drop-down defaulted to an open position where a selection was needed, making the options evident
I would worry in that scenario about an outdated database/service presenting the wrong options. With a straight dropdown there is no recourse for the user to correct and they will drop off if the options are incorrect. The safest tact seems to be pre-filling the “primary” city/state combo, but allowing the user to edit as necessary.
but what about a website that has an audience whose ZIP codes vary from 5 to 6 digits, not all 5 ! there will be too much frustration.
The zip-code auto-detection logic should be updated to only try for matches based on the country selected (the country value should generally, by default, be IP geo-targeted)
Have you tried anything to test this assumption Mahmoud?
Does zip-code auto-detection work for non-U.S. countries?
Hi Kerry, yes in most countries the postal code contains enough information to automatically set the “City” name and the “State” / “Region” input. From a resource perspective, I’d recommend you consider only supporting this in your key markets, so you can ensure a good integration here.
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 email@example.com