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.

I'm not designing anything at the moment but this thought popped into my head earlier. What do you think would be the pros/cons of wording validation errors as:

"This doesn't look like a valid phone number"

vs

"Phone number is invalid"

share|improve this question

6 Answers 6

Which is better? That depends on how strict the validation rules are. If there are edge case phone numbers that don't fit a general pattern, and the user can in fact successfully submit the form with that "is a phone number but doesn't look like one", then you you need to take that into consideration as to what messaging to provide.

Assuming you don't actually have restrictive requirements for the input then of the two example messages the first is friendlier.

Even better would be validation error messages that provide actionable help. That is, the error message provides direction to validation instead of simply pointing out that something is invalid.

One of Jakob Nielsen's usability heuristics applies here:

Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

For example: "Phone number: should be 10 digits and include the area code. Punctuation is allowed." (vary the message per your locale and requirements, of course).

Also, you want to put the name of the field in error at the start of the error message to better support screen readers etc.

share|improve this answer
1  
"should only be 10 digits" will depend on your locale. In the UK phone numbers are mostly 11 digits long, but there are variations. –  ChrisF Nov 20 '11 at 12:40
1  
I usually prefer to see the actual error "is not Y", rather than "should be X" in error messages. Way too often, websites add non-obvious validation checks and stick with a vague "should be X" message. –  dbkk Nov 20 '11 at 16:14
    
Thanks @ChrisF, I've clarified my answer to show that "10 digits" is just an example. –  Erics Nov 21 '11 at 5:44
    
@dbkk - agree if the X in "should be X" is simply "a valid number" without explaining what a valid number might be. Vague error messages are bad whether they say "X is invalid" or "should be a valid X". –  Erics Nov 21 '11 at 5:47

The latter - "X is invalid" - should only be used when you are 100% sure that the data is wrong. This commonly applies to "internal" restrictions, for example if usernames should be 4-20 alphanumeric characters. You can confidently say when the user enters "my!username" that it's invalid (against your restrictions; whether you should allow usernames with alternate characters is another discussion).

For most common data like names, addresses or phone numbers, there is always an edge case you didn't account for. Here you should accept any format, but it is useful to show warnings to users in case they mistyped.

share|improve this answer

Neither - tell the user what is wrong, as Erics has said. If you specify the problem in an English version of what you are validating for, it makes it clear what the issue is, and is then not pejorative about the users input.

"The phone number is invalid" may be incorrect - the phone number may be valid, just not acceptable in this environement.

"This does not look like a valid phone number" - again, this is subjective. I prefer it to the first one, because it at least implies that it may be correct, but, as Roger Atrill pointed out, the implication is that the user should check it, but the system will accept it anyway.

"The phone numnber must consist of 10-12 digits, with no spaces, without the international dialing code" or similar makes it clear to the user exactly what format they need to enter this in.

share|improve this answer

The first message should be given as a warning, not an error. In certain cases you may want to accept something that is probably wrong, but just very possibly not so. For example custom protocol prefixes for urls (like chrome://), internal phone numbers (that don't have 10 digits), e-mail addresses that have explored the full depths of the specs (including quoted strings for example.)

In all those cases I think it is fair to warn them with message one, but, allow for them to say "I know it looks wrong but trust me on this."

If you reject an input, it's better to be specific why, so people can fix it.

share|improve this answer
5  
Agreed - "This doesn't look like a valid phone number" is to say do you want to check this in case it's wrong, and I'll accept it if you're sure, but I think that's not what would normally be meant (by the application)? –  Roger Attrill Nov 20 '11 at 10:36
    
I've always felt that "Phone number is invalid" is so direct that it needs to be possible to dispute the statement as an end-user. What if it really is valid and the input validation is broken? Perhaps providing a subtle but visible "yes it is/report problem" link would be useful as part of the extended help that tells the user how it should look? –  Oskar Duveborn Nov 21 '11 at 15:16

Make it simple, make it stupid simple and fast to understand and recover from the error.

I believe that the option with least cognitive load (least processing time to understand the sentence) would be the best.

share|improve this answer

I think you have to take a look at what you want your application's persona to be and then determine how the errors should be displayed.

A lot of UX teams make personas for their users, but don't take the time to actually make a persona for the application - is it friendly and informal, or is it strict and professional? Thinking about these things helps determine what the proper copy should be.

share|improve this answer
    
Interesting response –  Kenny Evitt Nov 22 '11 at 1:02

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.