Redesigning The Country Selector


The country selector. It’s there when you create an account for a new Web service, check out of an e-commerce store or sign up for a conference. The normal design? A drop-down list with all of the available countries.

Typical country selector1

However, when conducting a large session of user testing on check-out usability (which we wrote about2 here on Smashing Magazine back in April 2011), we consistently found usability issues with the massive country selector drop-downs. Jakob Nielsen reported similar issues as far back as 20003 and 20074 when testing drop-downs with a large number of options, such as state and country lists.

So, this past summer we set out to redesign the country selector. This article focuses on the four design iterations we went through before arriving at the solution (free jQuery plugin included).

First, let’s take a closer look at the usability problems of traditional drop-down country selectors.

The Usability Issues

Drop-downs cause usability issues when used for country and state selectors for several reasons. Here are six:

  1. Lack of overview
    Seeing more than 20 uncategorized options can be bewildering, and country drop-downs often offer hundreds of options (according to ISO 3166, there are 249 countries).
  2. Unclear sorting
    When shown a massive list, the first thing users do is figure out the sorting logic. But because country drop-downs often include the three to five most popular options at the top, the sorting logic is unclear at first glance.
  3. Scrolling Issues
    Multiple problems are related to scrolling large drop-downs. If your mouse cursor is outside of the drop-down, you will most likely scroll down the entire page, hiding the drop-down options from the screen. In other browsers, however, the drop-down will actually scroll as long as it has focus, likely leaving you with erroneous data.
  4. Inconsistent UI
    The UI of drop-downs differs from browser to browser and OS to OS. The drop-down will not only look different, but will also work differently. For example, on a Mac, Safari forces you to hover on two arrows to scroll up and down, whereas Firefox provides a traditional scrollbar. Now grab your smartphone, and suddenly the UI has dramatically changed again.
  5. Lack of context
    Mobile devices have very limited screen real estate, which means you have less page context when scrolling, and actually finding the option you’re looking for takes longer.
  6. Breaking the flow
    Nearly all users — even those who otherwise tab through forms — will use the mouse when interacting with a drop-down, thus slowing their progress.

It All Adds Up

These usability issues are all minor interruptions that don’t occur every single time someone interacts with a drop-down country selector. But they all add up, and together with other minor usability issues on your website, they will degrade the overall user experience — ultimately leading to abandonments.

With this in mind, we set out to redesign the standard drop-down country selector. Below are the four design iterations we went through.

Iteration 1: Typing Vs. Scrolling

The easiest way to get rid of the hundreds of options and the issues related to scrolling is to simply replace the drop-down with a text field — letting the user type their country. This works only if the user knows what to type, because there would be no recognition effect (this would never work for shipping options because the user would have to guess the names of the options). But a country selector is a good candidate for a text field because it is fair to assume that every user knows the country they reside in.

Okay, so we’ve got a text field. While good for usability, it’s bad for the courier who has to deliver a product. The drop-down offered a limited number of options, whereas the text field offers infinite (the user can type whatever they want). In order to restrict the input to values (i.e. countries) that our back-end system can handle, the text field needs to auto-complete and accept a restricted set of options. This will enable us to 100% accurately map the text-field input to the countries that our back-end system (and courier) recognize.

Google Auto-complete5
Today, most Web users are familiar with auto-complete functionality. Google has used it for its search field since 2008 (and as an experimental feature since 20046).

Iteration 2: Typos And Sequencing

By replacing the drop-down with an auto-complete text field, we’ve introduced a new problem. While the user can be expected to know the name of their own country, they can’t be expected to know what our back end calls it. If the user lives in the US and makes an omission, such as “nited states,” or decides to type only part of the name, such as “America” (instead of “United States of America”), then no correct results would appear:

Apple Email Subscription7
Apple8’s country auto-complete field requires you to spell the name 100% correctly and in the right sequence.

This is because a typical auto-complete field will be looking for values that are not only spelled correctly, but typed in the right sequence.

