We’re all probably more familiar with online grocery checkouts than ever before at the moment, so I thought I would take the opportunity to examine a popular online grocer and see what lessons can be learnt from their online checkout.
Here they are:
Once a user has browsed your site, filled up their basket and is moving towards purchase, you want to remove the distractions of extra navigation items and focus their attention on their goal - completing their purchase with you. They are moving from browsing behaviour to a far more narrow focus - getting your goods to them.
The Tesco checkout process has a number of places where the path forwards seems muddled, or there are strange addictions of paths that lead away from the goal.
Take this holding page before entering the checkout process:
The heading and text underneath indicates that this page is here to get users to decide between a delivery and collection, but there are a number of browsing links, dead ends and looping buttons still present.
The headers still allow a user to go to other parts of the website:
The Book a slot button on the right hand side leads me back to this page (where I have to choose a delivery method and then a slot). The Checkout button also leads me back here.
Compare the Tesco journey with the John Lewis one at this stage:
Everything has been stripped out - links, headers, everything - to only leave a clear path forward and a single choice - Delivery or Collection.
Related to the above - the goal of the user once they have entered the checkout is to set their delivery options and address and provide payment details. All functionality should be enabling a customer to do this easily.
Another step on the way to the checkout itself has two buttons:
Continue shopping - takes a user back to browsing for more groceries.
Empty basket - as it sounds, clears out the basket entirely
Both are unnecessary paths away from the users’ goal, but the second is a ‘nuke’ button - a reset on everything the user has done so far to get to this point. Needless to say, this is not a good piece of UI to include in any checkout. The ‘Continue shopping’ button also gets further negative marks as “Continue” is almost always used to progress forwards in a journey, not move backwards to what someone was doing before. I would worry that some would click this expecting to go to the next step of the checkout.
Further into the checkout journey, if a user wants to change a delivery address or add an additional one into their account, the following message appears:
You cannot amend or add addresses within the checkout journey itself - instead you are taken to a completely different section of the website It’s then a long journey back to this same point. Most checkouts offer the ability to edit, add or remove addresses within the checkout - this would benefit Tesco’s checkout enormously.
Unlike browsing, a checkout has a clear direction and goal in mind - keep users moving towards that in a single direction without taking them elsewhere, or providing multiple chances to undo the work that they have already done.
For users not previously registered on the Tesco website, they will be asked to set a password. The requirements for this field are very strong:
For a full explanation of why this is a bad idea you can head to our blog on the subject, but the important part is below.
Baymard Institute lists two potential downsides to overly strict password requirements:
The first point consistent with data taken from Zuko - 50% of users return to the password field at least twice. This is a significant point of friction for users, and has a detrimental effect on UX.
Baymard also highlights the fact that since a form may require a complex password, a user may ‘make up’ a particularly complex one and, without a password manager, simply not be able to log in further down the line since it would be almost instantly forgotten. The password reset function would therefore be used widely, which is not a great user experience.
So whilst it may not cause abandonment, password requirements like this are likely to be detrimental to the overall user experience of your form.
We can see below the HTML for the card number field at the final stage of the checkout:
On the right, you can see that the type is set to text, which means on a mobile device the default text keyboard will appear:
A user will therefore have to switch back and forth between keyboards or long press on every number to get it to enter. This can be made easier by setting the HTML type to ‘tel’. This keyboard will appear when a user focusses into the field:
Certain fields within your form will be asking users to enter only numeric characters:
All of the above would benefit from having the type changed to tel to benefit mobile users.