Un utilisateur peut avoir passé plusieurs minutes à découvrir une entreprise, comprendre son offre, regarder ses réalisations et se rassurer sur son expertise.
Puis il arrive sur le formulaire.
Et là, on lui demande :
- son nom ;
- son prénom ;
- son entreprise ;
- son poste ;
- son téléphone ;
- son adresse ;
- son code postal ;
- son chiffre d’affaires ;
- son budget ;
- son délai ;
- et un message détaillé.
Tout cela avant même d’avoir pu dire simplement :
« Bonjour, j’aimerais discuter de mon projet. »
Je trouve que le formulaire est un très bon exemple de ce que peut être l’UX.
Visuellement, il peut être parfaitement propre.
Mais si l’utilisateur doit réfléchir à chaque champ, comprendre des consignes ambiguës, corriger plusieurs erreurs et ressaisir des informations, l’expérience devient rapidement pénible.
Dans mon article consacré au parcours utilisateur, j’expliquais qu’il fallait supprimer les difficultés qui n’apportent aucune valeur.
Le formulaire est probablement l’un des meilleurs endroits pour appliquer ce principe.
Chaque champ demande un effort à l’utilisateur. Avant de l’ajouter, il faut donc pouvoir expliquer pourquoi nous avons réellement besoin de cette information à ce moment précis.
Pourquoi un formulaire est-il un sujet UX ?
Un formulaire est un échange entre l’utilisateur et l’interface.
Le site pose une question.
L’utilisateur répond.
Puis le système doit :
- comprendre la réponse ;
- indiquer si elle est correcte ;
- signaler clairement un éventuel problème ;
- permettre de continuer ;
- et confirmer que l’action a bien été réalisée.
Cela paraît simple.
Mais chacune de ces étapes peut créer une friction.
L’utilisateur peut se demander :
- Pourquoi me demande-t-on cette information ?
- Est-elle obligatoire ?
- Quel format dois-je utiliser ?
- Pourquoi ma réponse est-elle refusée ?
- Est-ce que mon formulaire a bien été envoyé ?
- Que va-t-il se passer maintenant ?
Le W3C souligne justement que les formulaires peuvent représenter une charge visuelle et cognitive importante et recommande de les rendre simples, correctement structurés et compréhensibles.
Son tutoriel consacré aux formulaires accessibles rappelle notamment qu’il est préférable de ne demander que les données réellement nécessaires au processus.
C’est aussi un principe UX très simple :
Ne demandons pas à l’utilisateur de travailler pour nous si cette information peut attendre ou si nous pouvons nous en passer.
Commencer par l’objectif du formulaire
Avant de décider combien de champs utiliser, je préfère commencer par la question :
Qu’est-ce que l’utilisateur essaie de faire ?
Un formulaire peut permettre :
- de demander un devis ;
- de poser une question ;
- de réserver ;
- de créer un compte ;
- de s’inscrire à une newsletter ;
- de payer ;
- de signaler un problème ;
- de télécharger une ressource.
Ces objectifs sont très différents.
Le niveau d’information nécessaire doit donc être différent lui aussi.
Pour recevoir une newsletter, une adresse e-mail peut suffire.
Pour établir un devis technique très précis, davantage d’informations peuvent être pertinentes.
Le problème apparaît lorsque l’on utilise quasiment le même formulaire pour toutes les situations.
Un formulaire doit être conçu autour de la tâche, pas autour de la quantité de données que l’entreprise aimerait éventuellement récupérer.
Faut-il vraiment demander toutes ces informations ?
C’est souvent ma première question lorsque je regarde un formulaire existant.
Pour chaque champ, je peux demander :
- Pourquoi cette information est-elle nécessaire ?
- Est-elle nécessaire maintenant ?
- Pourrait-elle être demandée lors d’un échange ultérieur ?
- L’entreprise en fait-elle réellement quelque chose ?
- Peut-elle être déduite autrement ?
Prenons une simple demande de contact.
Avons-nous réellement besoin :
- de l’adresse postale ;
- du code postal ;
- du chiffre d’affaires ;
- du nombre de salariés ;
- du budget précis
avant d’accepter que quelqu’un nous pose une question ?
Peut-être.
Mais si ces données ne servent qu’à qualifier commercialement la demande, il faut aussi mesurer l’effort demandé à l’utilisateur.
Une information peut être utile pour l’entreprise sans être indispensable à la première interaction.
Chaque champ représente un effort
Tous les champs ne demandent évidemment pas le même effort.
« Prénom » est relativement simple.
« Décrivez précisément votre projet, vos objectifs, votre budget et vos contraintes » demande beaucoup plus de réflexion.
Je distingue donc aussi :
L’effort de saisie
Combien faut-il écrire ?
L’effort de mémoire
L’utilisateur connaît-il immédiatement la réponse ?
L’effort de décision
Doit-il choisir entre plusieurs options qu’il comprend mal ?
L’effort de confiance
Est-il à l’aise avec le fait de fournir cette information ?
Un numéro de téléphone est facile à saisir mais peut représenter un effort de confiance important si l’utilisateur craint d’être rappelé commercialement.
Le problème ne se limite donc pas au nombre de champs.
Un formulaire court peut être difficile et un formulaire plus long peut rester très fluide si chaque question paraît légitime et facile à comprendre.
Dans quel ordre organiser les champs ?
L’ordre doit suivre une logique compréhensible.
Pour une demande de contact, je peux par exemple commencer par :
- l’objet de la demande ;
- quelques informations simples sur la personne ;
- le détail du besoin ;
- les informations complémentaires éventuelles.
Sur un formulaire plus long, il est utile de regrouper les informations par thèmes :
- vous ;
- votre entreprise ;
- votre projet ;
- vos préférences ;
- validation.
Le W3C recommande d’ailleurs de regrouper correctement les champs liés et d’utiliser notamment fieldset et legend lorsque cela est pertinent.
Une bonne structure aide l’utilisateur à comprendre où il en est et pourquoi les questions sont regroupées.
Pourquoi je préfère généralement une seule colonne
Lorsque l’espace desktop est important, il est tentant de mettre plusieurs champs côte à côte.
Prénom | Nom
Email | Téléphone
Ville | Code postal
Dans certains cas, cela peut fonctionner.
Mais une seule colonne possède souvent plusieurs avantages :
- le sens de lecture est évident ;
- le regard descend naturellement ;
- l’ordre des champs est plus clair ;
- l’adaptation mobile est plus simple ;
- les messages d’aide et d’erreur disposent de davantage de place.
Je garde donc les dispositions en plusieurs colonnes pour les groupes qui ont une vraie relation évidente.
Par exemple :
Jour / Mois / Année
peut avoir du sens selon le composant utilisé.
Mais remplir chaque espace simplement parce qu’il existe sur desktop n’améliore pas nécessairement l’expérience.
Un champ doit toujours avoir un libellé clair
Le label répond à une question très simple :
« Qu’est-ce que je dois écrire ici ? »
Il doit donc être explicite.
Je préfère :
Adresse e-mail
à :
Vos coordonnées
si le champ attend uniquement un e-mail.
Pour un projet :
Décrivez votre besoin
est plus clair qu’un simple :
Message
Le W3C recommande que chaque contrôle possède un label décrivant clairement son objectif et souligne qu’un label correctement associé augmente également la zone cliquable et bénéficie aux technologies d’assistance.
Voir : W3C – Labeling Controls.
Pourquoi le placeholder ne remplace pas un label
On voit régulièrement des formulaires très minimalistes qui utilisent uniquement le placeholder :
[ Votre adresse e-mail ]Puis, dès que l’utilisateur commence à écrire, cette indication disparaît.
Il doit alors se souvenir de ce que le champ demandait.
Cela devient particulièrement problématique avec :
- plusieurs champs similaires ;
- des formats particuliers ;
- des utilisateurs interrompus pendant la saisie ;
- des difficultés cognitives ;
- certaines technologies d’assistance.
Je préfère donc conserver un vrai label visible.
Le placeholder peut éventuellement servir d’exemple complémentaire.
Par exemple :
Téléphone
06 12 34 56 78Mais il ne devrait pas porter seul l’information essentielle.
Le W3C développe également ce point dans ses recommandations sur les instructions de formulaire.
Champs obligatoires et facultatifs : être explicite
L’utilisateur ne devrait pas découvrir qu’une donnée était obligatoire uniquement après avoir cliqué sur « Envoyer ».
Il faut donc indiquer clairement ce qui est demandé.
Deux approches sont possibles selon la majorité des champs :
- indiquer « obligatoire » sur les champs concernés ;
- indiquer « facultatif » si presque tout le reste est obligatoire.
Je préfère surtout éviter un simple astérisque sans explication.
Tout le monde ne sait pas nécessairement que :
* = champ obligatoire.
Si l’astérisque est utilisé, sa signification doit être clairement expliquée.
Donner les instructions avant que l’utilisateur se trompe
Un bon message d’erreur est utile.
Mais éviter l’erreur est encore mieux.
Si un mot de passe doit comporter :
- au moins 12 caractères ;
- un chiffre ;
- un caractère spécial,
il vaut mieux le dire avant la saisie.
Si la date doit être saisie sous la forme :
JJ/MM/AAAA
l’utilisateur doit le savoir avant de recevoir :
« Format incorrect ».
Le W3C recommande justement de fournir les informations relatives aux formats, restrictions et champs requis avant qu’elles soient nécessaires.
Le formulaire devient alors préventif plutôt que punitif.
Utiliser le bon type de champ
Le choix du composant influence directement la facilité de saisie.
On peut utiliser :
- champ texte ;
- adresse e-mail ;
- numéro de téléphone ;
- liste déroulante ;
- boutons radio ;
- cases à cocher ;
- zone de texte ;
- sélecteur de date.
Le bon choix dépend surtout du nombre d’options et de la tâche.
Si l’utilisateur doit choisir entre :
- Particulier ;
- Professionnel,
deux boutons radio visibles sont souvent plus simples qu’une liste déroulante qui cache les choix.
À l’inverse, afficher directement cinquante pays sous forme de boutons radio serait évidemment beaucoup moins pratique.
L’objectif reste de réduire l’effort nécessaire pour comprendre les options et faire le choix.
L’autocomplétion fait partie de l’expérience
Pourquoi demander à l’utilisateur de retaper son prénom, son adresse ou son e-mail si le navigateur peut l’aider ?
Les attributs HTML appropriés permettent au navigateur de reconnaître la nature d’un champ et de proposer une autocomplétion.
MDN rappelle que l’attribut autocomplete permet justement d’indiquer au navigateur quel type d’information est attendu.
Voir : MDN – attribut autocomplete.
C’est particulièrement utile sur mobile.
web.dev recommande également d’exploiter les fonctionnalités natives du navigateur avec des attributs comme :
type;name;autocomplete;required.
Sa ressource sur les bonnes pratiques des formulaires de connexion illustre bien cette logique.
Une petite amélioration technique peut donc réduire une vraie friction UX.
Un bon message d’erreur aide à résoudre le problème
Il existe des messages qui constatent un problème :
« Erreur de validation. »
Et des messages qui permettent de le résoudre :
« Saisissez une adresse e-mail au format
Je préfère évidemment la seconde approche.
Un message utile doit expliquer :
- où est le problème ;
- ce qui ne va pas ;
- comment le corriger.
Le GOV.UK Design System recommande lui aussi des messages spécifiques et déconseille les formulations génériques comme « une erreur s’est produite » ou « remplissez ce champ ».
Voir : GOV.UK Design System – Error message.
Le W3C recommande également que les messages soient compréhensibles et fournissent des instructions simples permettant de résoudre l’erreur.
Voir : W3C – User Notification.
Quand faut-il valider les informations saisies ?
Attendre la toute fin d’un formulaire de quinze champs pour annoncer huit erreurs n’est pas particulièrement agréable.
Mais afficher :
« Champ invalide »
dès que l’utilisateur vient de poser son curseur dans le premier champ n’est pas très utile non plus.
La validation doit arriver à un moment où elle peut réellement aider.
Selon les situations, elle peut intervenir :
- lorsque l’utilisateur quitte le champ ;
- après une saisie suffisamment complète ;
- au moment de la soumission.
Le W3C recommande de valider les entrées de façon à aider l’utilisateur à éviter et corriger ses erreurs, tout en restant tolérant vis-à-vis de différents formats lorsque c’est possible.
Voir : W3C – Validating Input.
J’aime particulièrement cette idée de tolérance.
Si un formulaire peut comprendre :
06 12 34 56 78
mais aussi :
0612345678
je préfère ne pas obliger l’utilisateur à deviner le format exact attendu si ce format n’a aucune importance fonctionnelle.
Ne pas effacer ce que l’utilisateur a déjà rempli
Imaginez :
Vous remplissez quinze champs.
Vous cliquez sur Envoyer.
Le site détecte une erreur.
Et vous retrouvez le formulaire vide.
C’est probablement l’une des expériences les plus frustrantes que l’on puisse créer.
Lorsqu’une erreur survient, les données déjà valides doivent autant que possible être conservées.
L’utilisateur doit uniquement corriger ce qui pose réellement problème.
Corriger une erreur ne devrait jamais obliger à recommencer tout le travail.
Un formulaire long doit-il être découpé en plusieurs étapes ?
Pas toujours.
Transformer huit champs simples en quatre écrans n’améliore pas automatiquement l’expérience.
Mais lorsqu’un formulaire comporte réellement plusieurs groupes complexes, un découpage peut être utile.
Par exemple :
- Vos coordonnées
- Votre projet
- Vos besoins techniques
- Vérification
Le W3C recommande également, lorsque cela est pertinent, de diviser les formulaires longs en étapes logiques et d’informer les utilisateurs de leur progression.
Mais chaque étape supplémentaire crée aussi :
- un écran ;
- une action ;
- une transition ;
- un risque d’abandon.
Je préfère donc utiliser plusieurs étapes lorsqu’elles permettent réellement de réduire la charge cognitive.
Afficher la progression dans les formulaires en plusieurs étapes
Si le formulaire possède plusieurs écrans, l’utilisateur doit pouvoir comprendre :
- où il se trouve ;
- ce qu’il a déjà fait ;
- ce qu’il lui reste à faire.
Par exemple :
Étape 2 sur 4 — Votre projet
est beaucoup plus rassurant qu’une succession d’écrans dont on ignore la durée.
On peut aussi afficher :
Coordonnées → Projet → Options → Validation
Le nombre d’étapes doit évidemment rester sincère.
Je préfère éviter :
Étape 3 sur 4
puis découvrir ensuite trois écrans supplémentaires.
La progression doit donner un repère, pas créer une fausse impression de proximité.
Le bouton d’envoi doit expliquer ce qui va se passer
« Envoyer » fonctionne.
Mais un libellé plus contextualisé peut être plus clair.
Par exemple :
- Demander mon devis ;
- Créer mon compte ;
- Réserver mon créneau ;
- Envoyer ma demande ;
- M’inscrire à la newsletter.
L’utilisateur comprend immédiatement ce que déclenche l’action.
Cela rejoint directement la question de la hiérarchie visuelle : le bouton principal doit également être suffisamment visible par rapport aux actions secondaires.
Il faut aussi éviter plusieurs boutons de même importance qui font hésiter au dernier moment.
La confirmation fait partie du formulaire
Après l’envoi, l’utilisateur ne devrait jamais se demander :
« Est-ce que ça a marché ? »
Une bonne confirmation peut préciser :
- que le formulaire a bien été envoyé ;
- ce qui va se passer ensuite ;
- le délai de réponse ;
- les éventuelles actions complémentaires.
Par exemple :
Votre demande a bien été envoyée. Notre équipe vous répondra sous deux jours ouvrés à l’adresse indiquée.
C’est beaucoup plus rassurant que :
« Merci. »
Le W3C insiste également sur l’importance de notifier clairement l’utilisateur lorsqu’une tâche est terminée ou lorsqu’une erreur est survenue.
Concevoir réellement le formulaire pour mobile
Le mobile ne consiste pas uniquement à réduire la largeur des champs.
Il faut tester :
- le clavier affiché ;
- la taille des zones tactiles ;
- la visibilité des labels ;
- les messages d’erreur ;
- la progression ;
- le bouton principal ;
- le scroll nécessaire.
Le bon type de champ permet également d’afficher un clavier plus adapté.
Pour une adresse e-mail, un clavier proposant facilement :
@
peut éviter plusieurs manipulations.
Pour un téléphone, un clavier numérique sera généralement plus pratique.
web.dev recommande notamment de concevoir des formulaires dont les champs et boutons restent suffisamment grands et confortables sur mobile.
Ce sont de petits détails, mais ils s’additionnent tout au long du parcours.
Formulaires et accessibilité : les bases à prévoir dès la maquette
Je préfère considérer l’accessibilité dès la conception plutôt que découvrir à la fin qu’il faut modifier toute la structure.
Pour un formulaire, plusieurs éléments sont particulièrement importants :
- des labels visibles et explicites ;
- une association technique correcte entre labels et champs ;
- un ordre de navigation cohérent ;
- un fonctionnement clavier ;
- des indications qui ne reposent pas uniquement sur la couleur ;
- des erreurs clairement identifiées ;
- des groupes de champs correctement structurés ;
- des zones interactives suffisamment faciles à sélectionner.
Le W3C explique notamment qu’un label correctement associé aide :
- les utilisateurs de lecteurs d’écran ;
- les personnes utilisant la commande vocale ;
- les personnes ayant une dextérité limitée ;
- et, plus généralement, tous les utilisateurs.
Ces principes sont détaillés dans le Forms Tutorial du W3C.
TooNetCreation développe également cette approche dans l’article « Accessibilité web et design : non, un site accessible n’est pas forcément moche ».
Une interface accessible n’a donc pas besoin d’être moins esthétique.
Elle doit surtout être plus claire dans sa manière de communiquer.
La réassurance au bon moment
Un formulaire peut demander des informations personnelles.
L’utilisateur peut donc se demander :
- Pourquoi demandez-vous mon téléphone ?
- Allez-vous me rappeler ?
- Que faites-vous de mon adresse e-mail ?
- À qui ces données seront-elles transmises ?
La réassurance doit être placée à proximité du moment où cette question apparaît.
Par exemple, à côté du téléphone :
« Facultatif — uniquement si vous préférez être rappelé. »
Cette petite phrase peut complètement modifier la perception du champ.
Dans mon article sur le parcours utilisateur, j’explique justement qu’une information de réassurance peut perdre beaucoup de son efficacité lorsqu’elle est placée trop tard.
Le formulaire en est un très bon exemple.
Exemple : simplifier un formulaire de contact
Prenons un formulaire initial :
- Civilité *
- Prénom *
- Nom *
- Entreprise *
- Fonction *
- Email *
- Téléphone *
- Adresse *
- Code postal *
- Ville *
- Objet *
- Budget *
- Message *
Pour une simple prise de contact, je commencerais par questionner presque tous les champs.
Une version plus simple pourrait devenir :
Votre demande
Objet de votre demande *
[ Je souhaite parler d’un projet UX/UI ]
Vos coordonnées
Nom *
Adresse e-mail *
Téléphone — facultatif
Uniquement si vous souhaitez être rappelé.
Votre message
Parlez-nous de votre besoin *
[ Zone de texte ]
[ Envoyer ma demande ]
Nous sommes passés de treize champs à cinq.
Cela ne signifie pas que cette version conviendra à toutes les entreprises.
Mais elle pose la bonne question :
Qu’avons-nous réellement besoin de savoir pour pouvoir commencer la conversation ?
Exemple : concevoir une demande de devis plus complexe
Un formulaire de devis peut légitimement demander davantage d’informations.
Dans ce cas, je préfère structurer le parcours.
Étape 1 — Votre besoin
- Type de projet ;
- site existant ou nouveau projet ;
- objectif principal.
Étape 2 — Votre projet
- fonctionnalités importantes ;
- contenus disponibles ;
- délai envisagé.
Étape 3 — Vos coordonnées
- nom ;
- entreprise ;
- e-mail ;
- téléphone facultatif.
Étape 4 — Vérification
L’utilisateur peut relire les principales informations avant l’envoi.
Cette structure peut être plus longue qu’un formulaire de contact classique.
Mais l’effort est cohérent avec l’objectif : obtenir une première estimation plus précise.
Le formulaire devient alors une partie du parcours utilisateur et peut être réfléchi dès les wireframes.
12 erreurs UX fréquentes dans les formulaires
1. Demander des informations qui ne servent pas immédiatement
Chaque champ augmente l’effort.
2. Utiliser uniquement des placeholders
L’utilisateur perd l’instruction dès qu’il commence à écrire.
3. Utiliser des labels trop vagues
« Informations » ne dit pas ce qui est attendu.
4. Cacher les champs obligatoires
L’utilisateur ne doit pas découvrir les règles après l’envoi.
5. Indiquer les contraintes uniquement dans les messages d’erreur
Les instructions utiles doivent être fournies avant la saisie.
6. Refuser inutilement plusieurs formats valides
Le système doit être tolérant lorsque cela est possible.
7. Utiliser des messages d’erreur génériques
« Erreur » ne permet pas de comprendre comment corriger le problème.
8. Effacer les champs après une erreur
L’utilisateur ne devrait pas recommencer tout le formulaire.
9. Créer trop de colonnes
Le parcours de lecture devient moins évident.
10. Négliger l’autocomplétion
Le navigateur peut éviter beaucoup de saisies répétitives.
11. Oublier la confirmation
L’utilisateur doit savoir que l’action a réussi.
12. Concevoir uniquement sur desktop
Un formulaire confortable à la souris peut devenir très pénible avec un clavier mobile.
Ma méthode pour concevoir un formulaire
1. Définir l’objectif
Quelle tâche l’utilisateur veut-il accomplir ?
2. Lister les informations souhaitées
Je commence par tout ce que l’entreprise aimerait connaître.
3. Supprimer ce qui n’est pas indispensable
Je distingue besoin immédiat et information pouvant être demandée plus tard.
4. Évaluer l’effort
Certains champs sont simples, d’autres demandent réflexion ou confiance.
5. Organiser les groupes
Je crée un ordre logique.
6. Choisir les bons composants
Texte, radio, checkbox, sélection, date...
7. Écrire les labels et instructions
L’utilisateur doit savoir immédiatement ce qui est attendu.
8. Prévoir les erreurs
Je n’attends pas le développement pour réfléchir aux états invalides.
9. Prévoir la confirmation
Le succès fait partie du parcours.
10. Créer le wireframe
Je vérifie la structure avant le travail graphique détaillé.
11. Travailler la hiérarchie visuelle
Les champs, groupes, aides, erreurs et CTA doivent être facilement distinguables.
12. Tester sur mobile
Je vérifie la saisie dans les conditions réelles.
13. Vérifier l’accessibilité
Labels, focus, clavier, erreurs et composants doivent fonctionner correctement.
14. Observer de vrais utilisateurs lorsque c’est possible
La logique du designer n’est pas toujours celle de la personne qui découvre le formulaire.
Cette démarche s’inscrit directement dans notre approche de conception UX/UI et expérience utilisateur chez TooNetCreation.
Comment auditer rapidement un formulaire existant ?
Je peux commencer avec une checklist très simple.
Avant de remplir le formulaire
- Comprend-on son objectif ?
- Le nombre de champs semble-t-il raisonnable ?
- Les champs obligatoires sont-ils identifiables ?
Pendant la saisie
- Les labels restent-ils visibles ?
- Les formats attendus sont-ils expliqués ?
- Le clavier mobile est-il adapté ?
- L’autocomplétion fonctionne-t-elle ?
En cas d’erreur
- Le problème est-il clairement identifié ?
- Le message explique-t-il comment le corriger ?
- Les données déjà saisies sont-elles conservées ?
Après l’envoi
- La réussite est-elle clairement confirmée ?
- L’utilisateur sait-il ce qui va se passer ensuite ?
J’aime également regarder la page à travers la logique développée dans mon article sur la hiérarchie visuelle.
Si trois boutons, cinq encadrés et plusieurs couleurs se battent autour du formulaire, l’utilisateur peut avoir du mal à identifier l’action principale.
FAQ : UX et formulaires web
Combien de champs doit contenir un formulaire de contact ?
Il n’existe pas de nombre idéal universel. Il faut demander les informations réellement nécessaires à la première étape. Pour une simple prise de contact, nom, e-mail et message peuvent parfois suffire.
Faut-il supprimer tous les champs facultatifs ?
Non. Un champ facultatif peut être utile si son intérêt est clair. Il faut surtout éviter d’accumuler des informations qui pourraient être demandées plus tard sans pénaliser l’utilisateur.
Le placeholder peut-il remplacer le label ?
Je le déconseille. Le placeholder disparaît généralement pendant la saisie alors qu’un label visible continue d’indiquer la fonction du champ. Le W3C recommande des labels clairement associés aux contrôles.
Faut-il mettre les formulaires sur une seule colonne ?
Une seule colonne rend généralement le sens de lecture plus évident. Certaines informations très liées peuvent cependant être regroupées horizontalement lorsque cela reste compréhensible et fonctionne correctement sur mobile.
Quand utiliser un formulaire en plusieurs étapes ?
Lorsqu’un formulaire est réellement long ou comporte plusieurs groupes logiques complexes. Le découpage doit réduire la charge cognitive, pas simplement multiplier les écrans.
Comment écrire un bon message d’erreur ?
Il doit identifier précisément le problème et expliquer comment le corriger. « Saisissez une adresse e-mail valide » est plus utile que « Erreur de validation ».
Faut-il valider les champs en temps réel ?
Cela dépend du champ. La validation doit intervenir lorsqu’elle peut réellement aider sans signaler prématurément des erreurs pendant que l’utilisateur est encore en train de saisir sa réponse.
Pourquoi utiliser autocomplete ?
L’autocomplétion permet au navigateur d’aider l’utilisateur à remplir les données courantes comme le nom, l’e-mail ou l’adresse, ce qui réduit particulièrement l’effort sur mobile.
Un formulaire accessible est-il forcément plus compliqué à concevoir ?
Non. Beaucoup de bonnes pratiques d’accessibilité améliorent aussi l’expérience générale : labels explicites, structure logique, messages d’erreur compréhensibles, navigation clavier et instructions claires.
Comment savoir si un formulaire fait abandonner les utilisateurs ?
On peut combiner données analytics, taux d’abandon, erreurs, retours utilisateurs et tests d’usage. Il est aussi très utile de remplir soi-même le formulaire sur plusieurs appareils.
Sources et ressources pour aller plus loin
- W3C – Forms Tutorial : bonnes pratiques de structuration, labellisation, validation et accessibilité des formulaires.
- W3C – Labeling Controls : association des labels aux champs et intérêt pour les utilisateurs et technologies d’assistance.
- W3C – Form Instructions : présentation des instructions, formats attendus et champs requis.
- W3C – Validating Input : validation des saisies et prévention des erreurs.
- W3C – User Notification : messages de succès et messages d’erreur compréhensibles.
- GOV.UK Design System – Text input : exemples concrets de labels, aides, autocomplete et états d’erreur.
- GOV.UK Design System – Error message : recommandations pour rédiger des erreurs claires et spécifiques.
- MDN – autocomplete : fonctionnement de l’autocomplétion des champs HTML.
- web.dev – Sign-in form best practices : bonnes pratiques techniques et UX pour les formulaires de connexion.
À lire également sur TooNetCreation
- Comment construire un parcours utilisateur efficace sur un site web ?
- Hiérarchie visuelle : comment organiser une page web pour guider l’utilisateur ?
- Qu’est-ce qu’un wireframe ? Définition, utilité et méthode
- UX et UI : quelles différences et pourquoi les deux sont indispensables à un site web ?
- Conception UX/UI et expérience utilisateur
- Accessibilité web et design : non, un site accessible n’est pas forcément moche