Numerous Web services — and especially e-commerce stores — are geographically restricted, and international users are well aware of this. Even big websites such as Amazon, Hulu and Spotify have serious geographical limitations on some or all of their services. While someone from the US will probably expect their country to be supported, an international user who cannot find their country might abandon your website before detecting their typo.

In short, the country selector has to account for omissions and sequencing. We achieve this by simply enabling loose partial matching:

Iteration 3: When The Netherlands Isn’t Called “The Netherlands”

We’ve now taken care of typos and sequencing, but there’s yet another problem. Some country names have multiple widely accepted spellings; for example, the Netherlands is sometimes referred to as Holland. Geographically, they are the same, but the average person would say that they vacationed in “Holland,”9 whereas the Dutch themselves would typically spell it “Nederland.”

When we require the user to type a country name, we must consider all common spellings. This includes synonyms, local spellings, common abbreviations and country codes. A typical auto-complete (and drop-down as well) would fail when charged with all of these spellings, such as mapping USA to United States, or Schweiz, Suisse, Svizzera and Svizra to Switzerland, or DE to Germany.

From a usability point of view, this is unacceptable because these are common spellings, and people will often type them into auto-complete fields.

In our redesigned country selector, we’ve added the possibility to map multiple words to a given value:

Iteration 4: When “United States” Is More Common Than “United Arab Emirates”

Typing “United” into the auto-complete country selector on Apple’s website gives you the following list:

This list is simply sorted alphabetically. But because we don’t have to scroll through a long list anymore, there’s little reason to sort the list alphabetically. A more natural sorting order would be by popularity. Apple might want to prioritize United States, followed by United Kingdom and United Arab Emirates. Whereas a British newspaper may want to put United Kingdom first.

To accommodate for this, all values (countries) could be given a weight. By default, all would be equal, and then each website could then apply their own weighting for their most popular countries:

Solution: The Redesigned Country Selector

The solution is a redesigned country selector that addresses the issues of drop-down country selectors. It handles typos, various spelling sequences, synonyms and prioritized options.

The technically correct term for this would be something like an “auto-complete text field with loose partial matching, synonyms and weighted results.” That’s a bit long, so I’ve simply dubbed it the “Redesigned Country Selector” — you can try the demo here10.

For those of you who own or work on a website with a country selector, I’ve decided to open-source the code. It is a simple jQuery plugin for the progressive enhancement of drop-down menus (i.e. your current country drop-down), turning them into advanced auto-complete fields in modern browsers. It comes with instructions and an FAQ11.

Update: As many commenters have noted, the sorting logic on the original demo wasn’t all that “logical.” We have now changed it so the first letters of the country name are ranked higher (e.g. typing “Ca” now returns “Canada” at the top instead of “American Samoa,” and “In” returns “India” instead of “United States,” and so on) as many of you have suggested. Thanks for the feedback – you can follow the project on GitHub12 to be notified about future improvements.



  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12

↑ Back to top Tweet itShare on Facebook

