Remove Select Features When There’s Only One Option Left (14% Don’t)

Our large-scale Checkout usability testing reveals that 14% of e-commerce sites, at some point in the checkout process, present users with what appears to be a selectable option, only to disappoint users when it turns out there’s only one option, or the option displayed isn’t selectable after all.

Our testing revealed that, for most users, this results in confusion over why they’re being presented with a selection that can’t actually be made, which slows them down as they stop their progress in the checkout to puzzle over the option.

This user hesitation can result in simply mild annoyance at being offered a choice when one doesn’t exist, but is also observed to cause more serious user frustration, as some users attempt to make unavailable selections. Yet our benchmark data show that 14% of sites don’t remove “Select” features when there’s only one option left.

In this article, we’ll discuss the test findings from our checkout usability study related to “Select” features (like a drop-down or radio buttons) with only one option available, and provide a solution that testing revealed performs well with users.

Showing a Selection Interface Is Confusing When There’s Only One Option

“Why are you asking me to choose something when I have no choice?” one test subject pondered after opening a drop-down only to find it contained just a single preselected value.

When presented with a selection interface, like a drop-down or a set of radio buttons, users tap into their prior experience, which tells them that these interfaces clearly communicate that a selection either can or must be made.

The issue often occurs on sites when the select values are dynamically removed as they become invalid or unavailable — for example, removing those shipping options that are not available for the address the user has typed. This is in itself a good idea — that is, only showing options that are relevant to users based on their current context. However, in cases where there’s only a single option left, it shouldn’t be presented as a selectable option anymore since it’s no longer a choice.

When There’s Only One Option Available, Use Static Text

While selection interfaces should dynamically remove options as they are no longer available to users, the selection interface needs to take into account the stage where there’s only 1 (or 0) options left. Instead of displaying a selection interface (a drop-down, radio buttons, etc.) with a single option, we’ve found in testing that this single option should instead be displayed as plain text on the page. This way the same information is conveyed without confusing users by indicating a selection is to be made (otherwise indicated by the selection interface). As an additional bonus, there will also be fewer form elements on the page, making it seem less intimidating.

Note that the single option should be displayed as text, instead of simply “disabling” the selection interface (i.e., greying it out). Simply disabling the interface element was observed to perform poorly during all of our checkout and mobile usability studies, as users seldom noticed the interface was disabled or understood the concept — consequently, users were just as confused by the disabled interface as the selection interface with just a single option.

Again, it’s 14% of the top-grossing US e-commerce sites that do dynamically remove the options within selection interface as they become unavailable based on the user’s context, but then neglect to consider the stage where there’s only one option left for users to “choose” – here the entire selection interface should be dynamically removed.

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.

Share: LinkedIn

Authored by Christian Holst

Published on December 12, 2017

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 59Cart & Checkout articles

More E-Commerce Research

Free Research Content:

Products & Services:


Counterpoint: Keeping the selectable item with only one option tells me there are situations in which I have an option. This is key for things like Amazon where the shipping options can vary wildly and people use it often: if a user is accustomed to having 5 options and all of a sudden has NO options (ie is presented with one option without a selector like a radio button), there can be confusion.

It’s definitely not an all-or-nothing approach and needs to be carefully examined before being implemented.

Hi Adam, thank you for your comment and the concern. While site context should always be taken into account, we’ve consistently seen in years of usability testing of a myriad of different checkout contexts that selector interfaces with just a single option consistently confuse a large portion of normal end-users, and even confuse more web-savvy users. We observe that getting exactly what e.g. a solitary radio button means is largely for “web professionals”.

In testing we haven’t seen the static text option to cause usability issues. For clarity, it’s essentially the Blue Nile example: ( ) vs the Overstock example:

I see a point in Adam’s comment, and have seen similar user response in the past where there was confusion when a Select feature dynamically became static text (but in a security management product, not a consumer/e-commerce).

Do you see this confusion among users particularly within the e-commerce space, or any web app in general? The reason I ask is that sometimes the user could be interested in selecting a specific option, and would be open to go back and update the config of preceding information to re-enable the disabled option…somewhat a deductive interaction pattern.

We mainly test e-commerce sites with regular web users, so we would not be able to say if the observations also apply for other web apps in general.

(generally though the more “pro” users are, the less it will be an issue, for example for web apps where the majority of users are daily users, or for apps where the majority of the user base are it-professionals (almost no e-commerce sites have either of those)