I'm trying to redesign the forms on our web app and run into an issue with inline validation messages. I started with putting the error message in the top right corner above the input and this worked initially, but then I realised on a smaller screen this was causing it to overlap with the label and then jump onto a new line, so I'm now looking at alternatives.

In terms of the UX of inline validation, is it imperative that the error message itself is always shown? When I first started looking at this part of the system, I tried a few options such as putting the validation under the input, in popups etc but they all had their issues:

  • Under the input caused other inputs to move down the form when the error was displayed. This didn't feel very nice?
  • Popovers covered content or again caused things to move
  • Message inline with the label breaks when too small

So what I'm considering now, is to have the input show that its in an error state with the usual red border, and then place an error icon somewhere, but don't show the error message itself all the time. Instead, this would be shown when the user either focuses on the input in question, or hovers over the error icon.

Would this work from a UX stand point, or is it better to have the error visible all the time?

  • Adding the error message underneath the input field is the most common. You should always keep the error next to the associated input field to avoid confusion. – Wanda Sep 14 at 8:45
  • That's what I had originally, but is it alright that the form jumps when it gets displayed? All the inputs shift down to accommodate the space needed, and the only way around that was to increase the space between inputs which just felt like wasted space – PaReeOhNos Sep 14 at 8:58
  • As far as I know it is perfectly acceptable to have content jump because you add a layer of new content, whether thats an expandable panel or an error message that's causing this doesn't matter. You can always prototype this with principle or other tool to see how it feels. I find it not jarring or unusual to have error messages push content down. – Wanda Sep 14 at 9:05
  • Good to know, will experiment with this. Would it be bad practice to also change the error location sometimes? I recently read an article saying people prefer to had error messages to the right of an input, but this isn't really possible when the input is on the edge of a screen so under it would then make sense – PaReeOhNos Sep 14 at 9:10
  • @PaReeOhNos Wanda is correct. Movement is a very good way of getting the attention of the user. In general moving controls are bad because they are distracting, but in this case I think the movement merely acts to draw the attention of the user to the error. – Franchesca Sep 14 at 9:12
up vote 0 down vote accepted

There's a few guidelines you should adhere to when designing error states.

Error messages:

  • Should primarily avoid confusion.
  • Should communicate what is happening.
  • Should describe how the user can fix it.
  • Should be short, but meaningful.
  • Should display at right time and place.
  • Should have right color for the message.

This means you need to connect the error message to the 'offending' input field. It's not enough to show that something is wrong, users also need to know immediately how they can fix the situation. Placing the error message below the input field ensures a clear hierarchy; first the incorrect input, then how to fix it. The rest of your form will 'jump' a bit if you use this type of error message layout, but this serve as an additional cue for the user that something needs his attention.

So what I'm considering now, is to have the input show that its in an error state with the usual red border, and then place an error icon somewhere, but don't show the error message itself all the time. Instead, this would be shown when the user either focuses on the input in question, or hovers over the error icon.

Remember that the hover state doesn't exist on mobile, so you cannot hide crucial information behind it. It's best to just shortly describe the issue and the fix for it right below the input field. This approach will also work on mobile.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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