Here’s a simple test: pick up a standard business card. Judge its size. What you’re seeing is roughly the same size as the frame your mobile users have available to view your entire mobile site.
And when it comes to the mobile checkout experience, you should fold that business card in half as the touch keyboard will take up close to 50% of the available screen space in portrait mode. If the user is in landscape mode the landscape keyboard will take up 70-80% of the screen.
Throughout all our usability test sessions of mobile checkouts this extreme lack of page overview was observed to have severe implications on the user’s checkout experience and their ability to even complete a mobile purchase. Users simply get “lost in the page” – especially when filling out forms.
Therefore, to account for this lack of visible context and page overview in your mobile checkout and payment design, closely consider the following 6 mobile checkout insights:
When users lose their overview of the page they often tend to focus on each form field as a separate isolated task to complete, and not so much a part of a large whole (as they more often do during the checkout process at desktop sites).
It’s therefore critical that all the field labels can be read and understood when read out of context. For example, a label shouldn’t simply read “Phone”, even if placed within a “Billing Info” section header, but should instead be completely context-independent and read “Billing Phone”. This of course goes for any type of field, so it should similarly be “Gift Certificate Pin” instead of just “Enter Pin”, and so on. This way, the user can fill out the form field regardless of whether they remember its context (which is often out of view).
More than half of the test subjects (60% to be exact) had serious trouble identifying, seeing and selecting the guest-checkout option at the account selection step during checkout. To simplify the initial page impression and set the right expectations of what the user should do at a given step, consider using the principles of progressive disclosure and dynamically collapse the content.
For example, at the account selection step, instead of having 3 separate headers for “Sign-in”, “Create account” and “Guest checkout,” each with their respective fields shown, simply collapse all the content and show 3 clickable headers. This allows the user to instantly get a complete overview of all the available options (“there are three paths you can take, which direction would you like to follow, sir?”).
See further examples and explanation of the account-step issue in our guest post at Smashing Magazine, Exploring 10 Fundamental Aspects Of M-Commerce Usability (section #6).
The checkout process is dominated by form fields, so naturally any form field usability issues will tend to cause trouble during the checkout process. Some of the most severe issues that arose during testing were due to basic mobile form usability issues such as:
a) Users not being able to see their typed input because the field label was placed to the left of the field, making the field itself too short. For this reason form field labels on mobile should always be placed above the field (except when in landscape mode), as outlined in Mobile Form Usability: Place Labels Above the Field.
b) Users not being able to see the field’s context due to the use of inline labels. While inline labels look simple, they are in fact a perfect example of false simplicity: visually simple but complicated to use. The major usability issue is that the label disappears as the user begins typing (or in really poor implementations, as soon as the field receives focus, see first image), but the issues extend to validation errors (see second image) where users will often have to delete their input just to see the label again, as further described in Mobile Form Usability: Never Use Inline Labels.
c) Users having to endure needlessly many field interactions due to inputs being split into multiple form fields. While the intention of wanting to indicate the desired input format is great, it ends up creating needless friction as it requires an inordinate amount of field interactions. Therefore, make sure you have just a single phone number field, zip code field, and a single “full name” field, as outlined in Mobile Form Usability: Avoid Splitting Single Input Entities.
Even with context-independent labels placed above the field, users may still become doubtful about certain fields if a set of basic questions aren’t answered. These doubts range from the very severe “What is being asked for?” (seen above), to privacy concerns “Why do you need it?”, to input formatting “How should I format the input?”. Unclear field labels remain one of the most important aspects of both mobile and desktop checkout form usability, alas, it is also one of the most neglected facets with 92% of top 100 desktop e-commerce sites still having room for improvement. For the 15+ most common pitfalls see Add Descriptions To Checkout Form Labels (92% Get It Wrong).
Furthermore, in a mobile checkout, any descriptions, help and field clarifications, must be placed exactly where the doubt is likely to occur. Instructions placed at the top of the page proved to be of little value during testing as the subjects simply overlooked it (again due to the extreme lack of overview described in the introduction). This makes inline help such as click-based tooltips and form field descriptions vital.
Form usability can be greatly improved by leveraging the various input-optimized touch keyboards available (e-mail, phone, etc). Yet, of the top 50 mobile optimized e-commerce sites, 60% fail to utilize 2 of 5 keyboard optimizations. During our usability testing, this resulted in checkout experiences dominated by validation errors, and even orders submitted with erroneous data.
Using these touch keyboards is technically very simple – the difficult part can be to identify all of the candidate fields across a large website. We’ve made a Touch Keyboard Cheat Sheet showing how to set the best combination of keyboard
novalidate for checkout fields such as name, phone, credit card number, address, e-mail, etc. (it also includes a touch keyboard benchmark of the top 50 mobile commerce sites).
Typing on the small touch keyboard is both slow and very prone to errors. So whenever technically possible, auto-detect and auto-complete as much as you can. For country selection this can be IP geo-targeting or at the very least an intelligent country auto-complete.
Things like state and city name can often be auto-detected based on the user’s ZIP-code, so simply ask for user’s ZIP code first and then pre-fill the state and city fields. Luckily there are two freely available plugin’s for just this: Ziptastic and Zippopotam.us
When designing a mobile checkout think back on that business card. Your users will have to go through a number of pages and fill out a bunch of form fields all within that tiny area, and they typically have the touch keyboard open which cuts the available screen real estate in half! These 6 recommendations are a good place to start in order to deal with this extreme lack of page overview that your users suffer under during the mobile checkout process.
When you have a decent mobile checkout design up and running be sure to test it extensively internally, but also externally, preferably on users within the target audience, using their own device in a realistic context (e.g. at home on the couch). This allows you to uncover issues related to site, audience and context, which are hard to uncover otherwise.
This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” mobile e-commerce user experience.
Join 24,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
As a developer,I am disappointed that I would have to add, possibly for every single input EVAR, two non-existent/invalid attributes to “off” to prevent a bad design flaw in one specfic type of mobile phone. (Snce this is not part of the HTML spec, finding out whether these can be placed once on the form itself as an attribute is more difficult than it should be.)
It would make more sense for devs and customers to pressure Apple to turn auto-anything off (at least for web) and allow devs to selectively add “on” to whichever specific inputs would benefit from autocorrect or autocomplete.
The web is filled with hilarious gaffes and nasty things unintentionally said in SMSes and chats etc. due to autocomplete and autocorrect. To have these things on by default, as proprietary HTML attributes, feels very wrong.
I’ve changed the steps/flow of our hotel mobile website booking engines a few times in the last two years.
As we’ve gone through different iterations, addressing usability/conversion issues along the way, the one change that surprised me the most was how difficult the account selection step was.
We used a similar interface to what you’ve described above, allowing the user to sign up, sign in or proceed as guest on a single page – visually presented as three jQuery Mobile buttons.
Even though the user could easily proceed as a guest and jump straight to the checkout page, the abandonment from that step of the booking engine was very high.
I’ve now moved that logic into the payment page, it defaults to a guest checkout with two text links to sign up or sign in directly above the guest information panel.
This process works well for the us because people dislike creating accounts in general. Users are willing to create accounts for services they know they’ll use regularly or provide some intrinsic value but users know their own travel habits and most users don’t travel enough to warrant creating another account; hence why using a guest checkout as the default flow with an option to sign up/sign in has worked best for us so far.
While I’ve pushed the conversion related issues deeper into the booking engine and de-emphasised it, the next version of our booking engine is going to support creation of a users account via the reservation confirmation page (ie, enter a password — since we’ll already have all other necessary information) and I’m keen to see if putting that input box after the reservation has been secured will result in more account creations.
Hi Alistair, thanks for sharing.
Yes, another completely valid approach is defaulting to a guest checkout, and then “integrating” the account selection process with the shipping or payment step, and then inserting a options password field at the receipt page. This does however put considerable less focus on signing in during checkout, so sites with many repeat account customers will likely get better results with a dedicated “account selection” page (in a mobile context at least).
We’ve also published an article on 6 ways to better utilize the order receipt / confirmation page: http://baymard.com/blog/order-confirmation-page
Thanks Jamie for putting this up. We were struggling with multiple checkout we tried with our clients on mobile and when we implemented the first one of your list the results were great, we are still doing A/B testing over to use 1 page vs progress bar one.
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 firstname.lastname@example.org