Article overview

Users Continue to Double-Click Online

· By · 13 comments ·

Double-clicks can lead to products being accidentally added to the cart twice.

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. Yet many e-commerce sites continue to handle double-click behaviour very poorly.

AllPosters.com disable 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 behaviour 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.

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

Tom Bevan July 26, 2013 Reply to this comment

Very interesting post, keep them coming!

Jamie, Baymard Institute July 26, 2013 Reply to this comment

Thanks Tom, will do :)

Martin Blackburn July 26, 2013 Reply to this comment

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

Heres a quick javascript solution for anyone interested.
http://jsfiddle.net/4F99S/

Caroline Jarrett July 26, 2013 Reply to this comment

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

Stomme poes July 26, 2013 Reply to this comment

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. http://www.quirksmode.org/js/events_mouse.html#dblclick

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.
https://en.wikipedia.org/wiki/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.

Steve Krug July 26, 2013 Reply to this comment

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

Matt Westcott July 26, 2013 Reply to this comment

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

Helen July 27, 2013 Reply to this comment

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!

Wayne Baskin July 31, 2013 Reply to this comment

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.

Jane Christien December 7, 2013 Reply to this comment

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.

JDB April 3, 2014 Reply to this comment

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

Bhavia June 24, 2014 Reply to this comment

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.

Thanks.
Bhavia

uçurtma July 22, 2014 Reply to this comment

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

Post a comment!

Close overlay