Scenario: let's say we are talking about a simple form, which contains the following field types:

  • All fields are mandatory.
  • Number: only digits are allowed.
  • Text: text must not exceed the maximum length.
  • Email: must be a valid email address 'xxx@xxx.xxx'.

Preventing: make it impossible to enter an incorrect value by only allowing a valid input that follows the pattern, the submit button is only enabled once every field is entered correctly.

Explaining: allow submitting the form, check all the fields and generate a list of validation errors if there are any.

(On failure, user isn't forced to re-enter data. I guess everything should be preserved, since incorrect values could be really long and only require minor changes to be corrected.)

  • 2
    you need to double check on the server anyway because prevention can be bypassed. Nov 13, 2014 at 11:49
  • on failure, is user forced to re-enter all data from the start or they can proceed with the part that was already correctly entered?
    – gnat
    Nov 13, 2014 at 11:50
  • @gnat - I guess everything should be preserved, since incorrect values could be really long and only require minor changes to be corrected.
    – Den
    Nov 13, 2014 at 11:57
  • @ratchetfreak that is true, but what if it is a monolithic desktop app (for the sake of discussion)?
    – Den
    Nov 13, 2014 at 11:59
  • Entering an incorrect e-mail address is almost impossible to prevent, but you can validate it after the user indicated the entry is complete.
    – Bart van Ingen Schenau
    Nov 13, 2014 at 12:22

5 Answers 5


There are no absolutes in UI design, so it's impossible to say which is better in all cases. It depends on the data being input, the importance of it being correct, the difficulty in entering the data, the size of the form, the type of user, etc.

That being said, Preventing invalid input is generally the best place to start, but you need a belt-and-suspenders approach by also checking for invalid input during submission, unless your prevention code is absolutely bullet-proof, and you're certain absolutely nothing will ever get submitted except through your form and with your validation code enabled.

  • 1
    I'd rather never trust the validation on the client side. We, by definition, cannot fully control the client. A malicious user might use browser's built-in developer tools to circumvent your validation logic or simply send a request with all the right credentials. If an invalid value, especially a grossly invalid one, this can break your server code, you're in trouble.
    – 9000
    Nov 13, 2014 at 20:19
  • 1
    @9000: that's precisely why I said you also need to do validation when the data is submitted. But again, it depends on a lot of circumstances. From a user experience perspective, however, I think you need to start with trying to prevent bad data from being entered. Nov 13, 2014 at 21:07

I think it depends a lot on whether this is a very common form or a rare form.

If it is rare form, where the user might have little or no idea of what is valid input, I'd emphasize "explaining" a lot more. Since having the field just "beep" or "flash" on invalid entry will frustrate the user who doesn't know what they are doing anyway.

If it is a common form, familiar to the user, I'd emphasize the "preventing" more. They know what they are supposed to do, you just help out by preventing typos. A lengthy explanation will tend to just get in the way.

In practice, you should do some of both, but this is how I'd set my emphasis.


Should I prevent bad values or explain what's what's acceptable?

I find that neither A or B are singularly the correct answer, you need a little of both.

Why prevent bad values?

You know what pisses off a user... when you finish filling out a form, put away some information you wrote down, click "submit" and BAM error message saying your email was wrong, or password wasn't acceptable, or you skipped a required field, etc. As a developer you have to design your ux to assume your users are dumb as a bag of rocks.

Most of the times these mistakes are simply accidently fat fingering a key or not quite pressing a key down enough, etc. (honest mistakes)

Email address? If it's entered with no "@" put some red text next to it that says "A valid email is required" Why wait until I think I'm done and hit submit? (Don't clear the field out, that just pisses people off)

Why validate on the back end?

So we've made sure everything is on the up and up on the front end, why should I worry about the back end, shouldn't it all be handled by now? Yes it Should, but not necessarily. Good application design especially when considering any outside resource (webservice, user input, file system, database, etc) you want to assume that resource is volatile and dangerous (even if it's proven not to be)

Tons of reasons for this the backend could have multiple front end, bug prevention, security (primarily in limiting the scale of a compromise should you be victim to one), etc. This is the "trust no one" network mentality. Trust no one is typically inclusive of one's own resources as we all make mistakes and bugs happen, proper layered approach can prevent a minor bug in one place becoming a crippling bug on a large scale.

What I do

Generally I validate all user input on the front end as it happens, and prevent them from submitting at all (often through greying out the button with whatever's wrong nearby) then after it's sent I validate it in my business logic on the backend.

I do this because a lot of my input comes from multiple sources, some of which I personally oversee, others from third parties. Both of who I don't blindly trust. (that's right, I don't blindly trust myself. We all have good days and bad days.) I've not had a problem security wise, but I have had to slap third parties for sloppy validation. (which my backend validation caught)


Your second and third bullets (numeric only, maximum length) can be "preventing," because it's more or less clear from the context why the input box is not accepting the characters they are typing. Everything else is almost always "explaining."

The ideal, of course, is to both prevent and explain. If your user is running up against a character limit, it's polite to say so with some red text next to the box they're typing in (easily done in code-behind, since you're already monitoring the individual characters anyway). Same for numeric characters only.

You can't really know about the "required" fields until the user submits the page or form, and email addresses are difficult to validate while the user is typing them.

It gets a little more interesting when you're trying to prevent people from doing things that they don't have security permissions for. If a person does not have rights to the "deletion" function, for example, you can either hide the delete link, or show it and inform the user that they don't have permissions when they click on it.

The "explain" model in this context has the virtue of always showing the same control elements to everyone, in their proper positions, and is more self-explanatory. The "prevent" model is often simpler to implement, and some things shouldn't be shown to people who don't have permissions. It's the difference between "you can look but you can't touch," and "if you don't have permissions, you don't need to know about it."


Both are defensible. I will elaborate further as follows.

Prevention & Warning

  • Pros:

    • Helps the user avoid inputting lot of data again
    • Helps the user avoid inputting incorrect data quickly
  • Cons:
    • Often consumes more CPU resources (even memory) because validation has to run whenever there is a minor change in input
    • Hard to implement when there are complicated functional dependencies in the input. Think about a form with multiple fields, many depend on others


  • Pros:
    • Easy to implement correctly
    • Doesn't consume a lot of CPU resources
    • Easy to provide a thorough explanation and guidance to a correct input
  • Cons:
    • User may have to input some data again when explanation comes back
    • User is not warned of going into an incorrect data path, but I doubt this will happen often with well-normalized input data-design
    • Not as responsive and user-friendly as warning and prevention

Bottom line:

Use both, even in the same form.

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