Online Checkout usability best practices for developers
The following are a list of developer to-dos my teammate Dice and I have gleaned.
There are lots of other ux best practices, you can find some good lists of those elsewhere such as here and here for example (simple, fast and clean is common).
1. Set autocomplete off for private information such as card holder name, card number, cvc code and dates to ensure information previously entered is not displayed to the wrong people.
i.e.
<input autocomplete="off" id="cardNumber"/>
You can set it off at form level or individual input field level. I prefer input field level since you may want other fields such address on the form to autofill.
FYI this is also a godo diea to use for passwords too.
Mozilla post with more.
2. Don't store card information on your server to meet PCI Complicance. Many Checkout apis allow you to send card information in a javascript api (jsonp) which returns a token for your use thereafter. A simple trick to avoid submitting card information as part of form submit is to not include a name attribute for the field. e.g. repeating example from above there is an id but no name for cardNumber. Thus it can be styled etc. but is just not submitted.
<input autocomplete="off" id="cardNumber"/>
The nice thing about this is you can still submit/serialize the whole form but those fields without a name attribute are not sent. Trust me, you'll probably change the form over time and being able to submit the whole form will avoid lost fields.
If you have to have a name attribute then you could remove it just before form submission using jQuerys removeAttr or dom api removeAttribute. Don't forget to add back in case of errors.
3. Do not make the customer re-enter data. Once entered by the customer no data should be lost and have to be re-keyed. See ajax tip below for how to stay on the page until data is valid.
4. Use ajax as much as possible during checkout such as when users change shipping, add/remove gift wrap, change address, add/remove coupon etc. (as opposed to form submission). I think developers/designers should start from the premise that most every action in checkout which requires server interaction is an ajax call, even the submission of main pages. Once ajax is successful then you can redirect to next page as appropriate.
Using ajax calls in such ways allows customers to see the immediate cost impact of their changes but also ensures any information they entered on a page is not lost. This is important in the context of #2 PCI compliance since card information is not submitted for PCI compliance reasons and only exists on the page.
5. Show feedback to the user when updating (e.g. simple animation) so they know something is happening. Disable submission button on Pay screen while processing the payment.
6. You can detect card type from the card number entered, Google wallet does this as does PayPal but many many sites do not, perhaps it may change in the future or users are just used to/more comfortable choosing card type and then entering number. Up to you how you handle this.
7. You can run card number validations on the client to ensure the card number enters is valid for the card type. Talk to your payment gateway provider and ask them for regex for card number for the different card types you support. Then implement that regex check in javascript on the client. That regex does not change very often.
You can also add a checksum check for card number and check the exp date is a future date on the client.
While these checks also exist on the server its better for the user if they're caught on the page.
8. Avoid warnings on https pages for not https resources using protocol relative urls.
You've probably seen https struck through in red on Chrome address bar or a popup in IE warning about loading insecure content on secure page. This is not something you want your checkout users to see and become confused about (and thus loose a potential sale).
The warning is usually caused either by certificate problems or the page includes other resources which are insecure. It's quite common nowadays to have 3rd party resources (such as trackers) loaded on pages, so how to ensure these 3rd party resources don't cause https warning?
For such 3rd party resources use protocol relative urls for these 3rd party resources, it will load https version when on https page and http version when on http page.
9. Make as much as possible configuration driven so that a change is a config file (or other similar) change and not a code change. Such configuration values must be configurable by country. This includes checkout cards supported, date formats, address validations, urls for email, blogs and so forth, omniture style tracking and so on. "Go long" on this and it will pay dividends. Where necessary json encode and push the data to the client so the javascript can apply client side rules based on the data so when the data changes so does the client (niiiceee).
10. Supporting shipping and billing addresses types and rules will likely consume more effort than you expect (in many cases alot more). 3rd party services such as Cybersource or Payment Gateway may impose additional rules you do not anticipate (so thoroughly study and walk through their specs). e.g. a payment gateway required a state for Canada, the ui had to be changed to populate and add mandatory Canadian states list for Canada (in the case was not in the spec :-( ). Approx half of countries which have postal code require a value, the rest do not. Zip is US only. etc. Typically we develop agile and refactor as new requirements are added but in this case you must as much as possible identify&document the all the rules/requirements for all sites up front so you understand true full scope and can create a suitable design. Impress upon the business the need to do this now. See last advice about being data driven, such lists of whats required and not should be configuration settings configurable by country.
11. Hide or disable the submit button. We displayed a non modal timer but users still pressed the submit button more than once so we had to disable the button so it could not be clicked.
Funny checkout.
There are lots of other ux best practices, you can find some good lists of those elsewhere such as here and here for example (simple, fast and clean is common).
1. Set autocomplete off for private information such as card holder name, card number, cvc code and dates to ensure information previously entered is not displayed to the wrong people.
i.e.
<input autocomplete="off" id="cardNumber"/>
You can set it off at form level or individual input field level. I prefer input field level since you may want other fields such address on the form to autofill.
FYI this is also a godo diea to use for passwords too.
Mozilla post with more.
2. Don't store card information on your server to meet PCI Complicance. Many Checkout apis allow you to send card information in a javascript api (jsonp) which returns a token for your use thereafter. A simple trick to avoid submitting card information as part of form submit is to not include a name attribute for the field. e.g. repeating example from above there is an id but no name for cardNumber. Thus it can be styled etc. but is just not submitted.
<input autocomplete="off" id="cardNumber"/>
The nice thing about this is you can still submit/serialize the whole form but those fields without a name attribute are not sent. Trust me, you'll probably change the form over time and being able to submit the whole form will avoid lost fields.
If you have to have a name attribute then you could remove it just before form submission using jQuerys removeAttr or dom api removeAttribute. Don't forget to add back in case of errors.
3. Do not make the customer re-enter data. Once entered by the customer no data should be lost and have to be re-keyed. See ajax tip below for how to stay on the page until data is valid.
4. Use ajax as much as possible during checkout such as when users change shipping, add/remove gift wrap, change address, add/remove coupon etc. (as opposed to form submission). I think developers/designers should start from the premise that most every action in checkout which requires server interaction is an ajax call, even the submission of main pages. Once ajax is successful then you can redirect to next page as appropriate.
Using ajax calls in such ways allows customers to see the immediate cost impact of their changes but also ensures any information they entered on a page is not lost. This is important in the context of #2 PCI compliance since card information is not submitted for PCI compliance reasons and only exists on the page.
5. Show feedback to the user when updating (e.g. simple animation) so they know something is happening. Disable submission button on Pay screen while processing the payment.
6. You can detect card type from the card number entered, Google wallet does this as does PayPal but many many sites do not, perhaps it may change in the future or users are just used to/more comfortable choosing card type and then entering number. Up to you how you handle this.
7. You can run card number validations on the client to ensure the card number enters is valid for the card type. Talk to your payment gateway provider and ask them for regex for card number for the different card types you support. Then implement that regex check in javascript on the client. That regex does not change very often.
You can also add a checksum check for card number and check the exp date is a future date on the client.
While these checks also exist on the server its better for the user if they're caught on the page.
8. Avoid warnings on https pages for not https resources using protocol relative urls.
You've probably seen https struck through in red on Chrome address bar or a popup in IE warning about loading insecure content on secure page. This is not something you want your checkout users to see and become confused about (and thus loose a potential sale).
The warning is usually caused either by certificate problems or the page includes other resources which are insecure. It's quite common nowadays to have 3rd party resources (such as trackers) loaded on pages, so how to ensure these 3rd party resources don't cause https warning?
For such 3rd party resources use protocol relative urls for these 3rd party resources, it will load https version when on https page and http version when on http page.
9. Make as much as possible configuration driven so that a change is a config file (or other similar) change and not a code change. Such configuration values must be configurable by country. This includes checkout cards supported, date formats, address validations, urls for email, blogs and so forth, omniture style tracking and so on. "Go long" on this and it will pay dividends. Where necessary json encode and push the data to the client so the javascript can apply client side rules based on the data so when the data changes so does the client (niiiceee).
10. Supporting shipping and billing addresses types and rules will likely consume more effort than you expect (in many cases alot more). 3rd party services such as Cybersource or Payment Gateway may impose additional rules you do not anticipate (so thoroughly study and walk through their specs). e.g. a payment gateway required a state for Canada, the ui had to be changed to populate and add mandatory Canadian states list for Canada (in the case was not in the spec :-( ). Approx half of countries which have postal code require a value, the rest do not. Zip is US only. etc. Typically we develop agile and refactor as new requirements are added but in this case you must as much as possible identify&document the all the rules/requirements for all sites up front so you understand true full scope and can create a suitable design. Impress upon the business the need to do this now. See last advice about being data driven, such lists of whats required and not should be configuration settings configurable by country.
11. Hide or disable the submit button. We displayed a non modal timer but users still pressed the submit button more than once so we had to disable the button so it could not be clicked.
Funny checkout.
Comments
Post a Comment