Shopping Carts
If the customer is prevented from navigating away from the checkout page, by isolating the checkout process, navigation through the checkout process is nearly always in one direction: towards order confirmation. The exception is when someone wants to go back one or more steps to check or to change what they’ve entered. This often proves the downfall of badly designed or inadequately tested checkout processes.
Customers may want to retrace their steps to:
Change the product they’re buying (I’ll go for the more expensive/cheaper version)
Use a different email address (I’ll use my personal email address rather than my work email)
Use a different delivery address (I’ll get it delivered to my neighbor)
Use a different payment method (Not sure if there is enough money in that account)
Check the details previously entered (Which address/card/delivery service did I specify?)
However, something to keep in mind is trying to limit the need for the customer to click back and forth in the checkout process. This is best achieved through a persistent checkout summary – carrying forward a summary of the information entered in previous steps of the checkout. This persistent checkout summary can also facilitate navigation back and forth within the checkout.
The main recommendation for navigation in checkout, however, is to make sure the browser back button works in the way the customer expects it to. Checkouts can get this wrong in two different ways:
A) Warning messages
B) not taking customer to where they think they will be taken.
I purchase a lot of stuff online so I see a lot of warning messages, like – the previous page, which the customer is asking to be reloaded, has data to the server during the initial page-load process. In some cases, the technically savvy user will want to re-POST the data and in other circumstances they won’t – hence you warn them what is happening and ask what they want to do.
To the average e-commerce customer, a warning is only a cause for concern, possibly to the extent of abandoning their purchase. They don’t understand the warning, they can’t decide what to do, in case they get it wrong… and most importantly of all, this sort of warning is irrelevant in an e-commerce checkout.
Every time checkout data is submitted by pressing the continue button this data will be saved in the database. Resending POST data doesn’t matter because it is all saved anyway. So, what do we do to avoid such warnings?
There are a variety of solutions involving page redirects and, if necessary, the use of GET or session variables in place of POST variables.
A different problem that arises when customers use the browser back button is that it sometimes doesn’t take the customer where they expect to go. This is mostly a problem when AJAX is used to step customers through a checkout process without moving from one web page to the next.
Using the back button will take customers to the last page they had looked at, which in an AJAX-driven checkout is likely to be the shopping cart page – very annoying if you were on the fourth step of a five-step checkout and wanted to go back to step three!
There are many different technical work-around to this problem.
Taking customers to unexpected places is not just a problem with the browser back button – navigation buttons/links on the page must also be checked for incorrect or legacy URLs. This also applies to those sites that allow navigation via the progress bar. It should go without saying that allowing customers to navigate around the checkout should be possible without the loss of previously entered information.
Tags:
Shopping Carts
none