24

Working on a form dealing with phone numbers, I've seen two methods to capture user input .

In past practices example 2 (image below) has proved effective in controlling phone number lengths on forms.

However with responsive in mind it would seem example 1 is considered a more popular pattern on forms. I've researched both patterns with the findings below.

Phone Number Input Patterns on Form

Example 1

Pros

  • 1 input = less taps on mobile device
  • 1 input = less coding

Cons

  • could be difficult to control phone number format (1-555-555-5555, +22444455555, and etc)

Example 2

Pros

  • easier to control phone format
  • reduced user error

Cons

  • 3 inputs = more taps on mobile device
  • more inputs = more coding

Both inputs have pros and cons and I'm not such which method would provide the best user experience for responsive environments. Can anyone share some insight or provide a better way to use phone number inputs?

  • 41
    Example 2 is horrible for non-US numbers. – Uwe Keim Oct 22 '14 at 13:00
  • 9
    Sample 2 only covers phone numbers of a certain structure, which the user must know. There’s a lot of variety internationally. It also doesn’t work well with copy-paste. – Crissov Oct 22 '14 at 13:00
  • 2
    It should also be noted that using a single field of type="tel" is probably the best UX for mobiles - when focused, a numpad is shown instead of the usual keyboard – Bojangles Oct 22 '14 at 17:49
  • 1
    For the second approach, why not auto-tab? Ex: for the first textbox user types in 3 characters. When user types in the fourth character, automatically focus on the next textbox. – harsimranb Oct 22 '14 at 19:33
  • 2
    @UweKeim Also US numbers, if you have an extension – Izkata Oct 23 '14 at 15:12

10 Answers 10

35

When a person dials an actual phone number with their phone, do they type 1-555-555-555 or do they type 15555555555?

The only reason for forcing a fixed format is because your back-end can't determine the format it needs. Which is an implementation problem and you're forcing the lack of technical nous onto the end user. That's like saying "we aren't capable of parsing a phonenumber into a format that we want, so we're going to ask you to type in it the format we want".

Just like with credit card numbers - we are mostly no longer expected to type 1111-1111-1111-1111 in 4 separate fields and pick visa from a dropdown because there is already enough information in the credit card string itself to know the type of card, and we can easily split a single number 1111111111111111 into 4 'chunks' if that's how we need it in the back end.

You should try to set up some kind of intelligence in the logic itself. For instance if you know the country the person is from then you will know the format of the phone number, and if you know it's a mobile phone and not a landline then that's another clue for you to use. Then just give the user a single field and let them type in a number however they like.

Heck, some people will want to use a single field and type +44 (020) 444 4444 in there themselves. But you should be able to strip out all the unnecessary characters and spaces programatically and store it as a single field.

Let the programming do the grunt work, not the user.

  • I sadly have fallen victim to typing in the 1 when dialing a phone number (force of habit). Overall i've seen various ways people input phone numbers from using the 1 to dialing the seven numbers. I've actually watched my mother (not technical savvy in any shape or form) type in the () around the area code which made the form she was inputing data fail of course it didn't help there was no error message instructing her not to use them, lol. – Courtney Jordan Oct 22 '14 at 13:10
  • 5
    Yeah, people don't read hints / error messages really. Just let them type whatever they want and then strip out all the irrelevant characters afterwards. Saves all that bother. – JonW Oct 22 '14 at 13:22
  • 3
    Surely a UK phone number is written as one of the following: +44 (0)20 444 4444, +44 20 444 4444, or (020) 444 4444. Your example seems to be a hybrid. – TRiG Oct 22 '14 at 13:57
  • 1
    @TRiG Some people may know about stripping the preceeding 0 off, some wouldn't. But that's the point - as the developer we would be able to programatically tell that the 0 is superfluous and can therefore be removed. – JonW Oct 22 '14 at 14:00
  • 6
    Upvote for Jon for getting to the heart of the matter. Put the burden on the application to decipher the format, not the user. Courtney, this UX technique is called "Forgiving Format". And leads to better UX on all sorts of inputs. – Itumac Oct 22 '14 at 14:21
8

