We first observed that some users still double click links and buttons on websites back in 2009. In every usability test we’ve run since we’ve seen issues with users double-clicking links and buttons – in particular for initiating the checkout process and on mobile commerce sites. Yet many e-commerce sites continue to handle double-click behavior very poorly.

AllPosters.com disables their “Continue” button immediately after you click it.

This is not rocket science – the solution can be as simple as disabling the button upon click. This is not even a particularly new insight. Yet, it’s still a problem at far too many sites - mostly because we as web designers, developers and managers have a hard time realizing and designing for a behavior we’d never think of doing ourselves: double-clicking a link or button on a webpage.

Granted, it’s not your average user that still double-clicks on links and buttons; rather, it is a small (yet not insignificant) segment of users. In our tests the number tends to be around 10% of the test subjects, typically aged 50+. Furthermore, there appears to be a high correlation between the users who double-click and those who are generally “insecure” web users.

August 2019 update: This user behavior is increasing and even more prevalent now than when this article was first published. However, this increase is mainly because of the mobile aspect “The user simply thinks their tab wasn’t registered” whenever the mobile site response is just slightly slow (as addressed further down the article). In that sense, this observation and article have become even more important since it was first published (on mobile at least). (If you have Baymard Premium access see guidelines #928, #707, #505, and #363, for our most recent test findings on this).

The Problem

So why is this an issue? Well, it turns out that unless your site is designed for this behavior, a number of undesirable consequences may follow due to double-clicks. The most common examples on e-commerce sites are duplicate orders and unintentionally adding the same product to the cart twice.

Duplicate orders can be placed when double-clicking the “Confirm Order” button during checkout, which causes the order to be submitted twice. In case the user spots the issue immediately they (and you) will “just” be burdened by an unnecessary support case of finding and cancelling the duplicate. In case they don’t realize the mistake and only discovers the duplicate order down the road (when paid or delivered), these users are likely to blame the site, and possibly even believe they are being scammed. Needless to say such an experience can lead to a permanently damaged relation to a site and brand.

Double-clicking the “Add to Cart” button on NewEgg results in the same product being added to the cart twice.

Adding the same product twice to the cart happens when the user double-clicks the “Add to cart” button on the product page. While this is less critical than duplicate orders, it still introduce a significant hassle to the customer, who at a minimum will have to navigate to their cart and change the order quantity. In practice, the interruption is often worse as many users delete the entire line item in the cart rather than change the quantity, resulting in them having to re-find and re-add the product once more.

The Solution

The most simple solution is to dynamically disable the button immediately upon click – ideally showing a spinner as it loads. Disabling the button will make sure the user cannot click the same button twice in a row, and equally important (especially on mobile) the spinner provides them with feedback that their click was registered and that the site is processing their request.

IKEA turns the “Add to Cart” button into a spinner when clicked; this way users don’t accidentally add the product to their cart twice.

Disabling links and buttons with a spinner brings about an additional benefit: it prevents impatient users from re-submitting their request shortly after clicking. During tests, we repeatedly see how impatient users will re-submit requests even during very short (2-3 second) delays of unresponsiveness. They do this for a number of reasons. One reason is that the user believes the request has somehow “failed” and re-submitting will make the site “try again”.

In this short video clip from one of our test sessions, the test subject re-submits the request, thinking the first tap wasn’t registered – a spinner would have prevented this issue.

Another reason, particularly pronounced on touch devices, is that without a spinner the user thinks that maybe the click / tap wasn’t registered and therefore re-submits their request. Showing a spinner immediately upon click removes such doubts, reassuring the user that their request was registered and is being processed.

Of course other more advanced solutions may be added into the mix too. For example, to avoid duplicate orders, the order system can be programmed to reject or flag duplicate orders that are placed within a few seconds of each other (indeed, some payment processors even do this by default).

Amazon detects that the product is already in the user’s cart and displays a notice stating that the quantity is now two, but providing a direct link to “edit your Basket” in case the user only wanted one.

In The User’s Shoes

As with most design targeted at a wider audience, the difficulty here is not in coming up with a solution or even implementing it technically – rather, it is to realize the problem exists in the first place. It’s about designing for behavior you’d never do yourself; coming up with solutions to problems we often fail to imagine because they’re rooted in behavior that’s distant (if not obscure) to us as web-savvy users.

This is why usability testing, even with a minuscule number of test subjects, can be such a healthy exercise for design teams: it’s effectively a shortcut to putting yourself in the user’s shoes. This allows us to uncover behaviors and problems that we’d never think of because the behavior is foreign to us. It is equipped with these very insights that we can begin to design truly user-friendly interfaces that account for a wide variety of diverse backgrounds and behaviors.