User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I am working on a form where the phone number is optional. What is the best practice regarding a validation mechanism that checks if it's a correct phone number (over 10 digits):
I‘d go with option 2 (validate the field if it has been filled out)
Option 1 (no validation) – users may provide an invalid phone number and means you cannot contact them as they expected.
Option 3 (warn the user it might be wrong but let them continue anyway) – this is interesting but a bit of a copout in that you think there's a problem with the phone number but you're not sure you trust yourself.
Really, the validation rule should be reliable and liberal in what it accepts. For example, accept extra spaces, dashes, slashes and brackets.
If you're worried that a liberal validation rule may mean users make mistakes then you can play back the user's answers for them to review before submitting the form.
On a side note, try to avoid optional fields by first asking users how they wish to be contacted (if this is in fact why you're collecting the phone number): https://adamsilver.io/articles/form-design-handling-optional-fields/
In my experience, every field is required unless otherwise indicated. This is a HUGE ongoing debate but in my experience and testing with my users I only show input fields that are required. However, if you do want to show an optional field, add an optional indicator.
Phone Number (Optional)
Treat it like any other input field. Once it has a value, it is now required to be properly validated. If it is not valid then you can show an error state under the input field.
The way you worded your question tells me you are a developer with some experience in UX. While you are designing you need to take off your developer hat. It does not matter how you will technically build this form. First design your form the way your users would expect to interact with it. Case in point, when a user clicks submit.... they expect it to submit, not see a modal/popup with more junk to read and make decisions.
Once this is done, then dive into how you will execute it. If not you will find your designs will feel technical appose to simple and delightful.
Note: Your error state example is not ideal. Design with Error Prevention first then design for Error Identification. In this case you are letting the user make an error. If so, once there is an error, you as the designer know whats wrong.... so tell them how to fix it. Better yet fix it for them or even give them options to resolve the error.
Telling them that something might be wrong just creates a unpleasant and confusing experience.
I think it depends on the actual design of the entire input form rather than looking at this field separately, but without any screenshots this would be my best guess at which strategy applies best in which situation.
If this is an input that is expected to receive a reasonable amount of entries (for example, you have a large enough user base or potential users) then the effort of processing it alone should suggest that validation for internal purposes would be worth the effort, hence you probably wouldn't opt for strategy one. And if you apply this strategy, from a user's perspective it won't make much different if they don't expect this information to be used (depends on why it is optional I guess).
Strategy two maybe be problematic if the data is incomplete, which could be the case when you have more than one input field for the phone number (e.g. country code + area code + phone number), and if you ignore incomplete input then you are doing some validation and processing of the data anyway.
Strategy three works if you don't have a large number of input fields, and you are validating each input field as the user is entering the information rather than right at the end, where it can be tricky to organize the input error information for a large number of input fields.
