“Doesn't look like a valid…” versus “..is invalid”

Question

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"

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.