Users Continue to Double-Click Online

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. 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.

Share: LinkedIn

Authored by Jamie Appleseed

Published on July 25, 2013

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

More E-Commerce Research

Free Research Content:

Products & Services:


Very interesting post, keep them coming!

Thanks Tom, will do :)

Didn’t realise that such a large amount of people still double clicked.

Heres a quick javascript solution for anyone interested.

Thank you for reminding us that we need to design for this behaviour.

It rather makes sense: if your desktop environment requires double clicks, and if most people have trouble distinguishing between the desktop and the web, then of course some people will expect the same behaviour from both. Especially as web developers try harder and harder to imitate Desktop behaviour with increasingly complex apps, or with things like Dropbox where the same application has both a Desktop and a web component.

There is a dblclick event you can listen for, but as PPK warns on his (aging but still good) mouse events page, a click event begins the dblclick event.

I’m wary of blanket-always disabling double clicks. We have times where a user for example tries to add too many items (more than available) to their baskets from a product page. The first click returns false; and a message explaining what the total in stock is they can order, and the order quantity reset to the maximum. The second click, if the user chooses so, does the placing of orders into the basket (or they can not click it and do something else, like decide not to order at all or change the amount in some other way first).

The one thing every e-commerce site should be using to avoid duplicate orders is POST-REDIRECT-GET.
This not only prevents duplicate orders, but it makes the Back Button do what users expect, instead of giving them the endless loop of browser alerts asking if they want to resend this request.

Meanwhile double clicks on anchors should merely be robust and work. Two requests after each other for the same resource should simply result in the proper page, and if you’re using good caching there shouldn’t even be any longer delay due to double-clicking.

Very nice post. I particularly enjoyed the animated IKEA example, which made me feel like I was reading one of Harry Potter’s newspapers.

One pitfall of disabling the submit button is that Safari (both mobile and desktop) preserves the final document state when navigating with the forward/back buttons – which, in this case, means that if they submit the form, then hit the back button, the button will remain in its disabled state, making it impossible to resubmit the form.

You’ll either need to explicitly re-enable the button on revisiting the page – apparently doing this in a jquery ‘ready’ event should work, but it seems people have had mixed results with this – or be more sophisticated about how you catch multiple clicks (e.g. base it on a timer).

This was very informative – it’s true that I would have never thought of this as a problem when I never double-click. Thank you very much for the article!

From our usability testing we found people are double clicking as they are trained to do it from access applications on their desktop.

One other issue we found when designing our new site is that if you are using a shadowbox on click event, the second click (of the double click) closes the shadowbox before it opens.

To rectify this we disable the click using javascript with a short timeout thus ignoring the second click.

More and more people are become regular internet users on computer as well as other application. The more people use internet from what I can observe, they double click lesser. But of course the observation is not professional statistics.

Don’t most modern browsers prevent double-clicking automatically?

This is very interesting piece of information. It never occurred to me that click back button twice can be so troublesome. I enjoyed reading this post. Very informative.


One pitfall involving disabling your submit key is usually The idea Safari (both mobile IN ADDITION TO desktop) preserves the final survey state When navigating through the forward/back buttons – which, in the actual case, means The idea regardless of whether they submit the form, after that hit your back button, your press button will probably remain with it\’s disabled state, making it impossible to resubmit ones form.

You’ll either need to be able to explicitly re-enable the option at revisiting your web site – apparently doing this within an jquery ‘ready’ event Just in case work, but The item seems a person have had mixed results within this – or even be additional sophisticated about how you catch multiple presses (e.g. base That with an timer).

So it’s now 2019. Are users still double-clicking??? Or have they finally come around?

Hi Ian, ironically this behavior is increasing, but that mainly because of the mobile aspect “The user simply thinking their tab wasn’t registered” whenever the mobile site responsive is just slightly slow. In that sense, it’s become even more important to have good support for this (on mobile at least)

100% agree with the double click issues. For one of our client’s website the end user was clicking submit button twice or thrice while creating bills and thus system was saving 2 or 3 bills. Then after we started disabling submit button once user clicks on it which solved the issue.

Good post.

This is a very amazing piece of information. It never occurred to me that the click the back button twice can be so troublesome. I enjoyed reading this post. Very informative.

Ravi Kumar