Mobile: Never Use Native Drop-Downs for Navigation

This is the 4th in a series of 8 articles on mobile usability that draw on findings from our mobile e-commerce usability report.

Many responsive mobile sites are using native drop-downs (as in: a select tag) for main navigation and many plugins have been developed for this specific purpose, yet our usability research shows that this is a poor strategy. On the tested mobile e-commerce sites that used native drop-downs for navigation, the test subjects showed decreased control and overview of the menu items.

During testing, nearly all subjects scrolled up and down category lists before selecting an option, many explicitly stating that they wanted to see all the categories before selecting one – even if they felt they had spotted a good match early in the list, the subjects still scrolled the remaining items just to make sure they knew what their other options were (before then scrolling back and selecting the good match). The subjects exhibited the same behavior on homepages where they often scrolled up and down to get an idea of what their options were, even if they saw what they were looking for right away.

This strong tendency towards scanning all options before selecting one is at the core of why native drop-downs are a poor choice for navigation. When open, a native drop-down only utilize ~50% of the screen, which made it needlessly difficult for the subjects to get an overview of their options.

With only half of the screen used to display the available options, users will have a difficult time scanning and comparing the available options. To make matters worse, the drop-down often starts out at the top with only 3 options visible to the user (left image), and even when scrolled to align optimally, no more than 5 options can be seen at once (right image).

Another issue with the navigation options only taking up 50% of the screen is that the scroll area for those options is similarly small. The smaller scroll area resulted in less accurate scrolling as there was so little room to “drag” the content that many subjects flicked to scroll instead (which of course is a much more inaccurate way of scrolling).

Finally, we also observed a few instances where subjects mistook the navigation for filtering options. This was especially true of category and search result pages where subjects were on the lookout for filtering options and then simply jumped to the conclusion that the drop-down was such a feature.

Solution: Custom UI Drop-Downs

It’s very important to underscore that drop-down navigation isn’t bad at all, it’s native drop-downs (as in: a select tag) which are unsuitable for navigation due to the way they have been implemented in the major smartphone operating systems (such as iOS and Android).

While the navigation at The Boston Globe is very similar to how the native drop-down works in terms of interaction (you first click “Sections” and then a set of simple items are revealed) it is significantly better because the options aren’t limited to a dialog but can take up the entire screen if necessary. In the above all 10 items are shown at once; quite the improvement in terms of overview, scannability and “scroll control” when compared to the meager 5 items that can be shown in a native drop-down dialog. (The navigation items on Boston Globe are, however, on the short end, being only ~5,3mm tall.)

Another benefit of implementing custom drop-down UIs for navigation is that you have complete control over the design of the options. This means you can optimize the design and layout of the shown options (which you can’t with a native drop-down). CSS-Tricks, shown above, is a great example of this where, when expanded, the menu items are displayed in two columns and each has a descriptive icon next to it. It can also be more subtle, like the earlier Boston Globe example where arrows have been added to indicate virtual space.

During testing the subjects had no issues using these types of custom UI navigation as long as they followed basic design conventions, had adequate hitarea sizes (device manufacturers recommend a minimum of ~7x7mm), and the trigger element was designed as a link / button (so that the subjects knew it was clickable).

It should be noted that native drop-downs are not poor for all purposes – they can work well in forms where keeping page context can be as important as the options themselves. However, native drop-downs should not be used for main navigation as they simply afford too little overview of the available options and are needlessly difficult for users to scroll accurately.

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” mobile e-commerce user experience.

Share: LinkedIn

Authored by Jamie Appleseed

Published on April 23, 2013

Comment on LinkedIn

User experience research, delivered twice a month

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

Related Articles

See all 63Mobile Web articles

More E-Commerce Research

Free Research Content:

Products & Services:


This article is not particularly objective. By “Mobile” you mean “iPhone” and I regret to say that the element ‘select’ is much better managed by Android.

Hi Antoine,

Thanks for your feedback.

