Before you decide to use a select menu for a field ask yourself a question. Will users know their input without looking at the list of options? If the answer is yes, do not use a select menu for it. Instead, use an autocomplete field.
It’s unnecessary for users to scan and scroll through a long list of options if they already know their input. Select menus force users to do this extra work which frustrates them and slows them down. It’s even worse for them on mobile where only a small part of the list is visible and keyboard search is not available.
An autocomplete field is better because it saves users time and effort when they’re selecting known input. The user only needs to type the first few characters of their input before they see it appear as an option. They can then press the down arrow key and to select it from the menu.
Instead selecting from a large amount of options, they’re selecting from a minimal amount of options. The more they type the less options appear, making it even quicker to find and select their option. The number of options displayed to the user is reduced, which also reduces the error rate.
This usability violation of select menus is often found on fields involving time or place input. Country and state fields are big culprits as well as day and month fields. Users know their input for these fields and shouldn’t have to waste time scanning irrelevant options.
Make it quick and easy for users to fill out your form by using autocomplete fields instead of select menus for known input. It’s much like going to a familiar restaurant. If you already know what food you want to order, reading the menu is a waste time.
Book
Affiliate
So then on mobile, instead of a quick scroll and tap to select e.g. one’s state, one now has to find the correct letters on their mobile keyboard, and then select it from the smaller drop-down menu? That doesn’t sound easier…
How is scrolling through a longer list of options a “quick scroll”? How is swiping the menu wheel back and forth a “quick scroll”?
Hi Anthony,
I think this approach has two issues :
– You are assuming the user will know what is he looking which is not always the case. For instance, would you type United-Kingdom or England?
– Also, it can be hard for some people with disability to remember the first letters or the word they are looking for.
My suggestion is combining both. Provide a full list of options and allow the user to search in the list.
Best,
Charles
The united kingdom/england issue would occur on select menus as well. With autocomplete fields you can allow flexibility by parsing united kingdom and england as the same data value on the back-end.
Agree, the combination of the two would be a better UX. I can image a dropdown list would also be useful for a foreigner who is not familiar with all the different state.
I also favor auto-complete, but state names are an unfortunate example. Similar to Charles’ point, American users might enter “TX” rather than “Texas,” which means either the set of options in auto-complete has to accommodate likely variations, or the field needs unwieldy instructional text such as “Enter the two-letter abbreviation for your state or province.”
The width of the text field serves as visual cue for users to interpret which format they should enter. A smaller field would indicate abbreviation and a wider would indicate long form.
The state example is a very fortunate one. It is very easy to parse abbreviation to complete to full state name.
This might be shameless self-promotion but I ended up writing a JS script to do this thanks to this post:
https://github.com/shakyjake/Select-To-Autocomplete
It also accounts for the England/UK/Britain issue by providing an extra attribute to search in