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.
Cet article est également disponible en français.
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.
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.
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.
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 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
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 – gov.uk
Last updated on September 1, 2024