Insights on mobile dropdowns

Dropdown menus are standard elements in a modern user interface. They allow users to select one option from several other options. Although dropdown menus and their modification, the dropdown button, are widely used on desktop systems, there are often better choices for mobile systems.

Luke Wroblewski wrote a very good article about the advantages and disadvantages of different navigation elements and pointed out how many “taps” the user can save when using drop-down menus. But saving taps is only one aspect when it comes to usability. Time is another and crucial factor here: You want to enable your users to perform their tasks as quickly as possible.

To better understand how dropdown menus and their alternatives affect the time spent, I have conducted two experiments.

First dropdown experiment

In this experiment, users were asked to fill out a search form for a flight app For this they had to provide the following information:

1. Departure date (same month)
2. Arrival date (two days after departure)
3. Class (first class)
4. Number of passengers (six passengers)

Using Quant UX, I created two very different prototypes that are very similar to the examples described in Luke’s article. The first prototype relies heavily on dropdowns, while the second prototype uses alternative controls such as date selection, stepper and segment elements.

By changing the controls alone, the minimum number of taps can be reduced by a factor of three: from 28 to 9.

Both designs were unmoderated and tested remotely. A link to the prototype and a short introduction were sent to the testers and the tests were performed on their smartphones. The age of the testers was between 25 and 45 years and all testers had experience with mobile apps. The first design was tested by 22 users and the second design by 47 users. For the sake of simplicity, the fields for departure and destination airports were already filled in so that they could be ignored by the testers.

The majority of users of both prototypes were able to complete the test, but there was a significant difference in execution time between the two designs: users of the first design took an average of 43 seconds, while users of the alternative version took only 25 seconds.

This represents a 40% improvement!

The biggest impact on this result was clearly the combined date selection, which replaced six drop-down menus. It took users only 8.5 seconds to enter arrival and departure dates using the date range picker, as opposed to 22 seconds when using the six drop-down lists.

In the automatic screen shots I noticed that some users had problems with the date picker. Ideally, the user would tap the calendar once, tap a start date a second time, tap a third time to select the end date and close the calendar.

However, many users had problems with this interaction pattern. They did not expect to type a second time in the calendar. As a result, users could not select the end date immediately, but instead clicked a different time on the start date or closed the calendar before trying again. As a result, 50% of testers had to open the calendar a second time and 30% needed three or more attempts to select the correct date range.

Second dropdown experiment

Since a large part of the users had to struggle with the date selection, I decided to create a third prototype. I simply replaced the date selection with two normal date selection elements: one for departure and one for arrival. This design costs an extra click and was tested by 27 remote users.

The third prototype was an improvement over the second version in two main aspects: First, all testers could fill out the form and second, no user had problems with the two different date selection elements.

Ultimately, the new UI elements contributed to a reduction in execution time to 16.5 seconds and made usage 60% faster compared to the drop-down version.

Other observations

In my tests, users were asked to search for a flight for six people. This high number is certainly not common, but I chose it to better understand how the stepper can be compared to a drop-down menu. In the drop-down menu, users have to tap twice, once to open the options and once to select the correct number of passengers.

The stepper needs five taps for the same selection. The introduction of a widget that increases the number of taps seems to be counterproductive.

Do we not want to make the interaction as smooth as possible?

Fortunately, there is a big difference in the way people interact with drop-down and stepper elements. The drop-down menu opens the options in a list where users have to rescan the screen to find the right option while the stepper doesn’t change position. The user can simply “tap” on the same location. As a result, users are only minimally slower when using the stepper widget to select six passengers.

In our tests, users used an average of 0.3 seconds per tap. Only the last tap took a bit longer because the users didn’t want to skip a step. As a consequence, the stepper would be faster in scenarios with less than six people. It is also noteworthy that the stepper is more intuitive due to its higher success rate (77% vs. 88%).

I also replaced the drop down menu for class selection with a segment control. It allows the user to select one of three options. The segment button also works great: almost all users (93%) understood the function behind it and selected the first class. The control not only saves two clicks, but also makes users 1.5 seconds faster.

Conclusion

Avoiding drop-down menus is a crucial design pattern for mobile platforms. In my test, it made UI usage 60% faster and reduced usage errors. Date range selectors are powerful controls. They increase productivity, but can sometimes be difficult for users to use or difficult to understand at first attempt. Using two date range selectors could therefore be a safer choice.

Segment elements are excellent for a small selection of options. They are easy to use and save space. Last, but not least, steppers work very well, especially for smaller quantities. Although they require more clicks, they are extremely fast to use and therefore compensate for the need for additional interaction.