I've seen quite a lot of research on form design, but so far, I haven't come across any studies on error message design best practices. The only piece of advice seems to be that each error should clearly be associated with the invalid form field that it aims to correct. Has there been any research on this?

I have some specific issues I'm trying to work through and would appreciate any insight or resources.

Error message location

When you have live form validation, where should an error (or success) message appear in relation to the form element?

Some options:

To the right of the input


download bmml source – Wireframes created with Balsamiq Mockups

To the right of the label


download bmml source

Above the label


download bmml source

Below the label


download bmml source

Below the input


download bmml source

There are some thorny issues that also need to be taken into account regarding location:

  • How are errors displayed for radio or checkbox groups?
  • How wide is the error message?
  • Is the error message multi-line?

Error message visibility

Besides location, I'm also interested in how the visibility of the error message affects its usability. Does it matter or is it strictly a aesthetic decision? Consider the following 3 options:


download bmml source

Edit: There have been some excellent points on accessibility in some of the answers so far, as well as some interesting examples. However, I really would like to see some data from actual studies, if possible. Also, none of the answers so far have really addressed the two questions I had above:

  • Where should the error be located in relation to the input and label?
  • How does the design and visibility of the error message itself affect its usability?

Regarding the accessibility of the forms, it seems to me as if there might be two potentially conflicting use cases, live validation and server-side validation (which would require reloading the page). If the page is reloaded and the user again starts at the top of the form, an error summary makes sense, especially from an accessibility perspective. However, in the case of live validation, the error summary at the top makes much less sense, both for form design and for accessibility purposes.

Consider how a user would actually use a form with live validation:

The validation occurs on the blur event. Usually, the focus of will be on the next form element, not the list at the top. As I understand screen readers, there wouldn't be any reason to return to the top of the form to read the error list. For users not using screen readers, the error list at the top pushes the entire form down, doubly so if the error takes up vertical space near the form field as well. In longer forms, this is a usability issue as the error summary may not be visible. In shorter forms that have per-field errors, like a login, the error summary just looks like overkill. For all forms, the interface would be pushed down, making a poor user experience.

For live validation, if you really want to make the form errors accessible, I think using ARIA Live Regions might be the preferred solution.

  • As far as location: no studies, but from personal preference at least, the "Above the label" and "Below the label" examples don't work for me (either the message or the label gets too separated from the field). The "Below the input" is OK, providing it doesn't get confused with any input field below it. My preference, if space permits, would be "To the right of the input".
    – TripeHound
    Commented Jun 14, 2016 at 14:57

19 Answers 19


Encapsulated flags are the only solution I've found that reach all edge cases. Pointing the flag at the label rather than the input allows for consistency with radio buttons and check mark groups or weird inputs like sliders or sorters.

Highlighting the field with red is also helpful, but not always possible. Example usages below.


download bmml source – Wireframes created with Balsamiq Mockups


download bmml source


download bmml source

In reading @jonW's answer, I could not agree more with his thoughts on screen-readers, and my solution can be equally as effective depending on implementation. You can place the flags just north on inputs in the markup, and use aria to achieve the same accessibility

"Inline Validation and Validation Events" section on this page seems about ideal: http://semantic-ui.com/modules/form.html

  • 31
    One of the problems with this approach, however, is that it obscures the input. Commented Sep 27, 2012 at 0:56
  • 12
    I like the look of the tooltip error, but I think there may be multiple problems with it. If the error disappears on focus, before the field is proven valid, that can be a usability problem as well as the user may want to reference the error while they are typing. I'm not sure, but I suspect there might be some problems with mobile display too, depending on how its implemented. Also, ignoring the live validation for a moment, how would you display errors if you only had server-side validation? Commented Sep 27, 2012 at 1:25
  • 7
    Anything the user would need to reference while typing should not be in the error flag, it should just be part of the page. Otherwise, how are they supposed to get it right the first time? Commented Sep 27, 2012 at 1:29
  • 1
    As for server-side validation, I would do it with an ajax submit, and use the server response to activate the needed changes to the dom, but that is more of a stackoverflow question than a ux one. Either way, a full page refresh for form validation is not a great experience compared to ajax. Commented Sep 27, 2012 at 1:31
  • 2
    Agreed on the reference point, but I'm writing a custom plugin for public use, so I can't guarantee that the error won't contain vital information and would like to use best practices by default. Ajax and live validation is definitely a better user experience, but my comment on server-side validation was mainly meant for use cases where JavaScript is disabled. Ideally, the fallback server-side errors would be styled the same way. Do you have any comparison or conversion rate data for your method versus other methods? Commented Sep 27, 2012 at 1:36

