by Mat Janson Blanchet

Forms should validate according to user action

Posted on November 24, 2023


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:

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

Errors should be identifiable with:

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

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

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


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

Falsehoods and Assumptions

There are many falsehoods and assumptions that are used to validate forms (ex. minimum length of a name, addresses, complexity of password, etc.).

Ensure to read about them to check your assumptions before committing them to code, which can affect the user experience:

Awesome Falsehood | Kevin Deldycke – GitHub

Creating More Inclusive and Culturally Sensitive Forms | Mark H. Anbinder – UXBooth

Designing Forms for Gender Diversity and Inclusion | Sabrina Fonseca – UX Collective

False Assumptions About Names in Interfaces | Vitaly Friedman – LinkedIn

Falsehoods Programmers Believe | Scott Vandehey

Falsehoods Programmers Believe About Gender | Diana Thayer – GitHub

Falsehoods Programmers Believe About Names | Patrick McKenzie

Falsehoods Programmers Believe About Time | Tim Visée – GitHub

How To Ask Users For Names | Design System –

Last updated on February 13, 2024

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.