However, there are many different implementations of the ‘select’ tag on Android, and some of them are very close to the iOS design (and these two groups combined make up a very significant share of the smartphone market; certainly enough to spend a few hours to avoid poor navigation UI on those devices). But it is true that some Android distributions are different and more suited for navigation. However, even for those Android distributions the ‘select’ tag is still not optimal for navigation since you can’t do custom designs of the options.


On my android phone using the SelectNav site referenced it opens a “full screen” list of radio buttons that I can select. If I don’t want any I just hit the “back button” that is a physical control on the device itself.

The entire menu on the SelectNav site fits on one window. No scrolling required. It actually works quite well.

So maybe Android does it right sometimes. But you can’t ignore the other crummy implementations just because Android has their act together. When programming for mobile devices, you have to think about the lowest common denominator. Especially when it has a huge market share.

I’m sorry Antoine, but i totally disagree with you.
Android management of the element “select” also has it’s problems. For instance, In android phones, if you have an option, in a select element, that is too long, this option will not break into 2 or more lines, something that happens naturally on iOS.

The solution is that Apple should redesign the native controller to respond to longer lists of options. Browser vendors should also rethink how select boxes work on desktop too, since developers keep trying to build better versions with CSS/JS.

Mobile is bigger than just iPhone.

In Windows Phone, it feels more ergonomic to use. It takes the whole screen and I prefer it. It’s always faster than CSS/JS solutions.

Like this:

It doesn’t matter that there are other phones; when using the select tag you MUST take into account iphone interactions, whether you like them or not. You have to design for multiple devices, not just the one you happen to use. Even Internet Explorer.

I somewhat agree with ALi Reid. He has a point that regardless what you think of it, design has to cater for all devices. I do also like the alternative you have suggested though. All too many people complain about a service without having any suggestions of their own.

Even though Android has a market share of over 60%, and the iPhone market share is 13%, designing for Android at times feels like designing for IE. Sooo many different versions of the OS, it’s hard to make the site work in all of them correctly.

What about the pros of using native? There was no time spent on this. What happens when scripts update and your “custom” solution now has to be maintained to work with new technologies? I agree that navigation is a case where a custom interaction should be used, but this article is very biased.

I’d also like to question some of the “conclusions” that we’re jumped to. Just because a user scrolls through their options, doesn’t mean they have a hard time processing or seeing them. I think that was rather rash to assume that they were hindered by the native interaction. You didn’t talk about how the user felt during this time. Did you even take note of it?

What about testing the proposed solution? Did you see what the user said/felt if the UI took over the entire screen to show them all the options? If it were me, I would feel lost, like I was taken off the current page.

My 2 cents.

@Merne – as this article is condensed from their m-commerce study (, I would guess that details like that would be there. I also felt like they did support their rationale with feedback from the users, and timing the users on those tasks would reveal whether it was more efficient or not.

Hi Merne,

Thank you for commenting your concerns. This article is based entirely on how the test subjects were observed to behave and how they responded during our large scale usability study of 18 mobile commerce sites. Every single interaction was recorded and later on transcribed and analyzed which took almost 6 months – so yes, we did take note of how users reacted and felt when interacting with the native dialog for main site navigation – as outlined in the article – a few being confused and mistook it for a filters menu (severe issue, low frequency), while most had issues getting an overview of their options due to the native drop-down only utilizing half the screen (low to medium severity, high frequency).

Agree that using a non-native drop-down menu of course required proper testing and maintenance. A visibility toggle is however relatively simple.

This is Saurabh Pandey

I am looking for a drop-up menu to place in a footer at the bottom of my webpage. There are plenty of drop DOWN menus, but I don’t know how to modify the code to position the sub-elements to appear ABOVE the parent items.

Google isn’t helping but that’s probably because I don’t know the proper terms to use!

I’m starting out with something generated and modifying it but I don’t know how…

if you have a solution of our problem please help me !

So almost four years later, what’s the common consensus here? Go with the updated native “select” options or a pure CSS menu?

I was thinking the exact same thing. Why do web developers have to find workarounds for native html elements. Why aren’t browser vendors updating the mobile implementation of this??