It seems you're already marking optional form fields instad of required ones. There seem to be no 'required' indicators, but no 'optional'-indicators, too, so I wanted to mention that.

What I like to do on forms is to "micro-gamify" them: For every field in the form provide a "validation-indicator". For simplicity, let's say it's just a small circle. This starts off on a neutral position: A grey circle with a question mark. For optional fields, it's a grey circle with a checkmark. Whenever the user leaves a form field, it's live-validated and the following things happen:

  1. the indicator changes to either "success", e.g. green circle + checkmark, or "error" (e.g. red circle + exclamation mark)

  2. if there was an error, the field is highlighted

  3. if there is an error, the submit-button will grey out (clicking it will still work, but it only will take the user to the first error) and a general information message will be displayed above it.

If you're writing good hints it should suffice to just highlight the field and the hint. If you feel like you need a separate error message, chances are your hints could use some work. In my experience it is almost always possible to cover user input errors with good hints.

enter image description here

The user doesn't like to mentally go back in a form. It is processed field by field, the user focuses on it field by field, and goes through a mental checklist. By pointing out errors as they happen we support this mode and do not make the user go back "later on". It's a break in the flow of the user and an annoyance to click "submit" and then be "blocked" and "sent back". It's a much smoother experience if problems are just highlighted, and thus can be corrected, as they happen.

  • 5
    These forms are wildly nicer than pressing submit and getting pissed off. Commented Oct 2, 2012 at 2:16
  • Very nice approach. But not always possible consider a money transfer form in an internet bank web site. The user enters an amount, which is valid in the format we show him an smile but logically the number is not correct as he does not have the amount in his account or lots of other business rules. The case may be more complicated if the transfer form is a three step form and you can not check the amount until user pass all form steps. The user then claims that he got an smile for amount in first step but then the system says that the amount for transfer is not valid. Commented Sep 26, 2014 at 9:10
  • @AlirezaFattahi do you know Ajax ?
    – Preview
    Commented Oct 3, 2014 at 7:54
  • 1
    @Aperçu this is not a problem which can be solved by Ajax. Please consider that the form is multi-step Commented Oct 4, 2014 at 10:06
  • 3
    I dislike forms that are too eager to flag errors. Sometimes I may need a second to think what about value to fill. Or I may need to refer to something else (like a Google doc). Pointing out errors too quickly is rigid, and implies that the user must bend to the software, not the other way around. One of the advantages of software over, say, a human asking you a series of questions, is flexibility. Let's not lose that. Commented Mar 29, 2015 at 11:50

The error message should appear before the form field itself (at a minimum in the markup itself, but ideally visually shown this way on the screen too) so that when someone is reading the form they read that the field has errored before they then read the field in question - that way the user is prepared mentally that "the contents of this field I am about to read is incorrect and I therefore need to amend it".

