I'm toying with the idea of completely hiding the submit button on a credit card form until the user enters valid card info (checksummed number, expiration date, security code). As soon as invalid data is entered, the user is presented with contextual errors, and as soon as all valid data is entered, the "pay" button appears. Any thoughts on the effectiveness of completely hiding the button vs. just disabling it?
1
-
The others have explained in more depth but my 2 cents its not a good idea. My question is - why do you want to add extra code to your page. - What does it achieve or improve or optimize.– Accidental_EverythingFeb 28, 2015 at 16:33
Add a comment
|
3 Answers
In most cases this is not a good idea. It comes down to UX goals:
The main goal of a credit card form is usually to get the user to complete a purchase.
Error correction and validation is only useful if it helps you accomplish that goal.
The Buy it now, Purchase it, or Complete purchase buttons are usually excellent opportunities to display a clear call to action to the customer. So hiding that button deprives you of an opportunity to prompt the customer to complete a purchase.
The call to action is usually far more important than error validation, so that is why almost all shopping carts provide a bold purchase button which appears on screen right next to the payment form, and never disappears.
If the user mistypes a payment detail, the form will prompt the user to correct the detail, but the button does not fade or waiver...it's a bright and clear button that is designed to fixate your eye and your attention on the goal of the process:
-
btw, also related on general show/hide for form submits: ux.stackexchange.com/questions/8876/…– tohsterFeb 28, 2015 at 6:32
-
the main UX goal of a credit card form is to facilitate the users purchase (user focused language), rather than get them to complete a purchase (business focused language) Feb 28, 2015 at 10:56
-
Toni, I prefer to state goals in terms of clear outcomes rather than methods. For a commercial applications that often means a business goal. This actually maximizes design thinking because words like 'facilitate' can conflate goals with means and can bias teams towards certain approaches. For example, 'facilitate' is cognitively dissonant with 'force', 'cajole' or 'challenge', all of which may represent successful UX approaches. This is just a matter of professional practice... Your approach may work very well for you too.– tohsterMar 1, 2015 at 16:44
-
Interesting, so you would suggest that it's not a good idea to even have a disabled state for the button, as it reduced the impact of seeing the the end goal?– jscheelMar 2, 2015 at 15:26
-
@jscheel I would not have a disabled state because a wavering of state may cognitively cause users to pause and reconsider the purchase. But you will have to decide whether that is appropriate for you (some apps want users to make carefully considered purchases to avoid returns, others want to capture impulse purchases so removing cognitive friction is important)– tohsterMar 2, 2015 at 17:14
Hiding the submit button is not part of progressive disclosure. The only case where a submit button is not available upfront is probably within a Staged disclosure where there are a number of interdependent steps displayed in a wizard or similar pattern and submission taking place as part of the last task in the process: see below for distinction between progressive and staged.
With the above distinction in mind, Credit card forms are quite straight forward and don’t need to be broken down into a multi-step process. So the "Submit" button needs to be available and viewable for the user to commit to action.
If you want to improve the process you could focus on improving layout and optimizing the form for better formatting, in which case, you might find the following piece useful:
Format the 'Expiration Date' Fields Exactly as the Credit Card (40% Get it Wrong)
-
Thanks for the clarification. I have the full Baymard report, which I will be digging into more.– jscheelMar 2, 2015 at 15:24
There are expectations at play — users have an idea of the form and would want to see button there, otherwise the whole component would seem incomplete/broken.
Disabled button implies visually that user has to complete the form (correctly) before it can be submitted. By hiding the button, you are hinting that there is no such condition. As users know from previous experience the condition is obligatory, they might suspect your form is buggy. There inevitably will be a percentage of users who thought there is something wrong with the form and fall off the process instead of completion.