A single input field is always easiest for the user — whether it's for a phone number, first and last name, social security number, or any other value that you may think of as being divided into "parts". Luke Wroblewski has written many articles about this with plenty of data to back it up.

Design your page for the user, not the database. If you absolutely need to break up a phone number into separate pieces (international prefix, area code, exchange, post code) before storing it, then make an attempt to do so but verify it with the user.

For example, if the user types in 5551234567 you could unobtrusively prompt them to confirm that (555) 123-4567 is correct. Be sure to give them a way to fix it along with a way to clarify why your guess was wrong (e.g. it may not be a U.S. phone number, so let them specify their country).

Be liberal with what you accept — allow the user to use a plus sign for an international prefix (and use that in your algorithm!) as well as any other punctuation they feel is necessary. Everyone has their own style of formatting.

6

I would suggest you keep one input field, but use a mask for the text:

-You can use Placeholder attribute from HTML5 (If you are working in a web App) for showing a example number.

4

My guiding principles for this are as follows, vis-à-vis users:

  1. Show them what you expect
  2. Take whatever they give you
  3. Show them what you’re taking

The best way to accomplish all three with HTML5 and jQuery is to borrow this plugin.

enter image description here

I’ve added type="tel" mainly to give mobile users a keypad instead of a keyboard, and placeholder="(999) 999-9999" as a better way of displaying the expected format. When you leave out placeholder, or when focus is placed in this field, the user will see this:

enter image description here

At this point, they can type or paste in whatever numbers they want and see them nicely filled in. If they try to type or paste in any other characters, they simply get ignored. The end result is a nice looking number that should be friendly and recognizable to the user and the system.

If you want to cover international possibilities, ask for the user’s country first and then use form logic to display a field you’ve customized for that country (adjust regular expressions/definitions in jQuery).

  • I always wondered whether ignoring non-numeric characters is always the best way. You could, for instance, transform letters A|B|C → 2, D|E|F → 3, G|H|I → 4, J|K|L → 5, M|N|O → 6, P|Q|R|S → 7, T|U|V → 8, W|X|Y|Z → 9. – Crissov Oct 22 '14 at 17:11
  • 3
    @Crissov I think any benefit to individual users who want to enter their phone numbers with letters (and surely they should be able to enter the numbers) would be outweighed in the aggregate by confusion of users who are entering letters by accident or because they didn’t understand the field. – Tyler James Young Oct 22 '14 at 17:17
  • You don't need a table. – bjb568 Oct 24 '14 at 2:18
  • @Crissov That would be real awkward. That is old-school conventional phone semantics. They have no place on a web-site. To make matters worse: Those keys aren't as standardized as you think. Especially 6 and higher can be mapped differently. Eg. 6:PQR, 7:STU, 8: VWX, 9:YZ. Some variants include the "0" as well. – Tonny Oct 24 '14 at 14:47
3

From my testing, I have learned that you NEVER, EVER, use a single empty field to represent a phone number (or credit card, or any other multi-part field). I've watched users often make mistakes when typing one long number, then not being able to find the mistake they made. With a multi-part field, they pinpointed the mistake easier ("oh, the first number of the 2nd field is wrong!"). Users are also simply used to typing in multi-part numbers as... multi-part numbers. Your phone service provider doesn't tell you your number is 10982859205, they tell you your number is 1 (098) 285-9205. When a person tells their number to another person, they don't speak it all as one number; they break it up just as it is written. When you read a number off a credit card, it's not written as one giant number; it's written as chunks of 4 numbers. Users are used to it, and if you follow JonW's answer, it WILL test badly.

