Deciding when to use a drop-down — or when to use another interface type, such as a radio button interface or open text field — for a specific input can be tricky.
In e-commerce, most users will encounter drop-down menu inputs while navigating the checkout flow, for a wide variety of inputs.
However, our large-scale usability testing reveals that using drop-down menus for the “wrong” input types can lead to slower checkout completion times, field validation errors, and unnecessary user attention being devoted to optional fields, all of which increase the likelihood of checkout abandonments.
The issues caused by drop-downs being used for the “wrong” inputs were observed during our very first rounds of checkout usability testing dating back to 2010. Since then we’ve reconfirmed this user behavior during all subsequent checkout usability testing we’ve performed, including our most recent Cart & Checkout usability study.
In this article, we’ll discuss the test findings from our Cart & Checkout testing related to deciding when to use drop-downs, including:
Note: though specific numbers are used to illustrate “too many” and “too few” options in a drop-down, it’s important not to get hung up on what exact number of options in a drop-down should trigger using an alternative input interface. The number of options used in this article are for general guidance only — each site and input type has an individual context that should be taken into consideration. Furthermore, all these findings apply for e-commerce checkout flows; other contexts, like survey forms and application software, may deviate.
Drop-downs quickly become difficult for users when they are presented with an overwhelming number of options to choose from.
Take, for instance, a commonly included input in checkout forms, the “Country Selection” drop-down. 47% of sites in our benchmark include a country-selector drop-down in their checkout.
Testing revealed 3 main issues caused by massive drop-down inputs such as the “Country Selection” drop-down:
On the other hand, if there’s just a handful of options for a particular input, a drop-down will similarly nearly always be a poor interface choice because the space savings are small compared to the amount of friction created by not providing users with sufficient information scent — users must click the drop-down to see the 1–4 values it contains.
Furthermore, when the input is optional, 55% of users across our testing were observed to open a drop-down, just to see what it contained, and then immediately close it again without changing the input. This occurred even when the drop-downs were clearly marked as being optional.
Therefore, drop-downs with many options, and drop-downs with only a handful, are both suboptimal interface choices, as they are intimidating and hard to navigate, or introduce unnecessary friction into the checkout process by hiding information that could simply have been exposed.
If, for a particular input, there are many more than 10 options, but the input doesn’t have to be validated, an open text form field will often be simpler than a drop-down, as users don’t have to read and understand all options before making a choice.
For example, a “Full Name” field is a very flexible way of supporting optional “Title” and “Suffix” fields (inputs often wrongly displayed in a drop-down). Similarly, an optional text field for delivery instructions will often be simpler than an optional drop-down.
For some fields, such as the “Country Selection” field, where the input often does have to be validated, we observe that a well-performing alternative to a drop-down is an autocomplete field.
This addresses the issues of drop-down selectors by letting the user begin to type their country themselves. As they begin typing, the possible matches are suggested, which simplifies the task of locating and selecting a value, and is observed to greatly speed up the country-selection process altogether.
(For those who are interested in exploring autocomplete country selectors further, we’ve developed an open source jQuery plugin that turns a standard drop-down into an advanced auto-complete field. To try a demo or get the code see Redesigning the Country Selector.)
For drop-downs with few options, a radio button interface will often be a better choice, as it doesn’t require users to open it just to scan how many options they have and to see what each of those options are.
A note on checkboxes: checkboxes are good when users have to choose between opting in or opting out (a single yes/no option), and when the majority of users should pay close attention to this choice. Common examples include newsletter opt-in, up-sell opt-ins (insurance, subscriptions, etc.), and for choosing “shipping address = billing address”. Thus, it’s often better to go with open text form fields or radio buttons when addressing the issue of drop-downs with too-many or too-few options.
There are three checkout inputs (not including “Country” or “Title”, discussed above) that our benchmark reveals are often implemented as drop-downs in the checkout, when there is in fact a better alternative.
Shipping Address, “State” Field. The importance of “State” field drop-downs can be reduced by implementing zip code autodetection, which will allow the vast majority of users to skip interacting with the “State” field altogether. Yet, we’ve found that only 33% of sites have ZIP code autodetection for “State” and other similar region inputs.
Shipping Method Selection. During testing, drop-downs for shipping selectors were often overlooked entirely, not perceived as important, suffered from a lack information scent in the collapsed state, and rarely had sufficient information hierarchy. Instead, a radio button design is a better choice. (Happily, only 4% of e-commerce sites use a drop-down for the shipping method selection.)
Payment, “Card Type” Field. Based on the first digits of the credit card number, it’s possible to determine the card type, hence it’s needless friction to ask users to select their card type themselves. Instead, the card type should be autodetected from the IIN range. Yet, our benchmark reveals that 23% of sites use a “Card Type” drop-down.
Note: one type of drop-down input where it’s acceptable (even preferable) to use a drop-down, even though there are many more than 10 options, are numerical inputs (e.g., expiration date fields and product quantity fields). In testing we observe users interacting with these drop-down inputs don’t have the same usability issues as users interacting with text-based drop-down inputs.
Our testing reveals that, in general, opting for an open text field or radio button interface instead of drop-downs with many or few options (respectively) is a better choice.
That’s not to say that drop-downs should never be used in these contexts, especially when there are many options to choose from. If there are many more than 10 options, and the optional input either has to be submitted in a known and structured format for validation and analysis, or where users don’t know their options upfront (hence, can’t type it), a drop-down can be a completely warranted choice.
It’s important to consider the specific site and field context when making a decision on whether to use a drop-down interface. However, it’s safe to say that drop-downs that have many options, or very few, warrant extra scrutiny to determine if it’s really the best interface choice.
In the majority of cases — like inputs for “Title”, “Country”, “State” or “Region”, “Shipping Method Selection”, and “Card Type” — it’s likely that there’s a better alternative to drop-downs with many or few options that will help users move more quickly with less friction through checkout and other processes that require user input (e.g., online return flows).
This article presents the research findings from just 1 of the 850+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” cart and checkout user experience.
Join 22,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 agree that huge drop-down lists can be a nightmare… don’t get me started on country lists organised by continent… but if you were to use client-side auto-complete there’s a chance the user will ignore it and type in the country name themselves, increasing the chance of typos. How do we get around that?
I think the big list of countries could be overcome by informing the use they can start typing the name of their country as most any modern browser supports this. Also, from a programmatic standpoint, you could try to auto-detect their location and have your best guess selected for them.
I agree with Mr Leo. If it were just a text field with autocomplete what do you do if the user types jargon? Ultimately you are choosing from a predefined a list so what you’re really doing is searching or filtering. I’m sure it could be overcome, but there’s definitely a bit more experimentation needed.
One other reason drop downs are used instead of radio buttons is that it’s easier to have no selection.
@tom_r @MR Leo, just check if the string exists in database.
Sarah Allen and I wrote an article “Should I use a dropdown?” that goes into this dicussion in more detail. We talk about the benefits of radio buttons compared to dropdowns compared to checkboxes compared to fill-in boxes.
Although it’s a few years old, I think the discussion still works today.
Gerry Gaffney and I included a revised version of the material as chapter 5 in our book “Forms that work: Designing web forms for usability” www.formsthatwork.com
One way of solving the excessive number of countries problem is to offer a much shorter list of the countries that are typically chosen by the top 80% of your customers, and then offer an ‘other’ selection with a place to type in the name of the country.
This also has the advantage that country names aren’t quite as stable as you might think: countries change quite often, and the names of countries are a matter of political dispute. For example, the “former Yugoslav Republic of Macedonia” has been admitted to the United Nations under that name because of a dispute about the name “Republic of Macedonia”.
There are also some smaller geographical areas where the question of which ‘country’ they are is somewhat complicated. For example, Isle of Man is geographically placed between the islands of Great Britain and Ireland; it is self-governing; citizens are British Citizens but the Isle of Man is NOT part of the European Union; it is a British Crown Dependency and many practical matters are such as defense and diplomacy are dealt with by the British government on its behalf.
I’ve gone into all this detail because it also helps to think WHY you want the information, such as country. Is it purely for postal purposes? For some other reason? Depending on why you want it, you might ask in a different way.
Caroline, I am reading the dropdown.pdf in 2017 & its still so relevant. Thanks !
Thanks a bunch for your comments!
As panaghia also points out, back-end validation will solve this (and you really should always do back-end validation if 100% correct data is important to your business).
You should include jargon in your country synonyms. And of course, if correct data is crucial to your business, you should of course validate the data in your back-end. Finally, you could just design your auto-complete in such a way that it doesn’t allow entering non-matches.
“One other reason drop downs are used instead of radio buttons is that it’s easier to have no selection.”
I’m not exactly sure what you mean by this. If you write “Blank” or “No selection” or whatever as an option in the drop-down menu, I don’t see why you can’t add this option to a group of radio buttons..?
This is actually one of the guidelines of a usability study we’re currently conducting. Using geo-targeting to automatically select a smart default country is a great way to get around the hassle of selecting a country – whether it be through a regular drop-down field or an auto-complete enabled text field.
I guess your solution with the most popular countries and then an extra text field would solve a lot of political issues. Of course, if you need exact matches for postal reasons, having it all validated against a back-end makes sense. And of course if the data is stored in your back-end for validation, it can also be used in the front-end. But all of this is once again only necessary if absolutely “correct” country names are important to your business.
Another common approach is to put the top 10 countries at the top of the drop-down list so they are available right from the beginning even if they start with a ‘U’ (e.g. United States). It’s important to make this a duplicate, though, as people may overlook this and then get confused that they can’t find United States under ‘U’.
“synonyms and abbreviations so you can map ‘US’, ‘America’, ‘United States’”
I think you need to read up a bit on geography. Last time I checked, America was divided into two areas: North America and South America. And USA, US or United States or United States of America is in North America :-)
ALL the countries in North- And South America are inside America.
So people from Cuba, Honduras, Chile, Jamaica, Brazil, Argentina, Venezuela, Bolivia, Canada and Mexico are all americans :-) However, they are not from USA.
Traditional mistakes (USA = America) can not dictate how things should be listed in a website or computer programme.
@Traveller. I can see the original post is a bit unclear on this (no harm intended), which is why Jamie tried to make it a bit more precise in the first comment by saying “you’d want to map multiple countries to ‘America’”.
As such Cuba, Honduras, Chile, Jamaica, Brazil, Argentina, Venezuela, Bolivia, Canada and Mexico should also be mapped to ‘america’ as well.
I have corrected the original post to avoid any further misunderstandings. Thanks for pointing it out.
“Traditional mistakes (USA = America) can not dictate how things should be listed in a website or computer programme.”
While I certainly appreciate the difference between these two geographic areas, I think if it is a common mistake, then you’d definitely want to display allow for it to be used. At the end of the day, design is about meaning.
If people think of US (or Cuba, Chile, etc.) as ‘America’, then all of these should be displayed, as long as you show the one “correct” version as the result. (So when the user types ‘America’, the auto-complete shows ‘United States of America’, ‘Cuba’, ‘Chile’, etc.)
If scrolling down a long list of dropdown items is “slow and painful” then clearly whoever wrote that software didn’t think properly about how to implement long dropdown boxes. In all windows applications, the dropdown list has a proper scrollbar that you can just grab and throw to whatever position you want. I notice on the mac this is more often not the case (something I’ve always found rather odd actually, dropdown boxes seem to adhere to the same idiom as menus from the menu bar for some reason) – Firefox does seem to have a more sensible implementation which uses proper scrollbars when necessary though, even on the mac.
What software did you use for the usability study you did? Was it just Safari, or was it a combination of different implementations like in Firefox vs. Safari? That would be quite interesting to see, whether there was any difference between the two.
It’s true that the Mac’s default implementation of drop downs is awkward. However, we tested this in Firefox so (as you mention) the scrollbar was there.
The slow and painful experience was due to the small, confined space the user had to scroll within, not because the scrolling in and by itself was different from normal scrolling behavior. In the drop down, the user had to scroll 100+ options positioned closely to one another within an area that was approximately 150px wide and 500px tall.
Present that much information in a list with that small boundaries and you end up with a poor user experience which is slow and painful. Since this is how any drop down will present that much information – Windows or Mac, IE or Safari – I believe our conclusions are applicable to drop downs in general.
That the Mac’s default implementation of drop downs lacks the scrollbar just make the experience even more cumbersome I would imagine, although we haven’t tested this so I can only speculate based on my own experience with drop downs in Chrome on the Mac.
Is it easier on a mobile device to use the select list vs radio buttons?
While the auto-complete text input is an OK solution – what if the predefined options are not easily guessed? And what about cases of multiple selections?
Sometimes a large drop-down list that you can BROWSE, not search/filter, is appropriate.
In extensive drop down lists like country and state entries, you can often type the first letter or two letters quickly with the list opened to find your selection more quickly. Just some insight (which I realize is awkwardly explained to most consumers… “Do what now?”
on your mobile device get the hand-crank option for those large lists!
It depends on the mobile device you’re using – specifically screen size and browser and default OS drop-down list design. How you design the labels of the radio buttons will obviously have an impact on this too.
If you have 7 or less radio buttons I’d imagine it would be easier but our study was conducted on traditional computer, not a mobile device, so I can’t say for sure.
As mentioned in the post, the auto-complete solution is only relevant in those scenarios where the user already know the options in advance (such as the name of their own country).
Regarding multiple selections, this is supported by many modern auto-complete plugins.
“Sometimes a large drop-down list that you can BROWSE, not search/filter, is appropriate.”
Agreed! This is also mentioned in the post. Drop-down lists can be great as long as you use them correctly.
Exactly. We told this tip to a few of our test subjects after the test and almost all of them asked us to show it to them because they didn’t get what we were talking about.
Good ideas, really makes one think. Thanks for the guidelines!
client side auto complete is a good idea, but you can skip this whole step if you do an ip lookup and prefill the form field.
I think screen real estate is also a factor while deciding to go for drop down or radio button.
Good article, but important for readers to keep perspective. Not every case will be the same, and I think typically the country selector is a slightly bad example.
Two other important considerations here between Radio buttons and drop-down lists are information hiding, and space constraints.
Radio buttons can often display too much information, even when fewer than 7 choices are available. I find (based on very informal research, so no guarantees here!) drop down boxes work much better than radio buttons in cases where both a) a default option is available, and b) alternate choices are very similar or confusing.
The other consideration is space. Sometimes it may be beneficial to have areas of a form visible, and a radio set may push these further apart.
Simple things, and common sense to some degree, but a lot of people forget.
Radio buttons aren’t so good for viewing information. This:Sex: [Female ∇]
May be quicker and easier to skim than this:Sex: Ο Male Θ Female
(Please excuse my Unicode art.)
A current project of mine features dropdown menus for everything, including yes/no questions. Initially I thought this was just ridiculous — that’s what checkboxes are for! — but now I see its use. When information is edited once or twice but read many times, the dropdown has the advantage of hiding all unused options. This follows on from Keith’s comment above — there’s no chance of misreading the answer.
My first impression after reading this article was: why 7?
My opinion is that making the choice between a dropdown and radio buttons depends on several factors:
Length of the form: Users are scared of the length of some forms.
Possible answers: You don’t want 2 lines of text in your dropdown menu.
Possible answers: Obvious answers can be in a dropdown. Like a country selection. But if the answer need more attention do it in radio buttons.
Just a few factors that are case dependent.
Yes, using geo-targeting to auto-select the right country is actually another guideline in our report. Although it’s not always possible for small sites due to the required investment in an IP-database (and upkeep of keeping the database up-to-date).
Very true. In fact, there’s only two reasons to use a drop-down instead of radio buttons: 1) to save space (as you also point out), and 2) to hide data and only display it when relevant.
Thanks for your thoughtful input Keith, and you’re absolutely right. Our article is meant as a guideline, not a strict rule. As with any other design decision, you should always take the context into consideration.
Saving space and hiding data until it’s relevant are the two reasons to use drop-downs as opposed to radio button, so if any of those two attributes are important to your design, you should obviously feel free to break this guideline – as long as you know why you’re doing it.
If you do use forms for viewing data, this is a great insight. However, in most cases I’d use a separate view for reading information, simply because you have so limited design control over form fields, so designing the optimal reading platform will only be possible by having a separate view. In cases where you mostly read but also need to be able to quickly edit incorrect input and/or resource constraints force you to use form fields for viewing data, in those scenarios this definitely holds true and will be a valuable design insight.
True – context should always trump guidelines.
As long as you have a good reason for breaking a guideline and know why you’re doing this, then by all means, go ahead. This goes for all design guidelines.
Regarding “why 7”, we do state at the very end of the article that you shouldn’t get too hung up on the specific numbers, but rather use them as “guidelines, not strict rules”.
@JT just a quick note that Apple specify that a pop up menu (drop down list) shouldn’t contain more than 12 items, otherwise it should be implemented as a list box, which obviously does have a scroll bar. Mac drop downs that have too many options, are that way because the developer didn’t conform to Apple’s guidelines, not because drop downs are badly implemented.
Nice, but how would a screen reader like JAWS handle this?
I had this exact issue except it was with suburbs loading up in a drop down select box.
It wasn’t actually the ability to find the suburb that was annoying, it was the time it took to load the drop down select box! Even with caching it was unsatisfactory.
Then imagine having 3 drop down select boxes on one page all which load suburbs!!
I ended up going with a type in box that uses Ajax to return matching suburbs as the result.
Very thoughtful idea. I really appreciate your effects. I have read few comments about the ip config, without selecting the country select. I am working a ecommer website which we have more than 200 countries. Suppose if US user enters different country and try to order a product from our site, the ip config wont work, thought they still clear the cookies it shows only ip selected country. which this solution wont work? Just a thought.
I really appreciate this article, especially when it’s tied together with your Country Selector redesign. Little things like drop down lists for 3 options (or 100) make the web a less friendly place to use, compound that by registering/purchasing/sending/etc dozens of things on dozens of different websites makes it that much more frustrating.
I took the time to consider all the user actions in a recent project and found that dropdown menus were quite a clumsy user experience.
I’ve never had a problem with country selection lists because in all of the ones I’ve used, you can simply type out the country name and it will take you to it in the list.
Normally I just type the first few letters and was moved to that part of the list. I would agree that without this functionality, this would be very problematic.
I am wondering what would be the veredict on having a multi-select list with the “default” option of “* No Selection *” (that is, the “no selection” is actually one of the options available to pick).
I ask because often we need to give the user a way to “unselect” or reset the selection on a multi-select list and I believe it is better than having a separate “Clear” button.
What are your thoughts on this?
Just based my checkout process on this post. It better work ;)
Let me know how it works out for you.
What would be your suggestion for a Date Of Birth entry on mobile? The year dropdown which is usually used is going to be 100+ options long. Is a text entry field a better user experience in that instance?
It is also important to think of the ‘Please select’ label in drop-downs and how that relates to other input methods…
How about this as a list of guidelines:
Use a checkbox when there is a binary choice, on/off, enabled/disabled, etc
Use radio buttons when there are two or more mutually exclusive choices and you have an intentional preselected or default value
Drop-downs when you have more than two items, but less than 15 (for sake of argument), where none are preselected/default.
Series of drop-downs where there are more than 15 items, i.e. continents/countries, manufacturer/model, etc.
Text field with auto-complete if more than 15 items (the user must obviously know what they are looking for in this case)
“Sometimes a large drop-down list that you can BROWSE, not search/filter, is appropriate.”
Follow-up to the comment above:
For the use case were users do “not” know or is not familiar with the options in a drop down list;
what is a recommended approach for using a drop down list for a very long list of options? One that is a required field,in a data entry form used by Admins for data entry.
Are there example links of recommendations?
@UX O2 we are struggling with the long list issue. We are currently designing a mobile application for smart phones. On particularly long lists that a user is required to select, We are thinking of displaying the top 15 items based on usage (data in the database for the last couple of months). At the bottom of that list display “other” with all the remaining options.
I love the way in which the three cases for drop-down lists are framed:) Thank you:)
I really didn’t know the advantages/disadvantages of radio button and drop down list till the time I read this article. I guess I stumbled upon great content.
On desktops and mobile devices with physical keyboards (not too sure about iOS though), you can always press an alphabetical key and you can scroll faster for each word. This of course finds the first letter of each word. I think a combination of what you said a auto-complete with the dropdown would be better. That way you don’t lose this functionality for a power user.
Pablo – not every site or program allows the user to filter by typing the first few characters. The ones that do are quite helpful.
Also, IP lookup isn’t always helpful – I’ve worked in more than one company where the IP lookup had Google Maps and Amazon and MSN showing me results for Houston, TX when my local area was Sleep Backwater, Arkansas. (Note: That’s not a real town name in Arkansas, it’s a description of the very rural area in which I lived and worked.)
No mention or discussion of whether to order chronologically or by perceived relevance? For example, a product list of 14 products…
Website design is not my world, and no one will see this comment five years after the article was written, but reading it was extremely satisfying. State drop-down lists are ubiquitous, and when I las checked there were more than 15 US states. In fact there are almost 15 Canadian provinces, and lately I’ve been seeing Mexican states or Australian states or territories or lands, or whatever they’re officially called, depending on focus of the site. Then there’s every island or atoll where the Navy can anchor a ship or the Army or Air Force can land a helicopter or build a PX. The state pull-down is often the only one on a site, leading me to wonder whether there is some sort of great-great-grandfathered reason it can’t be removed. There are about 200 countries on this planet. What will the list become when it includes every state, province, prefecture, department, county, municipality, territory and whatever from every country? Maybe they’ll have to have two pull-downs, on with a million foreign administrative subdivisions, and the other with just the good old 50 states of the US of A. An oblast from the past.
Just about to design a website and this is making me rethink the interface. I was planning on drop-down entry for darts match entry but radio button mixed with drop-downs would be more-user friendly.
No one seems to explain why we must use dropdown lists of state names when ordering online. What is the point?
I am reading this in 2020 & I can’t believe we are still not using any of the principles in our design. I just shared this with my team & told them to print it & use it whenever we are designing forms, This is the must-follow guide. Thank you so much for sharing your finding.
Thank you from an experienced programmer who is a rank beginner at UX/UI. I came to this article via a Google search for “How to multi-select from 100+ choices” and a feeling that a dropdown was the wrong widget. I had preliminarily decided to use 100 buttons arranged like tiles, each with the name of one choice. They would change color when selected. Two pros with this were:
1) The user could see the whole set of choices and which ones had been chosen;
2) I know as I work on this project that the number of choices will increase each year by maybe 1-3 choices. This form can easily accommodate that;
Another constraint (advantage) is that the user will be using a desktop monitor, not a phone or a watch, etc. So I know that I have real estate for this choice.
Is my choice good? Alternatives?
© 2021 Baymard Institute US: +1 (415) 315-9567 EU: +45 3696 9567 firstname.lastname@example.org