I'm working on a web application that will be used internally in an organization. The application will ask users for multiple pieces of contact information. We will allow them to optionally enter a mobile phone number. We also will ask for a phone number to which they would like to receive text messages.

It is likely that the number they would wish to receive text messages on is their mobile phone number. However, in the event that it is not, we would like to ask them to enter a text message number as well.

I could see designing this such that the user enters a mobile phone number, and the user has the ability to indicate (via a checkbox for example) that the text message phone number is the same as the mobile phone number. Doing so could disable the input text box for the Text Message number, and populate it with the mobile phone number that was entered. Unchecking the box could make the input text box editable again and remove the auto-populated value. One flaw I see with this design is that, since mobile phone is not required, checking the "Same as Mobile Phone" checkbox if Mobile Phone is empty would be useless and potentially confusing if the field becomes disabled.

Is there a better way to do this, or another way you have seen it done? Is it easier to just have the user type in the number a second time? Ideally we would like to reduce the amount of manual entry, while also reducing the likeliness of error (user typing in the number incorrectly).

Example wireframe

6 Answers 6


Avoid the complicated question: "*Can we have a phone number and by the way, is this is a number you want to use for text messages because if it isn't then can we have another number that is, and by the way we're not going to tell you whether the text messages are optional, even though the phone number is**.

Just keep it simple. There are two things you should be clearly asking of the user.

  1. can we have a phone number
  2. do you want to receive text messages

(What is not clear is whether you might want to actually call the user or are you just going to text them?)

It's bad enough that you are asking the user for a phone number (ok so it's optional) - very few forms do, and of those that do, most give a reason (Why do we need this), because it's one piece of information that users are very reluctant to give. I would make it clear why you want the number and I would ensure that you ask only for one number and not potentially seem to ask for two, when in reality, you'll be happy with one.

So your form should have a field for the mobile phone number, making clear it's optional so there's no pressure to do this. Then have a check box that says 'Receive texts on this number', but disable it until a number is entered.

  1. If the user doesn't want to give a number at all, they won't be bothered about the matter of texts.

  2. If the user doesn't want texts they won't check the box.

  3. If they are happy to receive texts, they will enter a mobile number in the phone field.

enter image description here

  • 2
    In this case, I don't think the form has to be shy about asking for a phone number, as it's an internal form in a business context. I suspect it's used for an employee contact directory. As such, I wouldn't say the form needs to be too coy in its requests. In this case, I think its conversation could be a little different. Aug 9, 2011 at 10:07
  • @Jimmy that's a fair point and it did occur to me, although I chose to generalize the response, as it just seems simpler all round, including this scenario. But it also made me wonder in this particular instance why it was even optional? Aug 9, 2011 at 10:19
  • This seems like the cleaner solution to me. Is it a problem that the two numbers are ever different? If so I might embellish this solution to have the option to add a additional phone numbers (not just a mobile phone) and so that way you can have any number of contact phone numbers and just click the box to receive texts on the appropriate one(s). Aug 9, 2011 at 13:38
  • Yes, the data is employee data for internal use only. It will be used for a system that will send messages to employees in the event of an emergency. Users can enter as many pieces of contact information as they would like to be alerted on.
    – Jessica
    Aug 9, 2011 at 13:56

enter image description here

Make the 'Send Text Messages..' checkbox appear only if a valid Mobile Number is entered in the 'Mobile Number' field.

Case I So the user enters the Mobile number and then moves to the checkbox. If he 'selects' it, then we populate 'Text Number' field accordingly and make it 'read only'.

Case II If user doesn't enter Mobile number field; He sees no checkbox. He can still enter the 'Text Mssg' field.

This should stop errors and confusion from setting in.


Does it happen often that people want to use a separate phone number for text messages? If not, focus on the default case with just one number:

enter image description here

And wait with the second field till needed:

enter image description here

(Similar pattern as you often see in webshops, in the part where you can optionally choose a separate billing address.)


I'm still not convinced there's a case for two separate numbers. Yes, a user might prefer two, but that's very rare, and I just can't justify burdening other users with an overcomplicated form. Remember, you can always provide an opportunity to provide more details later.

If you must do this, provide a form (possibly offered later) that lets people enter additional phone numbers of any sort (including multiple landlines), and give them the ability to assign priorities and flag one in particular as 'textable'. At least this time the extra complexity can at least cater for the use case of 'businesspeople with many phones'.


My two cents:

Mobile number
[ ] Use a different number for text messages?

if checkbox is clicked, show the other field:

Text number

Make the phone number field agnostic, adding additional blank inputs as the user fills them with phone numbers. Then place a "text messages?" tick box next to each one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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