This is even more important for creating accessible forms. If someone is reading the form via screenreader they need to be presented with the error before the form field is read out for the same reason as detailed above. (They don't want to have to go back after hearing the content of a field and then being told that field had an error). This is why it is the label of the form itself that needs to contain the error text, and not just be a popup or scripted alert because you can't guarantee that screenreaders or older browsers will be able to detect this text.

Also, if it's a long form, or if the user is browsing via keyboard and using the Tab button several of the fields may exist below the fold, so if you Tab down the form you might not notice that a field is in error until you have then tabbed into the next one (the field will scroll into view but if the error message is below it the error might be displayed off-screen).

Finally, there is an additional route you probably should take for your error messages:

You should summarise the errors right at the start of the form so that the user knows how many errors there are, and what those errors are. Really these should be links that jump you down to the errored fields in question (yet another reason why the error message against those fields should be before the field itself)

Much of this information can be found in the WebAIM article: Usable and Accessible Form Validation and Error Recovery

Here is an example. The errors are displayed at the beginning of the form and are also links so the user can easily navigate to the fields in question, where the error text is also displayed:


download bmml source – Wireframes created with Balsamiq Mockups

  • 1
    Interesting idea on the linked error summary at the top of the form, I don't think I've seen that before. I think it might lose some effectiveness on longer forms, though. Being as I've never seen it in the wild, it might cause some confusion too. Commented Sep 27, 2012 at 9:12
  • Regarding your placement of the error directly after the label, are there any data or studies that show that this might be the preferred method? Also, great points on accessibility. Commented Sep 27, 2012 at 9:14
  • 1
    @VirtuosiMedia The error isn't directly after the label, it's part of the label. (At least in the markup). The label itself needs to update to make screenreaders aware that the field is in error. I'll update my answer to highlight this point. As for studies, no I don't have any I'm afraid. I've taken accessibility best-practices as the main starting point for this form example. It can be enhanced with script certainly, but I'd be concerned that some studies may find a form that does something totally differently gets really good test results but from a totally in-accessible form.
    – JonW
    Commented Sep 27, 2012 at 10:14
  • 2
    +1 for the link @JonW! My organization requires that we list all errors somewhere together, so it's not uncommon, @VirtuosiMedia. Here's two other sites that recommend putting a list of all errors at top: Smashing Magazine Form-Field Validation and Adam Kalsey Simplified Form Errors Commented Oct 1, 2012 at 13:28

There is an old (2007) white paper presented by Human Factors International that has some data about error messages. The conclusion they came up with then was:

...most users go through a completion phase—in which the goal is form completion—followed by a correction or revision phase, in which errors are corrected...immediate errors were largely ignored until the form was completed.

Thus, of the six possible ways to present error messages, these three proved more effective than the others.

  1. Present the errors afterward, embedded in the form, all at once
  2. Present the errors afterward, embedded in the form, one by one
  3. Present the errors afterward, in dialogues, one by one

Obviously we wouldn't do number 3 anymore. The white paper is called "What we have learned: Looking back at 2007." You can download it from their site, after filling out a form. :)

It doesn't really talk about placement of error messages, except dialog vesus embedded, so not sure if this is really helpful.

  • Interesting information, but let's keep in mind that it's at least 6 years old. Habits change and people adapt to changes in workflow pretty quickly once it becomes common.
    – user12741
    Commented Nov 6, 2013 at 10:29
  • 2
    I agree there is a lot of outdated stuff. Here's a good description on how to handle error in forms and the physiology behind it [uxmovement.com/forms/… to Make Your Form Error Messages More Reassuring
    – Paul
    Commented Jan 15, 2014 at 10:09

Just above the submit button, there could be a list of mandatory items in the form of tags. Each tag should be hyperlinked to the respective field. As the user starts filling the form from the top, the tags keep disappearing. Before the user hits the submit button, s/he can verify if all the mandatory fields have been filled or not. If s/he has missed some item, s/he can easily scroll back to the field by pressing the appropriate tag.

  • 1
    Interesting idea. Has this been implemented anywhere? Do users respond well to this? I'd love to see this in action to see if it is a good option to go with. It might depend on how many fields there are in the form though - a mortgage application form would just be full of tags everywhere, but smaller forms may be more suitable.
    – JonW
    Commented Oct 3, 2012 at 14:36
  • @JonW: I haven't seen this idea implemented anywhere. When I saw the question, I thought how I will solve it and I came up with the above mentioned solution. I would be happy to discuss it further if you are interested. Commented Oct 5, 2012 at 14:32
  • 1
    One advantage of this idea is that the user can never hit submit and not see the error because it has scrolled off the screen, something that a lot of the highly voted answers seem not to account for.
    – Gus
    Commented Jan 25, 2014 at 19:27

What I am about to suggest is merely what came to mind as a solution that I would use when I read your question, so clearly you may not find any related research or material to substantiate it.

I am specifically addressing the question "When you have live form validation, where should an error (or success) message appear in relation to the form element?"

What if we show the message instead of the label itself something like

enter image description here

As and when the errors are resolved (considering they are the form level client side validations) you may revert to the original view of the labels helping the user keep a track of the remaining ones.

For this approach to work you may want to carefully word your messages to convey completely what the user needs to do in the least possible words. If the messages are long you can wrap it to the length of the fields.

  • 1
    new idea, just not sure how confusing it could be to users seeing the original label gone and replaced with red error message.
    – Mo'ath
    Commented Aug 2, 2018 at 15:21

As the question concerns real studies' results, here is a link to a 2009 study on different variations of validation messages by Luke Wroblewski (author of Fill in the Blanks).

It provides very interesting insights into how best to display validation messages, some of which might interest you. For example,

[ON BLUR] METHOD HELPS USERS TO COMPLETE FORMS MORE QUICKLY When we used the “after” ([on blur]) method..., participants completed the form seven to ten seconds faster than when we used the “while” ([on keystroke]) and “before and while” methods respectively.

As far as the position of the error message, the study reveals that

NOT FADE AWAY—KEEP SUCCESS MESSAGES PROMINENT OUTSIDE FORM FIELDS Displaying validation inside form fields failed to deliver any substantial benefit. The positioning of these messages was—necessarily—inconsistent. (While it’s possible to make validation messages appear inside form fields, it is much more difficult to display them inside standard drop-down lists, so we displayed them outside these elements.) In-field validation was not any more noticeable than messages displayed outside the fields.

2- Concerning the message visibility (color, etc.), here is another article suggesting UX Designers to tone down the severity of those messages and actually make users feel good about their progress (and not frustrated over their no-progress)

Among other things, it basically says that we should use orange/orange color for form error messages: enough alarming when users see it but less physically stimulating as red (likely cause them to panic).


Good suggestions were made regarding the summary of required fields above the form as a recall.

I would say that a the very first example shown here is a rather good one (error message next to the filed itself). You migh want to highlight the field in red as well but it is not proven to be more effective.

Now regarding the radio buttons issue, I would say that if you need such an error message for a radio button, it means that the radio button is not the right design option on the first hand: indeed, by essence, a radio button MUST have and SHOULD ONLY have one single option selected by default. This means that a radio button should always present a default option selected, whether it be a "none" option. In any other case, you should consider using any other design option that fits your needs (eg.: checkboxes if several options might be selected, or dropdown menu or whatever).

  • Good point about the radio button having a default selection. I overlooked that in my answer so I'll update my example. This is a W3C requirement.
    – JonW
    Commented Oct 1, 2012 at 10:04

After reading Web Form Design: Filling in the Blanks and researching about this on the web I found out that the best ones are under the input or to the right of the input.

Also the presumption that * = Required is not always right, some people don't know that. Most popular way of doing it is having explanation what * is at the top of the form. Or my favourite is getting rid of all unrequired fields and having "all fields required" or something similar at the top of the form.


I have not run across any studies on where the best place to put validation messages is. However, from a practical standpoint, I think user interface guidelines are close enough. Microsoft is well known to have done quite a lot of first-hand research in their usability labs for the information in their guidelines. As much as we all like to pick on Microsoft for some poor UI practices, generally those practices did not follow their User Interface Design Guidelines :)

