Forms should validate according to user action

Posted on November 24, 2023

Takeaways

There are usually three types of error that can occur when using forms:

Users’ errors and omissions while they finish interacting with an input, which leads to inline validation;
Users submitting forms with incomplete or incorrect information, which leads to errors being presented upon form submission;
Users submitting valid forms, but the back-end prevents completion of the process started by the user.

Ensure to use a design pattern that handles each situation appropriately.

This article is part of a series on user interface micro interactions and how they affect the user experience.

Designers interact with forms so often that they take their design for granted… until they — or other users — face a form that is not actually well designed, which leads to more confusion and frustration than necessary.

To ensure the vocabulary used in this article is understood, let’s define a form: a form is a section of a document which contains interactive controls for submitting information from the front-end to the back-end via the interaction of users with a button or another element. It does not matter if the form contains fields, checkboxes, radio buttons, any interactive element, or even static data that the system presents in the front-end. If the user interaction is required to send the information to the back-end, it qualifies as a form.

In order to choose the appropriate design pattern, let’s have to take a look at what are the causes of the errors users can face. In this article, I identify three (3) types of error:

Users’ errors and omissions while they finish interacting with an input, which leads to inline validation;
Users submitting forms with incomplete or incorrect information, which leads to errors being presented upon form submission;
Users submitting valid forms, but the back-end prevents completion of the process started by the user.

Let’s investigate what design pattern is best for each situation.

Types of validation and errors

Inline validation

Inline validation occurs when immediately after fields that expect something specific, e.g. users enter wrong information in a field, or omit to enter information in said field.

Flowchart showing the states of a form when users fill input fields incorrectly — Form inline validation

Expected behaviour

Inline errors should not be shown as soon as users set focus on an input field.
Inline error should not be shown while users are still entering information, even if the information is incorrect.
Inline errors do appear if users set focus away from the input field, and if that field is in error.
Only one error message can appear at a time for each field, the one that is relative to the actual error happening. e.g. If the field is empty and is required, only the “required” error message should show.

Errors should be identifiable with:

an error message that must be useful and that does not blame the user;
a badge or some visual icon to ensure not to only use colour to identify field in error.

Some Designers mention that this design pattern may be detrimental to the experience of screen reader users, as it might feel aggressive for the screen reader announce each error message if users are simply tabbing through the elements to get an overview of the data they are asked in a form. Note that the same would occur for sighted users, without the error messaged being announced aloud

Ultimately, this is a design pattern I feel works for most cases, and it also has been identified as a best practice by multiple experienced Designers. As is the case for many projects, usability testing with users, including screen reader users, would provide you with the most accurate answer for which design pattern to follow

Forms submitted with errors

Since forms should always be available to submit, users are able to submit a form that may be incomplete, or that may contain errors.

Flowchart showing the states of a form when users submit a form containing errors — Form submitted with errors

Expected behaviour

Upon clicking the submit button, the form validation should be triggered immediately.
If validation detects any issue, the form should not sending data to the back-end.
An error block should be presented informing the user if there are issues with the submitted form.
That error block should be set in focus and be visible on-screen.
Each problematic field should be set and displayed as invalid, with its inline error (see inline error section for appropriate display instructions for inline errors).
If there is already an error block when the user submits the form, it should be removed and added anew after the validation has completed.
If the user submits the form again, the same events should occur until the user submits a valid form.

Form submission with back-end errors

There are moments when users submit a valid form, but the back-end system may not proceed with the request. Sometimes it’s because there is actually a system error, but at other times, it’s because the back-end needed to validate the form values, which could not be done in the front-end.

Flowchart showing the states of a form when the back-end causes an error — Form with back-end errors

Expected Behaviour

Upon clicking the submit button, the button and the form should be set to a processing state
Upon return of an error by the back-end, an error block should be displayed above the submit button, and the form should be available again.
If there is already an error block when the user submits the form, it should be removed and added anew after the process has completed.
If the user submits the form again, the same events should occur.

In the case of a form submitted with errors (see section above), the error block was placed above the form, so that users can go through the form again from the start to correct their errors.

In this case, the error block should be placed above the call to action the user just clicked, to avoid changing context after seeing the submit button in a processing state.

This is a preferred design pattern of mine, however it is not a hard rule. The placement of this error block could be designed differently per project, or even for cases in which fields can be identified as in error, just like for front-end validation.

References and Additional Readings

Articles

The Anatomy of Accessible Forms: Error Messages | Accessibility Best Practices – Deque

A Complete Guide To Live Validation UX | Vitaly Friedman – Smashing Magazine

Designing More Efficient Forms: Assistance and Validation | Nick Babich – UX Planet

Input Feedback – Design Pattern – UI Patterns

“The text input field that throws an error when you TYPE ONE CHARACTER and doesn’t “heal” til you finish.” | Stephanie Lucas – LinkedIn

The Ultimate UX Design of Form Validation | Marcin Treder – Designmodo

Understanding SC 1.4.1: Use of Color (Level A) | WCAG 2.1 Understanding Docs – W3C

Understanding SC 3.3.1: Error Identification (Level A) | WCAG 2.1 Understanding Docs – W3C

Understanding SC 4.1.3: Status Messages (Level AA) | WCAG 2.1 Understanding Docs – W3C

Usability Testing of Inline Form Validation: 31% Don’t Have It, 4% Get It Wrong | Edward Scott – Baymard Institute

Usable and Accessible Form Validation and Error Recovery | WebAIM

The UX of form validation: Inline or after submission? | Chinwe Uzegbu – Log Rocket

Writing Error Messages

Errors come in many flavours: what they all have in common is that they can be a source of frustration to users. There are many people who wrote well-documented articles explaining the best practices to craft error messages.

The anatomy of an error message | Vana R – Bootcamp

The Art of the Error Message | Marina Posniak (🔒 Paywalled)

Designing Better Error Messages UX | Vitaly Friedman – Smashing Magazine

Error Message – Writing Guidelines | Design System – Atlassian

Error Message Design Tips | Adham Dannaway – Twitter

Error Message Guidelines | Windows App Development – Microsoft

When life gives you lemons, write better error messages | Jenni Nadler – Wix UX

Writing UX Microcopy for Error Messages: Copy-Paste Templates | FAQPRime