Mobile Commerce Optimization: 5 Tips for Touch Keyboards

While general form usability guidelines apply to mobile, there are some unique issues that occur with touch keyboards that you should anticipate and and properly handle in your code.

Today’s post highlights tips from the research findings of recently published m-Commerce Usability: Exploring the Mobile Shopping Experience by Baymard Institute.

Based on usability studies, Baymard Institute identifies 5 guidelines for touch keyboards (the report includes tutorials on how to code each tip properly):

1. Disable auto-correct where dictionary is weak

Auto-correct is helpful on mobile devices, but can also make it easy for customers to submit incorrect information when incorrect auto-correct is applied without customers taking notice. Auto-correct is particularly troublesome for abbreviations, street names, email addresses and similar words not in the dictionary.

In the study, even common address abbreviations like Rd were auto-corrected (for example, to “Ed”).

Auto-correct needs only to be disabled on fields where improper autocorrection is a problem, such as Name, Street, City, User ID and email address, and may be left in tact on fields where it may be helpful.

2. Show appropriate keyboard layouts

Best practice is to show the most appropriate keyboard layout for a given field. For example, pull the numeric keyboard for credit card and phone number fields, and email keyboard for email addresses. This spares the user from toggling between keyboards themselves and reduces the potential for errors.

Many of Baymard’s test users took notice of these optimized keyboards, providing positive comments. And typos were significantly reduced, leading to fewer validation errors (especially for long numbers like credit card input).

Be aware that numeric keyboard layouts don’t always allow for alphabetic characters and may only support select special characters. Ensure that neither the field nor keyboard you select prevents proper entry (for example, a telephone number format that requires dashes combined with a keyboard without the dash character). Also ensure that international form fields do not prevent alphabetical inputs for postal code.

3. Honor ‘Next’ and ‘Previous’ button behavior

Users expect Next and Previous buttons to do what they say. Naturally, test subjects had problems with sites that failed to move the user to the next or previous logical field in the form without requiring other changes or form submissions. Surprisingly, this bug occurred on more than one site in the test group.

Not all users will rely on these buttons (rather, use the tab method), but those that do will experience friction if they do not behave as expected.

4. Disable auto-capitalization where appropriate

This is a problem I’ve encountered many times with CAPTCHAs on mobile forms. Smartphones tend to auto-capitalize the first letter in standard text fields, which is helpful for fields like Name, but not for email addresses and case sensitive password selection. Used with CAPTCHAS, failure is inevitable, and the user may not understand why input is failing each time.

5. Consistently invoke keyboard layouts

When optimizing keyboard layouts, be consistent. FTD, for example, applies the numeric keyboard to the credit card field, but not to the security code field that follows.

“What is even more surprising is just how confused some of the test subjects were by this. They began questioning their initial interpretation of the field, thinking that maybe something else was required. For example, when seeing the standard keyboard layout for the “Card Security Code”, the subjects began wondering if this was the 3-digit code on the back of their VISA card or if perhaps it was one of the many other numbers printed on the card.”

It’s a good idea to test your form fields on a variety of popular devices, as not all touch screens behave alike.