Bad Practices on Phone Number Form Fields

Phone number fields, along with birthdate fields, are tricky to get right. There are many phone number formats users can choose from and they’re often unsure which format is valid.

Phone number fields, along with birthdate fields, are tricky to get right. There are many phone number formats users can choose from and they’re often unsure which format is valid. Sometimes they’re even unsure if they should include their country code.

When users are unsure about the proper format, they worry that the form won’t validate their input. A validation error for the wrong phone number format can cause them to abandon the form.

Your users should not wonder which phone number format is valid or get a validation error for the wrong phone number format. If they do, your phone number field has a poor user experience and needs to be redesigned. Avoid the bad practices and follow the best practice if you want to improve your phone number field.

Allowing Any Format

Some think that allowing a phone number in any format is the answer. This would prevent validation errors, but it doesn’t curb user’s uncertainty about which format they should use.

phone_number-any_format
Any uncertainty the user has can decrease your form conversion rate. Users need to be certain about their phone number format otherwise they’re going to worry their input won’t validate.

It’s also not clear to users whether they need to include their country code before their phone number. Users may make the mistake of typing in their country code when it’s not required, resulting in an incorrect phone number.

Showing the Proper Format

Some believe that showing the proper format with an example by the text field will solve the format uncertainty. The user will just look at the example and type their phone number in the proper format.

phone_number-example

Turns out that users notice the example, but most of them don’t follow it. A research study found that “89% of test subjects entered their phone number in a different format than the example provided.“

Providing a formatted example isn’t helpful since most users ignore it. Not only that, but they lead to validation errors when the user’s input isn’t in the proper format. The study found that format validation errors resulted in form abandonment.

Separate Text Fields for Each Number String

Some say splitting each phone number string into separate text fields solves the formatting troubles. For an American number, you would have three text fields. This practice does make the formatting proper and consistent, but only for American users.

phone_number-separate_fields

Users from other countries would not be able to type their input because their phone numbers have different formats and lengths. Creating text fields localized to one country isn’t user-friendly to international users.

Separate text fields also make it difficult for mobile users to type in their input. Usability testing found that many users had a “difficult time navigating between the fields on mobile devices.” This also makes it harder for them to correct their input if they mistype it.

Auto-Formatting with Geolocation and Input Masking

The best practice is one where users don’t even have to think about phone number formatting or country code because it automatically displays it for them.

Auto-formatting the input with geolocation and input masking is the best way to present phone number fields. As users type their phone number, the proper format is displayed without any effort from the user.

phone_number-autoformatting

Users don’t need to type any parenthesis, dashes, slashes, periods, or spaces, just numbers. The field has a numbers only constraint to prevent validation errors if they type other characters.

Geolocating the user’s country allows you to auto-format the phone number of every user no matter where they’re from. This also tells you what their country code is without having them type it in. This means less work for the user and a better conversion rate for you.

The country code should be displayed alongside the phone number so users know they don’t need to type it in. The most intuitive way to do this is to display an icon of the user’s country flag inside the text field next to their input.

It’s possible to allow users to change their country code if they want to enter an international phone number. Clicking the flag icon would display a dropdown menu with other country codes.

Don’t Make Users Think

When users fill out forms they don’t want to think. They want to type away and complete the form as quickly as possible. Allowing users to enter their phone number in any format forces cognitive work on them. Instead, take the load off users by auto-formatting their input for them.

Making this change to your phone number field can prevent form abandonment and increase your conversion rate. Follow the best practice on phone number fields and stop making your users think.

Mistakes to Avoid on the Birthdate Form Field

Asking users for their birthdate on a form is complicated. Birthdates have formats that vary depending on the country and they consist of three separate data strings.

Asking users for their birthdate on a form is complicated. Birthdates have formats that vary depending on the country and they consist of three separate data strings. It’s easy to confuse and frustrate users if the birthdate field doesn’t use simple controls and isn’t in a clear format.

