Les formulaires doivent être validés en fonction de l’action prise par les utilisateurs
Publié le 1 septembre 2024
À retenir
Trois types d’erreurs peuvent généralement se produire lorsque des utilisateurs remplissent des formulaires :
- Les erreurs et les omissions des utilisateurs lorsqu’ils interagissent avec un un champ, ce qui cause une validation immédiate du champ ;
- Les utilisateurs qui soumettent un formulaire avec des informations incomplètes ou incorrectes, ce qui entraîne l’affichage d’erreurs lors de la soumission du formulaire ;
- Les utilisateurs qui soumettent un formulaire valide, mais pour qui une erreur survient du côté serveur, ce qui empêche les utilisateurs de continuer leur tâche.
Veillez à utiliser un modèle de design approprié selon la situation.
Cet article fait partie d’une série sur les micro-interactions avec les interfaces utilisateur et la manière dont elles affectent l’expérience utilisateur.
This article is also available in English.
On dirait parfois que les designers interagissent si souvent avec des formulaires qu’il leur arrive de considérer leur conception comme allant de soi… jusqu’à ce qu’ils soient eux-mêmes confrontés à un formulaire mal conçu qui entraîne confusion et frustration.
Afin que le vocabulaire utilisé dans cet article soit bien compris, définissons ce qu’est un formulaire : un formulaire est une section d’un document qui contient des composants interactifs permettant à des utilisateurs de soumettre des informations d’une interface graphique à un serveur.
Peu importe que le formulaire contienne des champs de saisie, des cases à cocher, des boutons radio, des éléments interactifs ou même des données statiques présentées dans l’interface ; si l’interaction de l’utilisateur est nécessaire pour envoyer l’information entrée dans le formulaire vers un serveur ou un système, il s’agit d’un formulaire.
Afin de choisir le modèle de design approprié, il faut regarder quelles sont les causes des erreurs auxquelles les utilisateurs peuvent être confrontés. Dans cet article, j’identifie trois (3) types d’erreurs :
- Les erreurs et les omissions des utilisateurs lorsqu’ils interagissent avec un un champ de saisie, ce qui cause une validation immédiate du champ ;
- Les utilisateurs qui soumettent un formulaire avec des informations incomplètes ou incorrectes, ce qui entraîne l’affichage d’erreurs lors de la soumission du formulaire ;
- Les utilisateurs qui soumettent un formulaire valide, mais pour lequel une erreur survient du côté serveur, ce qui empêche les utilisateurs de continuer leur tâche.
Voyons quel est le modèle de design le mieux adapté à chaque situation.
Types de validation et d’erreurs
Validation immédiate
Ce type de validation se produit immédiatement après la modification d’un champ qui requiert quelque chose de spécifique — par exemple lorsque les utilisateurs saisissent des informations erronées dans un champ ou s’ils omettent de saisir des informations dans ce champ.
Comportement attendu
- Le message d’erreur ne doit pas être affiché dès que les utilisateurs placent leur curseur dans un champ de saisie.
- Le message d’erreur ne doit pas être affiché pendant que les utilisateurs saisissent les informations dans un champ, même si celles-ci sont incorrectes.
- Le message d’erreur s’affiche si les utilisateurs placent leur curseur ailleurs que dans le champ dans lesquels ils entraient des données et si ce champ est erroné.
- Un seul message d’erreur peut apparaître à la fois pour chaque champ, celui qui est relatif à l’erreur réelle. Par exemple, si le champ est vide et qu’il est obligatoire, seul le message d’erreur relatif au requis « obligatoire » doit s’afficher.
Un champ en erreur doit être identifiable facilement et permettre aux utilisateurs de corriger leur erreur :
- un message d’erreur doit être utile et ne doit pas blâmer les utilisateurs ;
- un identifiant visuel doit être ajouté afin de ne pas utiliser uniquement la couleur pour identifier le champ en erreur.
Certains designers soulignent que ce modèle de design peut nuire à l’expérience des utilisateurs de lecteurs d’écran, car il peut sembler agressif que le lecteur d’écran annonce chaque message d’erreur si les utilisateurs se contentent de parcourir les éléments pour avoir une vue d’ensemble des données qui leur sont demandées dans un formulaire. Il est à noter que la même chose se produirait pour les utilisateurs voyants, sans que les messages d’erreur soient annoncés à voix haute.
Il s’agit d’un modèle de design que j’estime efficace dans la plupart des cas, et qui a également été identifié comme une bonne pratique par de nombreux designers qualifiés. Comme c’est le cas pour de nombreux projets, des tests d’utilisabilité avec des utilisateurs — y compris des utilisateurs de lecteurs d’écran — vous donneront la réponse la plus précise quant au modèle de design à suivre dans votre projet.
Validation lors de la soumission du formulaire
Puisqu’il devrait toujours être possible de soumettre un formulaire, il est possible que des utilisateurs tentent de soumettre un formulaire incomplet ou erroné.
Comportement attendu
- Lorsque le bouton pour soumettre un formulaire est activé, la validation de tous les champs de ce formulaire doit être déclanchée.
- Si un ou plusieurs champs sont en erreur, les données du formulaire ne doivent pas être soumises au serveur (back-end).
- Un bloc informant que le formulaire a été soumis avec des erreurs devrait être ajouté à l’interface pour expliquer aux utilisateurs la situation.
- Ce bloc devrait être en focus et être visible à l’écran.
- Chaque champ problématique doit être affiché et considéré comme invalide, son message d’erreur doit également être affiché (voir la section sur la validation immédiate pour obtenir des consigne sur comment afficher de façonappropriée ces erreurs).
- S’il y a déjà un bloc qui mentionnait des erreurs à cause d’une soumission précédente du formulaire, il doit être enlevé à la soumission du formulaire et rajouté une fois la validation du formulaire complétée.
- Si les utilisateurs soumettent à nouveau le formulaire, la même séquence d’événements doit se produire jusqu’à ce que le formulaire soit soumis sans erreurs.
Formulaire soumis correctement, erreur du serveur
Il arrive que les utilisateurs soumettent un formulaire valide, mais que le serveur ne puisse pas traiter la demande. Parfois, c’est parce qu’il y a effectivement une erreur du serveur, mais d’autres fois, c’est parce que le données du formulaire ne peuvent pas être validée par l’interface du formulaire et que seul un serveur peut juger de la validité des données entrées.
Comportement attendu
- Une fois que les utilisateurs soumettent le formulaire, le bouton de soumission et le formulaire doivent afficher un était « en traitement ».
- Si le serveur renvoie une erreur, un bloc d’erreur doit être affiché au-dessus du bouton de soumission et le formulaire doit être à nouveau disponible.
- S’il y a déjà un bloc qui mentionnait une erreur à cause d’une soumission précédente du formulaire, il doit être enlevé à la soumission du formulaire et rajouté si la situation se produit à nouveau.
- Si les utilisateurs soumettent à nouveau le formulaire, la même séquence d’événements doit se produire jusqu’à ce que le formulaire soit soumis sans erreurs.
Dans le cas d’un formulaire soumis avec des erreurs (voir la section ci-dessus), le bloc d’erreur a été placé au-dessus du formulaire, afin que les utilisateurs puissent reprendre le formulaire depuis le début pour corriger leurs erreurs.
Dans ce cas, le bloc d’erreur devrait être placé au-dessus du bouton de soumission que les utilisateurs viennent d’utiliser afin d’éviter de changer de contexte après avoir vu le bouton d’envoi dans un état de traitement.
Je préfère ce modèle de design pour la gestion des erreurs de serveur, mais il ne s’agit pas d’une règle absolue. L’emplacement de ce bloc d’erreur peut être différent pour chaque projet.
Références et lectures additionnelles
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
Rédaction de messages d’erreur
Bien que les erreurs se présentent sous différentes formes, elles ont toutes en commun qu’elles peuvent être une source de frustration pour les utilisateurs. De nombreuses personnes ont écrit des articles bien documentés qui présentent les meilleures pratiques pour rédiger des messages d’erreur.
The anatomy of an error message | Vana R – Bootcamp
The Art of the Error Message | Marina Posniak (🔒 article payant)
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
Faussetés et présomptions
Beaucoup de gens se basent sur des faussetés pour codifier la validation de formulaires (par exemple : la longueur minimale d’un nom ou d’une adresse, la complexité d’un mot de passe, etc.)
Assurez-vous de lire les articles suivants pour éviter d’iintégrer dans le code des idées préconcues qui pourraient affecter l’expérience des utilisateurs.
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
Mis à jour le 6 septembre 2024