So... Microsoft's Windows User Experience Interaction Guidelines essentially chooses an asterisk to the left of the label and a tooltip with the message:


download bmml source – Wireframes created with Balsamiq Mockups

The guidelines also makes some insightful points, that I have summarized below:

  • If most controls are optional, don't indicate anything (Handle missing required input with error messages. This approach reduces clutter.)
  • If most controls require input, indicate optional inputs with "(optional)" after the label.
  • If all controls require input place "All input required" at the top of the content area.
  • Validate input early, show errors near the point of input.
  • Use popup balloons for user input errors that can be detected immediately. *Balloons don't require available screen space or the dynamic layout that is required to display in-place messages.
  • Display only a single balloon at a time.
  • Use in-place errors for delayed error detection (e.g. after submitting a form).

Interestingly, there is not much detail in the Apple Human Interface Guidelines on this topic, but below is a summary of the relevant points that I found:

  • Validate input early
  • Avoid validating input after each keystroke. To frequent validation is annoying.

Again, while I realize these are not "studies on error message design best practices", I am sure research went into the formation of these guidelines and as a practical tool they are a great point of reference for this topic.

  • +1 for the links. Just a little confused, your text says "to the left of the label", but your example mockup doesn't show that. Which way did you mean? Commented Oct 11, 2012 at 0:17
  • Thanks for the feedback. I meant that the Windows User Experience Interaction Guidelines recommends an asterisk to the left of the label. I have updated the text to further clarify. Let me know if something is still unclear. Commented Oct 15, 2012 at 19:13

Marking required fields with * or marking which fields are optional with (optional) - which is best depends on the tipping point in the form.

