Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

We are using 4 fields for phone number entry. We are supposed to support international phone numbers. Country_code1, Area_code1, Main_Phone, Extension1

We default and hide the country code field when the selected country is US. We also have an area code field, a phone number field and an extension field.

We remove any '-' from the phone number field before it is sent to our server so the phone number is formatted like this when it gets to our server:

cc-ac-number-ext , i.e. 1-800-9059912- (blank extension)

Should look like this in our DB:

Country_code1, Area_code1, Main_Phone,  Extension1
     1            800       9059912

Now, the issue is that a LOT of people are entering the first three digits of their US phone number in the phone number field and apparently tabbing into the extension field and entering the last 4 of their phone number there.

This cause the phone number to be entered into our DB like this:

Country_code1, Area_code1, Main_Phone,  Extension1
     1            800       905           9912

How would I fix the validation of these in order to also support international phone numbers?

Screenshot of layouts: enter image description here

This is how we do it on another one of our sites: enter image description here

SO I guess reorganizing the outputs may help somewhat. But client-side validation is still going to be problematic. We currently only test to make sure the number field is populated.

Here is the new planned layout vs. the current layout: enter image description here

share|improve this question
2  
Can you post a screenshot of your interface? It sounds more like a problem of not clearly labeling fields than a validation problem. –  norabora Jul 11 '13 at 22:29
    
Re international phone numbers and dashes, see ux.stackexchange.com/questions/23176/… -- it isn't necessarily straightforward. –  Andrew Leach Jul 12 '13 at 7:20
2  
@norabora Added screenshot of UI. –  MB34 Jul 12 '13 at 13:33
    
Do people still have switchboards and extensions? The number of companies in the UK who do not have DDI [direct dial in, where each extension has its own public number] is vanishingly small. Why not just get rid of that field altogether? –  Andrew Leach Jul 15 '13 at 18:17
    
Some PBX (phone) systems in the US offer the caller to enter an extension to be transferred to. –  MB34 Jul 15 '13 at 19:34

4 Answers 4

up vote 4 down vote accepted

I would give your user clear visual cues about what belongs in each field:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

The advantage is that it follows the pattern they are accustomed to but doesn't take up much more space than the current implementation.

Having the last box explicitly labeled as an extension should clear up any ambiguity as to what should be entered there.

share|improve this answer
1  
Well, I thought the "visual clues" were pretty evident in our layout. –  MB34 Jul 14 '13 at 13:12
    
I do kind of like this, however. –  MB34 Jul 14 '13 at 13:17
    
I have lots of designs that I still believe are evident but when you see users making the same mistake then they need some help :) –  Charles Wesley Jul 14 '13 at 17:11
    
Agreed and I will make the suggestion to the team. –  MB34 Jul 15 '13 at 2:12
    
See new screenshot added. –  MB34 Jul 15 '13 at 18:08

Remove static Extension field. Make checkbox 'Ext.' instead and display your Extension field when it's checked.

share|improve this answer
    
Now that's a suggestion we haven't thought of. –  MB34 Jul 12 '13 at 14:11
    
I'd suggest an [+Ext] button. Having [+] buttons on a form to add new fields is somewhat new , but the relevant audience (phone extensions implies white-collar employees) will have seen such buttons before. –  MSalters Jul 16 '13 at 12:40

Why do you need all those numbers separated? I can understand you may need the country code, but does it really make a difference to know which digits make up the area code and which ones make up the local number? What about people who have only a mobile number and don't have an area code, what should they write there? How will you deal with your already-gathered data when area codes change (e.g. cities grow and what was once part of the area code becomes part of the number)? I am speaking from experience here - my city's area code changed 3 times in the last 20 years.

I would rather ask the user to write their number in freeform, including the country code. Then I would parse the input to separate it into those fields. Parsing is not difficult: Country codes are public information, so you can find the longest matching code from the left of the entered number and separate the input at that point. You will be left with area code + number. Knowing which is the area code and which is the number will only help you if you have the infrastructure to call the user from a local phone. If you don't, there's no point in separating them. If you do, then you will know the area codes for that country already, hence you will be able to parse them just like with the country code.

share|improve this answer
    
I explained it in my question. The storage system is an outdated Oracle DB where we also have a desktop application that handles the numbers. We are leaning towards making it fully free form but I disagree with you about the parsing. You can't assume that a user will enter the numbers as a parser would view it and with the plethora of formats, it would be cumbersome to write a parser. Google's libphonenumber looks like the tool we will be using to do the parsing. –  MB34 Jul 14 '13 at 13:15
    
The only thing I assume is that the meaningful part of a phone number are the digits, and that you ask the user explicitly to give you the full number (i.e. with country code). The formatting of the number for display according to country conventions has nothing to do with what that number means, nor with how you save it in the backend. Before parsing, you just remove any non-digit character except a first + from the input. Google's library looks useful, however it does not solve the UX implications of the four boxes. –  Erion Jul 15 '13 at 8:36
    
I understand that the digits are the only meaningful parts of the number, we only store the digits, not the dashes or any parenthesis. But it DOES matter to storage on the back end if you must parse the number into different fields. Many users may not understand when asking to submit their full number including country code. Some of our users are really not very computer literate; I know it's sad these days. –  MB34 Jul 15 '13 at 18:11
    
This is the most likely option we will pursue. But it must meet approval, first. –  MB34 Jul 16 '13 at 15:56
    
Check this: code.google.com/p/libphonenumber It is an international phone number parser. I think that this (if it works, I don't tested it) fully implements @Erion's idea. –  Juan Lanus Jul 16 '13 at 17:54

As you had given the explanation here, the same you can specify besides the phone number fields so that the user can just have a look and then they can enter the number properly. This is from UX perspective.

From development perspective what you can do is just tell the users to enter the number without spaces/dashes and then the dashes will be added automatically after the fixed number of digits. (As Microsoft used to do it while entering the Product key in case of Windows Vista/7/8.)

Hope this may help you to get more ideas.

share|improve this answer
    
I don't know, just adding instructions is far from guaranteed to get the users entering data the way you want - you need something more active and subtle like the way you position and label the input fields. –  vincebowdren Jul 16 '13 at 13:26
    
And the comparison with MS product keys is unhelpful too - they are a fixed format which the UI and software can deal with relatively easily, but phone numbers are notoriously variable from country to country, from local area to local area, and even within an organisation. –  vincebowdren Jul 16 '13 at 13:28
    
I agree that the clues to entry must be VISUAL as well as in text. –  MB34 Jul 16 '13 at 15:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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