When a website or application has user input controls that validates the input, the user is (usually) notified in one way or another if the input doesn't meet the requirements. Eg. incorrect email address, input format etc..

The error is presented more or less clearly across the range of websites/applications. The quality of presentation is not however the focus of this question.

I'm interested in one specific aspect of how this user error is presented. That is whether the error should be visible until the user tries to submit the input again, or if it should be cleared as soon as the user manipulates the input in the control where the error occurred?

I'm not really interested in whether this should depend on how the validation is carried out, ie. in real time or on submission. But rather if the user is comfortable pressing the "Next"/"Submit" button when there's an error indicator present, for an error that may have been fixed by the user.

The reason I'm asking is that I've noticed that eg. Microsoft Hotmail has user errors present when composing an email even after the error is fixed. I would suggest that this is not in accordance with good UX. I would think that this could cause unease with the less experienced users, who may be searching for additional errors just because of a misleading error indicator.

Is there a good reason for the Hotmail approach that I'm not seeing?

EDIT: To clarify, it is this last sentence that I'm really interested in. Why would an application choose to display an error message that may have been fixed.

4 Answers 4


I believe users will notice what action made the error message appear and expect the same action to “check” the new input. Thus the same user action that triggers the error message should trigger clearing the error. If the error appeared on Submit, then clear it on Submit. If it appeared when the control lost focus, then clear it when it loses focus. If it appear as the user was typing, then clear it when the user retypes (or backspaces).

A case can be made to clear the error message before submitting, if it’s technically possible, but that’s true for showing the error message in the first place, and if you can detect corrections before submitting generally you should be able to detect errors in the same way, so the rule still applies.

  • I think this sounds very much like a line of reasoning that Microsoft could have had when choosing this design pattern. Commented May 10, 2012 at 12:27

I'm not really interested in whether this should depend on how the validation is carried out, ie. in real time or on submission.

Well this does have a bearing on the issue:

  • If the validation is only carried out on submission - on a login form for example - then you have to clear the error when the input changes. You've no idea at that stage whether the new input is correct or not. You have to assume it's correct until the validation has had a chance to occur and that's on submission ("Next" or "Finish").

  • If the validation is carried out in real time then you can - and indeed should - keep the error visible until it's truly fixed.

  • Yes Chris, I agree with that totally. But as I mentioned, the procedure of how the input is validated is not interesting to me. Of course real time validation would be preferable. But think of a login form, where the user enters a username and a password, the password is incorrect and the user is notified with a user error indicator. Now, should this indicator be present after the user has manipulated the input field? The input can't in this instance be validated in real time (at least it never should be) but only at submit. Should there be an error showing when the user clicks "Login"? Commented May 10, 2012 at 10:14
  • @AndroidHustle - I take your point, but the solution does depend on when the input is validated. In your example of a login form I'd clear the error immediately when the value changes and let the normal validation occur.
    – ChrisF
    Commented May 10, 2012 at 10:15
  • And I agree with you, I would expect the same behaviour. So then to my example, what could possible be the reason behind the behaviour of Hotmail to have the error showing even after the the problem may have been fixed? Is it just due to ignorance? Or could there possible be a valid reasoning behind it? I would not take Microsoft for a company that develops aspects of their GUI's on pure chance. Commented May 10, 2012 at 10:24
  • @AndroidHustle - I don't know why Hotmail doesn't clear the error. Anything I suggest would be speculation
    – ChrisF
    Commented May 10, 2012 at 10:31

If working with a pre existing system, when the validation is carried out will drive your solution, unless you can start from afresh.

I would say the sooner you can identify that the user has fixed the issue the better. In most situations real time error checking would be preferable and updating to confirmation when the user has resolved the issue. But there are situations where this may not be possible, such as on passwords.

In these cases you have a couple of options I can think of:

1 - continue showing the error until submit is clicked;

2 - Hide the error as soon as the user interactions with the object/the object loses focus;

3 - Once the user interacts with tht object/the object loses focus, there could be a way to communicate to the user that this field has yet to be validated (so is marked in a way that isn't right or wrong).

I would prefer options 2 or 3.

I would recommend real time validation/confirmation where possible. And I probably sound like a broken record but for confirmation go ahead and test different versions with users to find out which is the best solution.


Ideally, errors should be cleared when the text has been corrected. What this means is that error validation should be done by AJAX, which has the advantage of showing errors immediately too.


I'm not really interested in whether this should depend on how the validation is carried out, ie. in real time or on submission.

is critical to the question. Ideally, errors should be validated in real time, meaning that corrections to errors should also be done in real time.

Most validation is done on submission, just because that is easier. As long as it is clear, then that is not a problem. It should be possible to get a correct submission on the second go at the latest. If this is not possible - if the validation requires guessing a unique user name, for example - this should be done in real time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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