If you have a long form - say 40 fields (to exaggerate -I'm not suggesting a form should have 40 fields on one screen) and of those 40, 36 are required then marking 36 with * is both noisy and becomes redundant.

It is far simpler to make a statement at the top that 'all fields are required except where marked optional'. Conversely a form with relatively few required fields should indicate the required ones.

In other words which ones do we need to highlight as the exceptions.

The trend toward public facing web forms is toward only asking for the required information to reduce drop off rates, hence the move toward marking optional rather than required as they all tend to be required. This is not always the case on corporate/business systems though were there are legitimate in depth forms that contain legitimate optional and required fields.

With regard to the main question of placement of error message:
It is dependent on the design layout of the form in regard to label->fields.
Assuming the label over field I would put the error message to the right of the field and provide as many visual cues as possible, such as highlighting the field border in red as well as the 'this field is required' in red.

1) proximal placement of error message to field
2) does not break the proximity and association of the label (which putting the error between the label and field would)
3) your error message is acting as a signpost to what needs fixing (the text indicates how). In this sense you want your signpost to be an arrow pointing to the actual thing the user needs to take action on, which is the field, not the label.
4) tooltip type messaging is not a well established convention and as someone else has pointed out runs the risk or covering over items (unlikely I an actual tooltip where the user takes an action to do this) - it is also unlikely to be good for accessibility.

