Form errors that help users
Tags: design, ux, frontend
Published: 2020-05-26 23:01:50

I've been implementing a component library where the implementation of a text input with errors looked something like this: 
![A password field with help text underneath the input box and an invalid password field with an error message](https://dev-to-uploads.s3.amazonaws.com/i/30c7rt794maa409nw5qj.png)

This conflicted with the advice from Adam Silver in [Form Design Patterns](https://www.smashingmagazine.com/2018/10/form-design-patterns-release/) that was close to the design in the [Gov UK Design System](https://design-system.service.gov.uk/components/text-input/#error-messages)
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/phrlj0vlnj2gj3blquk9.png)

I wanted to see _why_ Adam suggested this style of implementation.

## Looking at others
Honestly, looking at others create more uncertainty. Some libraries like [Atlaskit](https://atlassian.design/guidelines/product/components/text-field) suggested putting icons within the text box:
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/b29pi429oucyo53oe7yr.png).

[Material design](https://material.io/components/text-fields#anatomy) suggests replacing any helper text with an error message below the input box: 
![Input with error message below the input box and an error icon within ](https://dev-to-uploads.s3.amazonaws.com/i/8kr1x04aqo35lsy79aev.png)
This seemed especially problematic because after an error occurs, the help text is no longer visible which may contain important information that helps the user properly input the data. For instance, if the input is a date input, then the help text may be "Date should be formatted (MM/DD/YYYY)". If no input is provided to a required date input, the error message would be "Enter a date." But how to format that date is gone!

NNGroup goes into why it may not be best to look to other large companies for UX designs:

(article continues after video).
{% youtube 74XfmOtz7AU %}

## Down the rabbit hole of science

Finding recent journal articles about this topic was very difficult. I began the journey with [User-friendly locations of error messages in web forms: Put them on the right side of the erroneous input field](https://www.sciencedirect.com/science/article/abs/pii/S0953543812000173). Sure enough in the title, my answer may have been provided. However, this study was conducted in early 2012, before responsive design implementations really took off at the enterprise level. For mobile devices, placing the error messages on the right side would take up a lot of real estate, and the study excluded mobile users.

However, it did note that "There was no significant difference be-tween the four locations near the erroneous input field". So, as long as your error was close to the input, it didn't really matter other than the preference of your user base.

So looking at who had cited this article, I found a few more resources particularly, [A Study of Usability of Arabic Forms for Smartphones](http://scholar.ppu.edu/bitstream/handle/123456789/717/A%20Study%20of%20Usability%20of%20Arabic%20Forms%20for%20Smartphones%20-30126-2017.pdf?sequence=1&isAllowed=y). This study focused exclusively on mobile devices, and found the following:
> The previous discussion applies to the big device groups as well, except that the group that scored the shortest time is the [below label and above input] group. In our opinion and according to the feedback that we got from users in the retrospective think aloud, placing error messages below label scores the best results because users will immediately recognize that the error message belongs to that field, because it is placed between the label and its text box.

This still wasn't the definitive answer I wanted. It seemed to come down more to user preference than anything.

Digging deeper into Adam's book, I found this reference: [Avoid Messages Under Fields by Adrian Roselli](https://adrianroselli.com/2017/01/avoid-messages-under-fields.html). Adrian found that placing information on how to fill out the form can be problematic due to browser features [covering up that information](https://adrianroselli.com/wp-content/uploads/2017/01/How-Not-to-Do-Field-Tips-Part2.mp4) on desktop and mobile.

## Conclusion
My final design looks something like this:
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/uf31dtjc9rfnckzxa036.png)

Adding a border to the left may help enforce association between the error, label, description, and input box. However, further testing may show if this is actually necessary.

The lesson here is to understand the usability of something before reaching for others. Large companies may have designs that work for them, but may not necessarily be the best for your users. 

This may seem like a lot of effort for something as simple as an error message, but it's important that users have a good experience and understand how their data is being used. Forms can already be a frustrating experience, so making it less so is a huge win.

### Special Thanks
Thanks [Adam Silver](https://twitter.com/adambsilver) for answering my many twitter questions and for a great book.