Implementing a custom designed drop-down selector is often a visually attractive alternative to using the browser’s native drop-down design. In a few select cases it can even lead to a more user friendly interface. However, it’s also a dangerous strategy. Our large-scale checkout usability testing and benchmarking reveal that while 82% of e-commerce sites use custom designed drop-downs in the checkout flow, 31% of all custom designed drop-downs have significant usability issues.
When developing custom designed drop-down interface, it’s very important that the many subtle features and capabilities from a native interface are built into the custom interface as well, as users have deeply rooted expectations about how fields and selection interfaces function. However, re-coding the native drop-down features in a robust way is challenging, even for the world’s very largest e-commerce sites — as you’ll see in the examples in this article.
In this article we’ll share our test findings from our checkout usability study that relates to custom designed drop-downs, such as:
In practice the many interaction nuances of a native drop-down aren’t supported in custom designed drop-downs.
Our benchmarking reveals that 31% of the custom designed drop-downs found in the checkout flows of the world’s 60 largest e-commerce sites, are suffering from at least one of the below 5 keyboard and interface issues. Note how all the examples of issues are from sites beyond $100+ million in online sales.
1) Users are unable to use the keyboard to tab into the custom drop-down selector. This breaks users’ tabbing flow in a longer form.
For example, at Foot Locker’s checkout flow (seen above), once users have progressed to paying, those 62% of users we find to regularly tab through a long form will not be able to do so, because the custom drop-down for selecting the payment method is not reachable by keyboard tabbing.
2) There’s no styling for keyboard focus in the custom drop-down. This makes it invisible to users that the drop-down actually has keyboard focus.
Or as one test subject explained during testing at Crate & Barrel (seen above) “Oh the tab didn’t work for ‘month’ and ‘year’”, when reaching the expiration date drop-downs during testing. The test subject had actually successfully tabbed into the expiration month, but couldn’t see that it had keyboard focus. She, therefore, tabbed multiple times before (wrongly but understandably) concluding that tabbing didn’t work.
Note that our benchmarking reveals the majority of custom designed drop-down implementations fail in this aspect.
3) Keyboard characters are not allowed for selecting values in the custom drop-down. This means that users cannot use the keyboard to “jump” to specific sections in the drop-down, makes it needlessly difficult to navigate long drop-downs and impossible to do quick keyboard selections.
For example, in REI’s custom drop-down for the expiration date, seen above, values cannot be selected using keyboard input. This makes it impossible for users to tab into the custom drop-down and then select the card expiration date using only the keyboard. Support for this is important because in our large-scale checkout usability study we’ve found that it’s 24% of all desktop users who consistently try to input the expiration date using only their keyboard.
4) The opened drop-down isn’t tall enough to display all values. This makes users prone to overlook the non-visible select values, and those that do notice them will have to use troublesome inline-scrollable areas.
For example, American Eagle Outfitters (above left) offers a custom state drop-down, where several test subjects successfully tabbed to the state field, and typed “t” to jump to that part in the list. While AEO got the keyboard interaction right, note how length of the drop-down interface is suboptimal as it’s too short compared to the available space. Walmart (above right), suffers from the same issue with their custom drop-down, it’s just in an even worse context.
5) The custom drop-down always has the same open direction regardless of the users position on the page. This causes the selection list to be cut-off by the browser viewport.
For example, note in Walmart’s custom drop-down for selecting states (seen above), how this user could only see four state values. The drop-down is actually taller than this, but because the drop-down always expands downwards, it will often expand outside the user’s viewport.
These are all nuances that are important to the drop-down’s overall usability, and all of these 5 drop-down usability issues were resolved around a decade ago in the browser’s native drop-down implementation. Today nearly all native drop-downs will have a dynamic open direction and size based on the drop-down’s position in the user’s viewport.
In our usability testing we do observe that in some instances, a custom drop-down can be superior to a native drop-down. Sometimes custom drop-down designs can be used to provide a better data presentation or a better interaction for the user.
In terms of data presentation a native drop-down is very limited as it, more or less, only allows unstyled text. In a drop-down for selecting credit card expiration dates, quantity, countries, states, etc. this lack of text styling is quite okay, and we observe no issues during large-scale testing for such selection values (due to drop-downs lack styling, at least). However, the native drop-down’s lack of styling makes it a very poor interface for visual selections. Such options are much better communicated using visual aids, like color swatches or color variation thumbnails.
Other times the user’s interaction experience can be improved by using a custom drop-down implementation. This is particularly the case for drop-downs with a large number of values, like “Country” and “State” drop-downs – where we consistently observe usability issues. Here a superior design is to (progressively) turn the drop-down into an auto-complete field. In the case of a country drop-down, instead of having to scroll 200+ country options in a tiny drop-down pop-over window, the user can then simply type the first couple of letters of their country and it shows up.
While some site do use custom drop-downs to provide better a data presentation or selection interaction, most e-commerce sites use them simply for aesthetic reasons as a lot of sites want to control their entire “brand feeling”. If aesthetics is the objective there’s a much simpler and better solution than a fully custom drop-down; the ‘Shell Approach’.
If the desire for a custom drop-down is purely rooted in aesthetics, we’d strongly encourage this ‘Shell Approach’ over developing a fully custom drop-down. The ‘Shell Approach’ is significantly cheaper to implement initially, requires far less maintenance, offers better compatibility with older devices and browsers, and is more flexible in supporting future web evolvements (i.e. accessibility, voice control, interface-less sites, etc.) since all of the selection logic relies on native HTML elements.
However, if relying on the ‘Shell Approach’, make sure to design a very clear styling for when the semi-custom drop-down has keyboard focus, as the majority of implementations using the ‘Shell Approach’ forget this important element – effectively disrupting users’ tabbing flow.
While fully custom drop-downs are somewhat popular, they are also very expensive to develop properly. Consequently 31% of all the custom drop-down implementations suffer from a series of low-level interaction and usability issues – all leading to selection friction that native drop-downs do not suffer from.
While there are exceptions where fully custom drop-downs are warranted – like country selectors, mobile main navigation, and horizontal filtering drop-downs – most sites use them purely for aesthetic reasons. This is a user experience trade-off that is seldom justifiable considering how many sites are unable to get the implementation details right, and considering that the ‘Shell Approach’, roughly speaking, give sites 80% of the effect for 20% of the cost.
If you still deem you need a fully custom drop-down implementation be sure to make it on-par with native drop-downs on these 5 important implementation details:
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 24,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
Thanks for sharing about the drawbacks of using custom drop down field options while designing an eCommerce site. These drop downs may look attractive but this can have negative impact on user experience. You have clearly explained the examples.The main disadvantage comes when the user is not able to see all the values in the drop down field and this results in bad design. The websites should be designed keeping the user experience in mind.
Here’s another flaw with many custom drop downs that has been long-solved in the native implementation: when the option you want contains a space, and it’s not a free text field with autocomplete but rather a conventional dropdown where typing merely changes the selected option, the space sometimes doesn’t get processed. For example, I’m from New Jersey so I like to type “[tab][n][e][w][space][j][enter][tab]” and this works perfectly on native implementations. I get New Hampshire or other wildly unexpected behavior on some of the custom drop downs.
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 email@example.com