Christian Holst is co-founder of Baymard Institute where he writes bi-weekly articles on web usability and e-commerce optimization. He's also the author of the E-Commerce Checkout Usability and Mobile E-Commerce Usability research reports.

  1. 1

    J. B. Rainsberger

    May 9, 2012 5:29 am

    Beautiful work. I’m a nut, so if you matched on Olympic country codes (ex. KSA = Saudi Arabia) and initials (PRK = North Korea) and even internet domains (.is = Iceland), that would make me happy beyond belief.

  2. 102

    great idea and greatly done. I was looking for best possible solution of this problem and I think its here.

  3. 203

    It’s a fuzzy weighted autocomplete. So what? It’s 400% more complex than an abc-sorted select/option.

    The problem though is not the complexitiy, but the lack of specification; as we can see from the comments, everyone wants something different added or modified – and wherever I worked noone ever took the time (product owner, architect, ux designer) to detail the workings of such a small component (I know it’s “my” problem per se, but bear with me).

    So I usually end up building these things by myself the way I find it good (mostly according to articles like this one) and everyone is happy. A week later when the QA team gets to testing the page, they will come up with all the comments you can read here, but IN JIRA TICKETS.

    And complexity grows. Reestimation starts. Velocity is being decreased. And then I’m asked, why is this country selector so complex? This is the true story why these “intelligent controls” are so rare.

  4. 304

    Great work, nice article.

    I like auto-complete a lot, but with one annoyance: in my observation & testing, in the Android browser, the keyboard overlaps the auto-complete list, and in fact covers all but the first few items in the list. It is possible to scroll the page up, but I do not think that is obvious enough for everybody.

    I am experimenting with a few approaches toward choosing from a long list, such as US states or world countries, targeting all of mouse/keyboard & trackpad & touchscreen, using one same/single form – the URL is:

    (Also discussed at: )

  5. 405

    About the difference between The Netherlands and Holland.
    Most used in pull downs is Netherlands. It is almost a standaard. Holland is less used in our country.


  6. 506

    I love this country dropdown, and I’m very grateful you made it open source, too. :)

    I have one question: what is the best way to set a default value on pageload? We have access to user data via 1) cookies, 2) language defaults, and 3) country via IP, so I’d like the page to load with a default country selected.

  7. 607

    ??$##%?? “…A more natural sorting order would be by popularity. Apple might want to prioritize United States…”
    Natural?? What are you talking about? What does ‘natural’ mean for you? I would expect a country list sorted alphabetically. Even more in the case where you filter with auto-suggest. If a list of 5 countries is showing up, it might be sorted alphabetically.

  8. 708

    A nice feature would be to give a message if you enter something like Kosovo.

  9. 809

    Hmm, what do you do if the country of a user is not included for the service?
    For example, one does not ship to the Netherlands.

    I see a couple of solutions:
    – Any variation of The Netherlands does not yield any result. (bad experience, user might feel they are not typing their country correctly and will try all variations: Netherlands, The netherlands, The Netherlands, Holland, etc)

    – Allow the user to select the country and then give feedback on the choice that the country is not available. (probably best, however because the user was able to select the country it feels like a positive/succesful choice, feedback might be overlooked)

    – Directly show feedback upon detection of a country that is unavailable. So user starts typing ‘Nether’ and the system directly gives feedback near field: ‘The Netherlands is unavailable for this service because blabla’ (maybe best solution of 3 above?)

  10. 910

    Holland is a region in The Netherlands. Of course, all the interesting stuff in The Netherlands is in Holland…

  11. 1011

    Great article, have learned a lot from it.

  12. 1112

    Drop down is technically easier to implement than this, incredibly involved, system.
    So why not just improve the drop-down with:

    1. Only display countries that you actually serve. A lot of web services are not global, vast majority of merchant sites don’t ship world-wide.

    2. Sort by most common use on your site. Ship more often to United Kingdom than United States? Sort by that instead of alphabetically.

  13. 1213

    Cassius Krendler

    May 4, 2014 11:33 am

    Quite frankly, the arrogant method of putting “USA” or “United States of America” on top of those country forms is beginning to piss me off big time. It’s typical, but sad.
    Same goes for phone formats always dictating the USA default format, some not even allowing an international dialling code to be added.
    Not to mention the fact that – by default – a US state needs to be picked, sometimes even regardless of which country was originally selected.

  14. 1314

    Very useful…

  15. 1415

    Very good suggestions and clear explanations, thank you. I can see that this approach works well for commercial web forms. Do you have any research or approach about internal tools (e.g. the post office software) where the users would be less likely to type in “Holland”. Do you think the same implementation would bring the same added value? Or a different approach sh/could be adopted?


  16. 1516

    Really love this solution – but wondering if there’s any plans to update it?

    Newer versions of Jquery & Jquery UI have problems with it.

    Otherwise does anyone know of a decent alternative?


  17. 1617

    In your update at the end, you mention that in the new version ” …“In” returns “India” instead of “United States,” and so on) as many of you have suggested.” ”
    I think you meant “United Kingdom”.
    I like the article and should have found it sooner.


↑ Back to top