My initial impression of the face style icons + highlighting + message is that its sensory overload. I'm not sure where my eye should be focussing to get the information. The field is what needs fixing in the middle but there's visual information vying for my attention before and after this, which means a lot of eye movement and effort for the user to digest the meaning (Pure hypothesis, I've never run user testing on a form set-up quite the same)

  • 1
    Hi Glen. I think you're focusing on the wrong part of the question - OP is asking about the positioning of the messages, not about what the message should be or about whether it is Required or Optional. The question would still be the same if OP asked where the 'This field is Optional' message is to be located.
    – JonW
    Commented Apr 5, 2013 at 9:59
  • my comment was specifically in response to this: "Still the traditional way of marking mandate fields with "*" is the best"
    – GlenFinch
    Commented Apr 5, 2013 at 13:29
  • 1
    Ah, so you're responding to another answer, not leaving an answer to the actual question? I'm afraid that's not really how this site works - we can't do threaded comments - that's more for forums. Answers should explicitly answer the main question. Once you receive 50 rep points then you can leave comments against posts, but really it's Questions and Answers that should get the focus, not comments.
    – JonW
    Commented Apr 5, 2013 at 13:36
  • edited and updated accordingly. Had to rush to airport hence didn't post full answer earlier.
    – GlenFinch
    Commented Apr 5, 2013 at 13:49

Unfortunately, there doesn't seem to be a "standard" way of displaying an error for a from, which was the original question.

I tried searching for a more detailed answer, but I think there isn't a definite solution because there are so many different styles of forms. Forms viewed on a desktop will generally have more space for error text than a form on a mobile device. Recently, you have to even think about what operating system you are designing for now that the Windows 8 modern style (formally Metro) has specific style guidelines for IE. Add in the fact that each modern browser has its own style for HTML5 form validation, and standardizing this becomes a mess.

The most I could find was a set of guidelines from Jakob Nielsen (http://www.useit.com/alertbox/20010624.html). These guidelines are very broad, with the only explicit rule being that you cannot only rely on color (turning the text for field red) because that can make it hard for users with disabilities to read. Color-blind users or those using screen-readers would not be able to differentiate the text.

That is the only reservation I have with the callout solution also posted here. Would users with disabilities be able to read it?

A solution could be to either adapt a style that is used by the majority of your targeted users (either Microsoft, Google, or Apple) and go with that.


sharing one of the approach which I designed for very Form intensive project and it was appreciated by team but because of some constraint we couldnt build it.

Interaction - the moment you move your cursor UI will show you client side instruction message to correct it before triggering submit button.

enter image description here

  • that is scary, You should consider replacing the red color with something more green. Did you know that in UK red color has been banned from some schools, because it "tortures" the students. (Yeah, they get "F" written in green :-D ) Commented Dec 11, 2014 at 16:17
  • 1
    agree that this is scary and overkill on the red. don't agree that you should use green!
    – pixelearth
    Commented Jun 18, 2015 at 23:47

Alarming error messages can make users anxious. User anxiety can cause users to abandon your form. You don't have to emphasize how bad the user screwed up to get them to fix it.

Reassuring error messages will make users feel more comfortable fixing their mistakes. The goal is to call their attention and guide them to correct their mistakes, not impress upon them that they made a huge mistake.


I agree with others that there should be a summary. Whether it is a specific account or "Something went wrong here. Please review any highlighted entries, make the necessary changes, and resubmit the form. Thanks."

This message could be at the top, or at the bottom by the submit form, but it just has to be visible and stand out to the user, without scrolling, immediately. So, if javascript magic can keep the page down by the submit button, great. That's where the user just was, so there's less page moving/blinking.

Then, I think that the simplest convention will be the "Below the label" version, from your examples. The label is how the user will first orient, and having the error text just below it makes good sense, with an actionable place (the field), just below.

I do like the 'red box' examples, and the hover bubbles, but my favorite UI for this would be one where the fields in question are:

  • Marked with error text that looks different beyond color. Italics or bold with color is better than just color. Unique color (with red as standard) is good, but we all know about color blind users, right?
  • Standing out from the other fields in a way beyond the text and text color. It would be very cool if all of the "ok" fields would be grayed out a bit, so that one could see the ones that need editing stand out in sharper contrast. However, if one wanted to edit one of these "ok" fields, a click should still 'open' them for 'bright' editing.
  • Nice idea about graying out of the the okay fields to emphasize the rest.
    – roni
    Commented Apr 16, 2014 at 6:38

I want to second what JonW said with some slight alteration. For those users on screen readers, you'll want to summarize the errors at the top of the form. Then, once you get into the form you want to notify screen readers of individual errors before the fields.

I came up against this issue at work and wanted to find a method that was both usable and accessible. I found this blog post http://www.nomensa.com/blog/2010/accessible-forms-using-the-jquery-validation-plug-in/ which helped tremendously. Being that I work in application development for a University, stuff like this is very important.

There are best practices - methods that are proven to work - but nothing beats real user testing. It's invaluable.

The example relies on jQuery and the validate plugin.

To summarize:

  • Group all errors together so users with assistive technology (AT) understands what's wrong from a birds-eye perspective.
  • Place individual errors above each form field so AT alerts users to the error before they complete the field.
  • If at all possible, link the summarized errors to the individual fields in question, like in the example.

Finally, if you require a certain format, make sure you mention the format in the label to reduce the number of errors (and to make the lives easier for those who can't see well or at all).


Its always best to

  1. Show inline error messages
  2. And Set the focus to the First Mandate Field left empty or the field with invalid data after form submission.

In case of Real time/live data validation

  1. Focusing the Field Red and showing a inline error message

In case of server side validation-for eg. where js is disabled -

  1. Still show an inline error message with focus to the empty field or the field with invalid data

Usual practice -

  1. Data validation should be real time (Tool tip suggesting the right format when user inputs invalid data)
  2. Checking for mandate field should happen on form submission - This helps avoid too much of system intervention on user data input)

Still the traditional way of marking mandate fields with "*" is the best

  • 1
    Where are the inline error messages shown? The main question the OP asked was about the positioning of that error text itself. While your answer is an overview of forms in general you haven't answered the specific question posed.
    – JonW
    Commented Oct 2, 2012 at 20:01
  • 1
    I'm curious as to what your final statement is based upon: "Stil the traditional way of marking mandate fields with '*' is the best", as opposed to the findings of the UX Movement here: uxmovement.com/forms/…
    – Christian
    Commented Oct 4, 2012 at 7:19
  • * To be precise about the positioning the error text should be below the input field. * Commented Oct 4, 2012 at 13:39
  • 1
    Am not opposing the findings of UX Movement, and I'd rather appreciate the thoughts . But I dont see the Red Asterisk to be noisy as mentioned in uxmovement.com/forms/…. This might be debatic as you see the comments on uxmovement.com/forms/… Commented Oct 4, 2012 at 13:46
  • "always best" is not helpful, especially in a subjective discussion. It would be more helpful to describe the cause/effect benefits of certain approaches so people can understand why you consider an approach superior.
    – pixelearth
    Commented Jun 18, 2015 at 23:49

I think google has a simple solution for the error messages on their signup form; change the border to red to highlight the field and a simple message underneath with a message in red.

This is easy when scaling a design to a small device and is clear and concise.


I think Facebook's way of showing error messages is most efficient and user friendly. Check the screenshot. This one is not consuming any extra space. User gets what is wrong and also to know in more detail, he can just hover on the field to know why the field is mandatory.enter image description here

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