Checkout Usability: Don’t Use “Apply” Buttons (72% Get it Wrong)

This is the 1st in a series of 8 articles on checkout usability that combine findings from our checkout usability study and benchmark of the 100 largest e-commerce sites.

During our large-scale checkout usability study we discovered that whenever an “Apply” button was used to submit only a section of a checkout form it was either:

  1. Not clicked, even if the related input field was filled out, or
  2. Mistaken for the primary button.

More than half of the test subjects were confused by e-commerce checkout forms with an inline “Apply” button. The test subjects simply didn’t understand the concept of having a separate “Apply” button for distinct sections of a form – i.e. for applying a shipping method or a coupon code to the order. Instead, the subjects expected a single primary button in the checkout flows which would submit everything and take them to the next checkout step.

6 “Apply” buttons all potentially causing confusion and needless friction as we will examine in this article. Checkout steps from the top left: Sears, HP, and PC Connection.

When we benchmarked the checkout process of the 100 largest e-commerce sites we found that 72% made the mistake of using an “Apply” button to submit distinct sections of the checkout form. These “Apply” buttons were typically used to submit zip codes for shipping calculators, applying coupon codes, or updating shipping selections and cart quantities.

The Problem

Let’s start by taking a closer look at the two-pronged problem we observed where “Apply” buttons are either 1) not clicked, or 2) mistaken for the primary button.

When testing Newegg’s checkout, only half of the test subjects who filled in their zip code also clicked the “Go” button. This relates to the first part of the problem, namely that users don’t click the “Apply” button. It simply wasn’t obvious to the test subjects that they had to submit the selected shipping option separately in order to see the shipping cost – after all, they had already chosen the shipping option and thus expected to see the cost immediately. While there may be technical reasons for these implementations, there aren’t any obvious interaction reasons. To the user, the request has been made – having to submit the selection is illogical since the very act of selecting it should be considered sufficient intent.

During Newegg’s checkout only half of the test subjects who filled in their zip code also clicked the “Go” button. (See full Newegg case study.)

The second part of the problem – users mistaking the “Apply” button for the primary button – is related to the notion that users generally don’t expect more than one button in a checkout form, so when they see one, they leap to the conclusion that it will submit the entire form and take them to the next step. This misconception can obviously be a critical problem since it can effectively halt the entire checkout process for a customer – potentially leading to abandoned orders. Below is a form from American Apparel’s site, where some of the test subjects mistook the “Apply” button for the primary button.

During testing, American Apparel’s “Apply” button was mistaken for the primary button, leading to great confusion as it didn’t take the test subjects to the next step as they expected. (See full-size screenshot.)

When a user clicks an “Apply” button, thinking it’s the primary button, the expected flow is broken as she won’t actually proceed to the next step of the checkout. In these cases most of the test subjects began looking for error messages as the page had reloaded yet they hadn’t progressed to the next step. However, since the clicked “Apply” button was applying local changes and not submitting the entire form, there (obviously) weren’t any validation errors to be found, which just confused the test subjects even more.

Styling and Micro-Copy

While the frequency of this issue depends on the visual similarities between the “Apply” and primary button, it was clear from the usability test that it’s not possible to avoid the issue by merely using distinct button stylings.

Furthermore this issue is in not limited to buttons with the name “Apply”, but applicable to nearly all buttons that apply, update or submit, only a specific input or selection within a form. The test subjects ran into the same problems when other contextual words such as “Go” or “Submit” were used for button naming.

The only exception to all this was the “Update” button for product quantity at the cart step. The test subjects never mistook this button for being the proceed button (problem 2), but in some cases it wasn’t clicked even though the user changed the quantity (problem 1) - and therefore this isn’t exactly an ideal implementation either.

In short: while restyling and renaming “Apply” buttons within a form can somewhat lessen the problem, it doesn’t fully alleviate it.

A Solution: Auto-Update

If you need to update a value before moving on to the next step (and often you do as it is generally good usability to reciprocate a user’s action with instant and responsive feedback) then auto-update the value using AJAX instead of using an “Apply” button.

