Do not make users choose from a list of only one option

Posted on November 17, 2023

This article is part of a series on user interface micro interactions and how they affect the user experience.

It’s quite frequent and normal to ask users to make a choice between different available options.

There are many components that allow to do just that, here are a few examples:

These examples is not an exhaustive list of the possible design patterns to choose from, but they provide a good overview.

In software, those options may be dynamically constructed based on the context of users and the available options of the system. This may lead to situations that require users to do more work because the system may not be designed to handle cases in an ideal manner.

It’s never a good idea to ask users to do work (e.g. more actions, more cognitive load) that a system could do. Many people like to quote Steve Krug’s Don’t make me think! when they design, however I prefer to think of it as “Don’t make me work!”

Let’s take a look at a few examples to illustrate that point

Example 1: example based on client work

In the system of a client, there was an option to remove options from a context in which they were previously recorded. Data had shown that removing all options was a more frequent action at the time, so the Designer chose to offer an option to remove all options at once, or to select them one by one.

What was not planned is that this design pattern may lead to the odd situation in which users are asked to choose from a list of only one option:

While this certainly is functional, it offers superfluous options users. Choosing “Specific options” actually requires more clicks than choosing “All options” when there is only one option recorded. If anything, this adds cognitive load on the shoulders of users who may be confused and try to understand if there is a difference between the options.

Additionally, Developers must ensure to handle the form error management in case users submit the form without choosing which specific option they must select.

In a case where only one option is recorded in the system, it would be simpler to user this design pattern:

With this single question, and clear actions offered with the buttons, users would not have to try and figure out what is the difference between the options.

Example 2: Nintendo’s Switch

Here is another example: when opening the online store on the Nintendo Switch, users are asked to select who is using the store app. This follows the design pattern Nintendo intended: this is a family console, it is likely that multiple people in a household would want to buy different games.

This becomes a problem when there is a single user of that console, like in my case. Every time I open the store app, I am again asked to select from a list of one option. In this case, it could be argued that users are given the choice to create a new user from that screen with the plus button next to the user avatar.

I would argue that since user creation and management is also offered in another part of the system, an improvement could be made:

With this minor change, users could choose to not have this interstitial screen presented every time they open the store app. If they wanted to change shopper, or change the default shopper, there could be options available in either the system settings or the store settings.

Keep in mind that unsolicited redesigns like I did in the wireframes above may be incorrect for many reasons. Maybe my suggestion had already been user tested, and did not provide the results I think they would. Always remember to test your design patterns with users.

Last updated on February 13, 2024