There are already lots of answers that discuss input masks, which is probably the best/easiest solution, but I have also seen well-coded multi-field solutions test well. By "well-coded", I mean fields which will correctly copy and paste values, automatically jump to the next field when typing (removing the need to tap on mobile devices), and automatically reverse-jump when the user hits backspace. Multi-field solutions work, but your point about "more inputs = more coding" is right on the money.

  • Welcome to UX Exchange. Please refine your answer to include specific examples of your research. Also please focus on your answer, there is no need to call out another user. If you have a question or comment for another users answer please do so in the comment area for the other users answer. Thank you. – Johnny UX Oct 23 '14 at 20:35
  • Many numbers (and alphanumeric identifiers) have conventional arrangements with separators, the most popular probably being the thousands separator (,, ., or whitespace), which make long strings easier to read (also popular: -, :, () etc.). Some people will also input these, or hit tab instead. Still, in their mind it is a single number (or ID), not several fields, although some may have special semantics (e.g. area code), but often nobody knows that, e.g. the issuer ID in a credit card number spans the 2nd to 6th of 16 digits arbitrarily arranged in 4 equal chunks. – Crissov Oct 24 '14 at 12:50
2

Go with Example 1. One field for the phone number.

Do some quick client side regex on the number the user entered, to account for any egregious errors to save an unecessary call to your server for 800 digit entries or garbled text.

Ultimately, you are validating the web form data on the server and sanitizing it before dropping it into your database.

  • If you're sanitizing it for database input you may want to do all of the validation on the server so it's the same code. (Just use ajax to pass the value and get the validation result.) Then you avoid having separate client and server validations which can become out of sync and may not be 100% identical due to programming language differences. You wouldn't want a JS validation to give a thumbs up only to have the database reject it because the JS missed some edge case. – craigpatik Oct 22 '14 at 13:27
  • I disagree. I meant a quick validation. As in: don't allow 800 digits or alpha characters. Saves a call to your server. – Eric Steinborn Oct 22 '14 at 13:29
2

Since you've specified that you will only be using this form for a US audience, I don't really see a problem with guiding the user towards using a particular format. However, using multiple text fields might not be the best way to go about that. Let's study some existing websites as examples:

Multiple input fields

Papa John's Pizza uses multiple fields for their account creation. As the user types, it automatically switches to the next field which is helpful because the user doesn't have to click or tab multiple times, but it can be confusing if the user isn't expecting it. If the user mistypes, it's not easy to go back to another section and correct it.

Single field with validation

Jimmy John's uses a single field with validation to ensure the user types in a real phone number. This ensures that the user inputs the desired format, but the coding to make this work can be difficult. Plus, if an error occurs, it may be difficult for the user to find it.

Single field with text mask

Pizza Hut uses a single field with a text mask. This allows a user to input all the numbers at once while specifying the format. It prevents the user from typing too much or too little into the field and it's easy to figure out where errors occurred. I like it. (It's worth noting that Domino's uses the same type of input field, though they likely just copied each other.)

1

I'd opt for option 1 due to the ease of use from purely a responsive view point and like said earlier, if you plan to use the area code etc to some how collate your data and categorizes phone numbers.

The last thing you would want is that number in separate inputs stacking on mobile or device although it wouldn't be a complete disaster again the con of having too many clicks would come into play with less fluidity for the end user...

Again accounting for parentheses and plus signs should also figure, lets not discriminate :)

1

Option 1. + input mask

An input mask (this type, not a password field) allows the user to type in their number in one go (as if they were dialing for example), yet have the number formatted before it is submitted.
This reduces the physical effort (navigating to the next input) and the mental effort (splitting up the number and context switching to the task of navigating to the next input - something outside the usual pattern of dialing a phone; the general use case) See this answer

It is flexible in that the spaces in a format such as 01234 456 789 can be typed, or left out by the user.

If it is required that the international extension is also input, either:

  • Make it clear on the form, so the user will input the correct number
    (e.g. +nn nnnn nnn nnn - have the + already there in the input mask
    or even +nn (n)nnnn nnn nnn)
  • Have a seperate county - code field, so they can still input their 'local' number. As something that is usually not included in their number, having it as a seperate entity is not user-unfriendly.
-1

One form field, such as the one presented in option one, is a better experience. You could make the input flexible by allowing the user to enter their phone number in whatever format they wish and using logic to clean it up for the database. For example, a user could enter 123-456-7890, (123) 456-7890, 123.456.7890, etc and they would all be valid.

  • 1
    This is just re-iterating my own answer. Please don't duplicate other answers unless you have something new or can expand / enhance such posts. Otherwise we'll just get people saying exactly the same thing in 100s of different ways. – JonW Oct 22 '14 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.