Walmart’s checkout is a great example of auto-updating the user’s shipping selection instantly instead of using an “Apply” button within the form to update the order total. (See full Walmart case study.)

Removing the inline “Apply” buttons obviously resolve the issue of the user overlooking it (problem 1) and eliminates the risk of it being mistaken for the primary button (problem 2). This way you avoid sub-actions within the form-step, ensuring the checkout linearity that users expect from your form steps.

When it comes to auto-updating input fields of a more open format, such as a text field, you have to consider at what time you should auto-apply the value using AJAX. If there’s multiple ways of writing a correct input then you could do it as the user types (e.g. revealing availability of a username as the user types, or the correctness of a password). If there’s only one correct way of writing the input (e.g. a coupon code with a defined set of characters), then you should only try to apply the value when the field loses focus or when the input has reached the correct number of characters (to avoid any inline error messages while the user is still typing). Alternatively, when the field receives focus you may show an “Apply” button that’s visually integrated with the field, and then hide it again when the field loses focus – although this should still be combined with auto-update.

Avoiding “Apply” Buttons

This is a very easy problem to screen for. Generally speaking, whenever you have a button within your checkout process which isn’t the primary button for submitting the entire form, there’s a good chance it’s an “Apply” button that you should consider getting rid of by implementing an auto-update solution instead. It’s one of those small things that lowers checkout friction and makes the process feel more responsive – ultimately improving the customer’s checkout experience.

Share: LinkedIn

Authored by Jamie Appleseed

Published on July 11, 2012

Comment on LinkedIn

User experience research, delivered twice a month

Join 22,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

More E-Commerce Research

Free Research Content:

Products & Services:


Great article, many thanks

It’s all well and good using Ajax to auto complete but you are discriminating against those without JavaScript for whatever their reason.

I have 2 alternatives:
1. Make the button name “Apply the specific change to your basket”
2. Use only one button on the page and call it “Update and/or continue” until all the fields have been submitted. Of course each time the button is submitted it checks the form for any changes and if there are none, then it continues.

Clearly 1. is not ideal for any visually stimulated user but it is extremely accessible and usable as it says exactly waht it is for and saves confussion creeping in.

And with 2. Ajax or other JavaScripts could be used to change the name of the button depending on what has or hasn’t been changed in the process.

To be honest, if your checkout process requires so many different fields to be changes in the first place, change your checkout processes to be more user friendly despite what yout business requirements are.

Hi Jason (and Mat below), thanks for the great comments, but the concept of multi-buttons dosen’t resolve the two issues (overlooking it, and mistaking it for the primary button) only dampens it, but at the cost of screaming louder too all of the customers.

The single-button approach, either with Ajax or without, is a much more foolproof in regards to resolving the two user issues.

In reagards to technical discrimination; progressive enhancement (as George and Giuseppe suggests) is the way to go combining the best from both approaches.

I agree with Christian here, non-JS usage shouldn’t hold back progressive enhancements that the majority of people will benefit from.

Fallbacks are easy enough to implement if needed…

.no-js .apply-button
display: block;

I agree with Jason…as much as we love to use slick Ajax interactions, it’s discriminatory. Simply using better visual cues is a simpler method. Single button approaches will almost invariably work best but in multi-button cases, using either simple hyperlinks or differentiated buttons along with better verbiage selections (‘Redeem Coupon’ or ‘calculate Shipping’) is usually better, even if it breaks our design flow need for simplicity and word reduction.

I am curious as to why we are still so concerned with browsers that don’t support JavaScript or users that turn it off. Does anyone have any statistics that would warrant spending the $ on this subset of users.

I expect it is very small and given the audiences of these websites, not a primary target and not worth the cost.

I agree with the guys above to a certain extent but I don’t see using Ajax to improve usability and user journey through your checkout process as a problem. It isn’t discriminatory to use technology to improve the process, it’s a designers responsibility to provide the best solution with what is available. Providing the non javascript process is as well developed as it can be, then Ajax away!

Jason’s second alternative above is a good idea (to check for changes on continue), but it’s something that should be built into your checkout process / forms as a fallback for non javascript users.. It isn’t an ‘alternative’. There are many situations when a user has changed something on the page and they expect visual feedback be it some kind of confirmation text, or just a small loading gif.

