Best practice with error messages say what is wrong, or how to remedy the error?

Question

I've had a quick search and probably explaining the situation is why I can't find anythign useful to help me. It's best to describe the sitation with an example!

Take a form where a user must input a positive integer. If they don't put in a correct value, say -1, the form will fail validation. Naturally you want some feedback returned to the user so they can fix the problem.

Should this error message explain what is wrong and why this field failed validaton, or the how to fix it.

E.g:

Field cannot be a negative number

or

Field must be a greater than 0

Ultimately both mean the same thing, and I understand it's an English language thing, but from a UX best practice perspective what is better. (Please note in my case UI limitations mean it can't be a combination of both)

(I also know that it could be a case of either are OK, just make it consistent through the UI).

Answer 1

From the UX perspective, you find someone who designs the error messages for you. If you can’t do that, remember that the user is a user and not a software developer. You stated a fact. Yes, your second choice that you believe tells them what to do, doesn’t actually. Instead tell them what to do, like “Please enter a positive amount for the number of widgets.” And not “this field”, but what it is there for.

And it would be really, really nice if your form doesn’t forget any input due to the correction. Make sure that the user doesn't have to go through all of a three page form to hunt down the field that's rejected. And as Greg said, make sure that people needing screen readers will hear the information they need and can act on it.

Answer 2

Don't blame the user for your errors

Note that the context where you want to show a error message may actually be wrong. You say:

Take a form where a user must input a positive integer. If they don't put in a correct value, say -1, the form will fail validation.

Aren't you in the control of the form in the first place? If you are, why do you allow the user to enter an invalid value, just in order to have a chance to blame him for that?

Instead of being mean to the user, prevent the errors before they happen. If this is a simple form with a simple text box, accept digits (and a dot/comma according to the current culture, if applicable), but no minus sign.

Don't show a error when you can avoid it

There are cases, naturally, where you can't be strict about the allowed characters. The value may come from a plain text configuration file, or the input control of a form may handle inputs such as “53*2-198” where a minus sign is perfectly valid as input, and only a negative value isn't.

In those cases, think about alternative behavior which doesn't involve blaming and finger-pointing. One such behavior is to default the value, for instance to zero. Sometimes it doesn't make sense whatsoever. Sometimes it does. Adobe Illustrator, for instance, when faced with a negative value as a width or height of an object, defaults it to 0.0001 mm. While the user rarely wants this behavior, a error message won't bring anything useful there.

Sometimes, the error is so obvious, that no explicit message is needed, and just highlighting the value in a specific color would be enough. One common example is the mandatory values, where the empty fields would be highlighted differently if the user leaves a focus without entering anything in them.

If a error is shown, explain what's wrong, and give suggestions

It's not one or the other, but both.

I have answered a very similar question on UX.SE. The idea is that you should start by saying what's wrong, and then suggest a solution. In a case where a given field has a negative number (for instance a value in a configuration file), the message would look like this:

The minimum threshold defined in stack.thresholds.min cannot be a negative value. Specify a value within the range 0..1000.

The message starts telling what's wrong—the value is outside the valid range—and then gives a suggestion that the user might follow. Or the user may do something else, like removing the value to set it to the default one, for instance.

Think why the error was made in the first place

Assume users are not completely stupid. They may make mistakes, but if a specific field gets a lot of invalid input, it is indicative of a problem in the interface of your application.

One example is a form which asks to enter your address, and gives a one-line field. Most persons would assume that they are asked to provide their email address, and would be surprised to see a error message telling that the input wasn't recognized as a valid postal address. Statistics about the error message being shown would highlight an issue within the user interface and give a chance to fix it.

Answer 3

When a program really knows precisely what failure the user made and how to fix it, then it should tell the user this. To my experience, such a constructive feedback is better received and helps the user most. Unfortunately, things are seldom that simple in reality.

However, in lots of real-world cases, a failing validation may involve more than one field, may have more than one potential root cause, or may have a few different approaches to fix the issue. Hence the program could only make guesses or suggestions how to remedy an error. In these cases, it is probably clearer for the user when the program

• first explains which validation rule was broken (in plain english, of course)

• and then either leaves fixing the problem to the user, or

• gives some suggestions how to resolve the issue (ideally a complete list, in case this list is not too long)

For example:

• for entering a date range, the end date must come after the start date. In case a user first entered a start date, then an end date before the start date, the program should not tell them "you need to enter different end date". Instead, a message saying "start date must be before end date" leaves it to the user which of the two dates they want to fix.

• or, when entering a postal address, in the US the program requires to select a state, but for other areas of the world, where not every country consists of different states, this requirement does not exist. So when a user select "country=US", but forgets to select a state, the program error message should not be "you need to select a state". A better message would be "For the chosen country, you need to select a state" (so leaving it to the user if they want to fix either the country or the state)

• another example: an field for a printer dialog where the user can enter the page range to print in some syntax like "1,2-5, 6-", for example: when the user enters a wrong character here, or makes a grammar error like entering something like ",-," , the program can inform them about the broken rule. But a suggestion how to fix a wrong input correctly? That would only be a rough guess, so I would not try to let the program giving such a suggestion.

This gets even more important when fixing the issue may involve data which is not accessible directly from within the current form.

So in short: try to give your best to make the program giving contructive feedback, but don't confuse your users by giving them wrong hints about the issue to fix.