Presenting users with drop-down, radio button, or other selectors, when there’s no selection to be made, leads to unnecessary clicks and user frustration.
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.
“And then I can select the color,” a subject says in the cart at H&M (first image), and clicks the drop-down, only to disappointedly realize that “there’s only green. Okay” (second image). Presenting users with what seems like a choice will result in unnecessary clicks and frustration.
At RueLala, users are presented with a drop-down containing a preselected shipping option, but when they click the drop-down to see the expected alternatives, none are available.
Issues also occurred when testing radio-button interfaces with only a single choice, as seen here at Blue Nile, where users doubted whether there were choices to make (there weren’t).
“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.
At ASOS, 33% of the test subjects were confused about invalid options included in the shipping selector drop-down at the cart step. Several tried to pick invalid options, saying, “When they give me the option it just might work” or “I’ll choose this one anyways [‘Spend over £20’, ed.] and see if it figures that out itself.”
“Okay you can’t select anything. There’s only this one,” a test subject concluded after attempting to open the color drop-down. When faced with disabled drop-downs, users often clicked multiple times (as many as 4) before concluding the drop-down couldn’t be opened.
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.
Notice how Overstock.com dynamically changes the radio button interface for their shipping options (first image) to static text when there’s only a single option available (second image).
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.
At GAP, registered users with saved credit cards are asked to either select an existing credit card or add a new card during checkout (first image). However, for registered users without saved payment methods the drop-down is removed (second image), which is also what is displayed to guest users. Therefore only users for whom making a selection makes sense (i.e., registered users with one saved credit card) are shown the selection drop-down.
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.
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
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 info@baymard.com
AdamDecember 13, 2017
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.
Christian, Baymard InstituteDecember 14, 2017
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: ( https://cdn.baymard.com/research/media_files/attachments/27376/original/research-media-file-137b7f93161e3f5468a3d557874110bc.jpg ) vs the Overstock example: https://cdn.baymard.com/research/media_files/attachments/27387/original/research-media-file-b5b9186d72e898e761d44e8d02b5eec0.jpg
YoshiDecember 14, 2017
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.
Christian, Baymard InstituteDecember 15, 2017
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)