The Confusing Way

Users are either used to seeing a birthdate displayed with the month first (month/day/year) or day first (day/month/year). When they see a required format that’s different than what they’re used to they have to think hard about their input.

birthdate_field-format

What users commonly see next to a birthdate field is “mm/dd/yyyy” or “dd/mm/yyyy.” Although it may be easy for some users to intuit that “mm” stands for month and “dd” stands for day, other users often get confused by this or they ignore it.

Users might also pause to wonder whether they need to use leading zeros (e.g. 09) for the month or day number. This makes them think about the input format and slows them down.

Another problem is that users may see the required format but instead type the date in the format they’re used to by force of habit. This user error leads to receiving incorrect user data.

The Difficult Way

Sometimes the birthdate field is spelled out with Month, Day, and Year labels. While this is less confusing for users, it can be difficult if the user has to scroll through three different select menus.

birthdate_field-menus

The number of options users have to scroll through is tremendous. There are 12 month options, 31 day options, and 118 year options (from 1900-2018). Scrolling through this many options is difficult and time-consuming to do.

On top of that, desktop users have to switch from keyboard to mouse when they get to these select menus. Switching causes them to exert more effort and slows them down. It’s possible to navigate them with your keyboard, but few users do so.

The Complex Way

On rare occasion, you’ll find a calendar widget being used to select a birthdate. This is complex for users because they have to click tiny arrow buttons to select the year and month. Since most birthdays aren’t near the current year, users will have to click that button a lot.

birthdate_field-calendar

When they finally finish selecting the correct year and month, they have to scan thirty-one numbers to find the correct day. These numbers are often in small font and hard to read.

The Clear and Easy Way

Writing out the label for each birthdate string and separating them into three fields instead of one eliminates the format confusion. Users may have to press the tab key to hop to each field, but if correct user data is important to you, a clear format is essential.

birthdate_field-good

Custom sized text fields are also important for clarity. When you customize each text field to the length of each birthdate string, you’re giving users a visual cue. This signifies them to enter the month number not the month name. It also signifies them to enter the full year instead of abbreviating it (e.g. 80 for 1980) since the year field is wider.

Text fields are easier to use than select menus and calendar widgets because desktop users don’t have to switch their hands from keyboard to mouse. Mobile users also don’t have to swipe or tap small targets.

Too Many Choices

The birthdate is a complicated form field to design because there are too many formats and controls to choose from. The way most birthdate fields are designed today is confusing, difficult, and complex. Designers should choose the clear and simple way and leave the other choices behind.

Stop Using Select Menus for Known User Input

Before you decide to use a select menu for your form field ask yourself a question. Will users know their input without looking at the list of options? If the answer is yes, do not use a select menu for it.

Before you decide to use a select menu for your form field ask yourself a question. Will users know their input without looking at the list of options? If the answer is yes, do not use a select menu for it. Instead, use an autocomplete field.

It’s unnecessary for users to scan and scroll through a long list of options if they already know their input. Select menus force users to do this extra work which frustrates them and slows them down. It’s even worse for them on mobile where only a small part of the list is visible and keyboard search is not available.

select_menu-autocomplete_field

An autocomplete field is better because it saves users time and effort when they’re selecting known input. The user only needs to type the first few characters of their input before they see it appear as an option. They can then press the down arrow key and to select it from the menu.

Instead selecting from a large amount of options, they’re selecting from a minimal amount of options. The more they type the less options appear, making it even quicker to find and select their option. The number of options displayed to the user is reduced, which also reduces the error rate.

This usability violation of select menus is often found on fields involving time or place input. Country and state fields are big culprits as well as day and month fields. Users know their input for these fields and shouldn’t have to waste time scanning irrelevant options.

Make it quick and easy for users to fill out your form by using autocomplete fields instead of select menus for known input. It’s much like going to a familiar restaurant. If you already know what food you want to order, reading the menu is a waste time.