Good article by the way, some interesting results!

While I like the idea of Jason’s alternatives, the second one contradicts the initial reasoning behind doing them in the first place. If the user doesn’t have Javascript enabled, you can’t change the name of the button dynamically when the user updates a field in the page.

But, it’s on the right track. By using Progressive Enhancement techniques in the development of the checkout process, you should build the system first without Javascript, then enhance it appropriately. In the case of a check out page with the ability to apply discounts, calculate shipping costs, etc, Have the primary action button just submit the data to the server. Let the server do it’s job and parse the form, making the appropriate next steps based on what comes in, and move to the next appropriate step, even if that step is back to the same page.

As always, thinking about how the flow should work shouldn’t necessarily always be with regard to the “latest and greatest” thing out there to date, but should be solid without any bells and whistles first, then enhanced to add in bells and whistles.

Hi George, spot on with your suggestion of the one-button approach with Progressive Enhancement.

On addition: when you say “Let the server do it’s job and parse the form, making the appropriate next steps based on what comes in, and move to the next appropriate step, even if that step is back to the same page.” only ever direct a user back to the same checkout step in case there is a form validation error (an even then consider Errors- only depending on the dataset ) .

Improving process doesn’t always require a “new” technology – it requires improving the conditional and global user experience by providing a process that meets both advances in IxD, performs all the necessary parts to complete a transaction and hopefully also appeals to the user visually. While I do it, creating two paths depending on the technology availability increases the likelihood of problems in execution. A stepped, page-turning, non-interactive checkout that works and converts is 100% better (or more) than one that is single-page, slick, interactive and either doesn’t work or confuses the user.

I agree to your notion of not using slick technology just for the sake of it. And that one-page checkouts ins’t a sure path for achieving a usable or delightful checkout experience: .

But in some instances – this article describing one such case – one of the easiest ways to avoid confusing the user during checkout is by utilizing “slick” technology (here eliminating the consequences of overlooking or misinterpreting an “apply” button within the form).

It would of course be even better not to have the fields there in the first place, by rethinking the underlying business/logistical requirements for the purchase process (e.g. having flat rate shipping, etc.).

I think you should have an ‘Add a coupon’ button, which when clicked pops up a layer which allows entry, shows a loading indicator, then the layer hides itself if everything is ok, and displays a message if it isn’t.

I think the obvious other elephant in the room is the layout of the sites tested. They are all a similar layout, so naturally have the same issues and rather than a multi-step wizard (like etc) they try to do too much in a small area.

Hi Dawesi, hiding the coupon code fields are an advisable approach. It could also be a link instead of a button, thus further avoiding the possibility for misinterpretation (primary button issue). Although the button text of “Add coupon code” might be enough.

In regards to the sites tested, then no. They aren’t of similar layout as this happens on 72% of the top 100 grossing e-commerce sites. I do see that the Sears and HP images used in this article are very similar, sorry about that.
This issue are equally also applicable to accordion styled checkouts (multi-step wizards such as as there will still be a sub-action within each “step”. Two examples of accordion checkout where this could occur are: Victorias Secret checkout step 4, and Gap checkout step 5. In both cases the Apply button can be overlooked, and to some degree also mistanken for the primary button (especially because the button styling are the same as for the primary button).

Image of Gap checkout step 5:

Image of Victorias Secret checkout step 4:

An exception could be when there is a text field input, for example “Search by name”. Would be interesting to see if that would work with autoupdate, but then it would need a few seconds of no-typing to start the autoupdate. How would use perceive that?

Great article. I think you’ve managed to get into most user’s mindset (including myself) about the potential problems of having an apply button as well as a continue button. Better yet, your proposed solution is very much appreciated. Cheers.

Excellent article. I think the usability and user experience are two different concepts but interdependent. When a web site is not very usable, users have more difficulty navigating between its content and find what they need. Usability is often a cause of poor user satisfaction (negative user experience) and in the long run the bad user experience reflects negatively on organic ranking of the website.