Our application is showing one error message at a time only, instead of listing all errors at once. The user spends much time clicking the OK button, fixing one item and then repeat.

Highlighting all the fields like in web applications is not possible in our application, so I expect at least a complete list of mistakes made in a message box or something.

I am aware of the issue and I'll report it, but I'd like to give the problem the correct name. If there's a UI design principle considering this issue, what's the name of it?

  • 5
    At this point in the development of the field of UX, appeal to common reason might be strong enough.
    – msanford
    Commented Oct 31, 2016 at 13:06
  • 1
    You could also mention the number of wasted journeys a user may need to make in order to fix all the errors Commented Oct 31, 2016 at 14:00
  • I think the more important principle that is being violated here is that fields are validated all at once instead of after they are filled. Commented Oct 31, 2016 at 18:06
  • I see problem here is not "How to show errors". Just simply go with bunch of errors. This is unncessary headache. The challenge here is "How to enable user to take action against the errors?"
    – Jivan
    Commented Nov 2, 2016 at 11:54

3 Answers 3


Two heuristics come to mind.

This rule from Jakob Nielsen's 10 usability heuristics https://www.nngroup.com/articles/ten-usability-heuristics/

"Visibility of system status - The system should always keep users informed about what is going on, through appropriate feedback within reasonable time."

Not having the full set of errors requires the user to guess at how many errors are left. In most cases it is helpful to provide error messages as close to when the user entered the invalid data as possible, so that they can correct it quickly.

Also, your users should be able to achieve their goals efficiently. When you are editing a form your primary goal is to save the information you have entered. If you need to click save each time to see the next error message this makes saving very inefficient. Luke Wroblewski http://www.lukew.com/ has a great book and presentation on form design best practices.


I did some more research and found the following (not repeating items of the answer given by @Jeremy Franck).

Principle of least astonishment [Wikipedia]

The user gets an error message and corrects the mistakes. After submitting again, he gets an error message again, for something totally unrelated which was never mentioned before.

IMHO the user will be astonished, thus violating the principle.

Principle of clarity [Bokardo]

This might not be a UX principle, but a communication principle. Anyway, an error message is a form of communication. I didn't find an original author, but it's mentioned several times in the web (e.g. here). On the Bokardo website it says:

predict what will happen when they use it, and then successfully interact with it

On the Invision website it's mentioned:

What will happen when you do it

This is not the case with several error messages. One would predict that after fixing the listed mistake, the data is accepted, but that's not the case.


It might violate the principle of sufficient information.

Many pieces of software still aren't particularly well-written, and they get confused easily. So they can emit a dozen or more "errors" where every one but the first is an artifact of that first one, and therefore spurious. But to an experienced person, seeing those "errors" can be helpful in debugging.

On the other hand, if these are errors shown to the naïve end-user, there can be a legitimate reason for only showing one at a time. If only the first one is real, and that one is corrected, then none of the others should ever be shown because they're not genuine errors (except in the sense that the software should be better at resisting becoming confused).

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.