Le canon des formulaires : chaque champ est une question

Un formulaire, c’est le moment où une interface cesse de présenter et se met à demander. Chaque champ est une question posée à une personne qui préférerait faire autre chose, ce qui signifie que chaque champ superflu est une imposition et que chaque champ confus est une petite trahison. L’artisanat du formulaire se ramène à un canon que l’on garde en tête : poser le moins de questions possible, sur une seule colonne, avec des libellés visibles ; accepter les réponses telles que les gens les donnent naturellement ; déclencher la validation quand l’utilisateur a fini sa pensée, et non au milieu d’une frappe ; rédiger des erreurs qui disent comment corriger le problème ; et ne jamais, sous aucun prétexte, jeter ce que l’utilisateur a saisi. La plupart des frictions de formulaire rencontrées en production violent l’une de ces lignes. {.answer-block}

TL;DR

• Un formulaire est une conversation, alors demandez comme le ferait une personne : le moins de questions possible, dans une seule colonne ordonnée, regroupées par thème – et chaque champ doit se justifier face au coût de la question.
• La mise en page est une affaire réglée : une seule colonne, les libellés au-dessus du champ, une largeur de champ qui suggère la longueur de la réponse. Les formulaires multicolonnes et les astuces de libellés flottants échangent de la compréhension réelle contre un raffinement imaginaire.
• Acceptez les réponses telles que les gens les donnent. Coupez l’espace parasite, prenez le numéro de téléphone dans n’importe quel format, gardez le champ entier au lieu de le découper en trois cases – la normalisation est le travail du logiciel, pas celui de l’utilisateur.
• Validez à la sortie du champ, pas à la frappe, et rédigez des erreurs qui enseignent : ce qui n’a pas marché, comment le corriger, à côté du champ concerné.
• La saisie de l’utilisateur est sacrée. Un envoi échoué qui vide le formulaire, ou un bouton désactivé qui refuse de dire pourquoi, transforme un participant volontaire en ancien participant.

Pourquoi chaque champ est une question

Traitez un formulaire comme la transcription d’un entretien et sa qualité devient lisible. Un intervieweur compétent demanderait-il votre numéro de fax par simple habitude ? Exigerait-il votre date de naissance avant d’expliquer pourquoi ? Vous couperait-il en pleine épellation de votre e-mail pour annoncer qu’il est invalide ? Oublierait-il tout ce que vous venez de dire parce que votre code postal contenait une espace ? Chacun de ces gestes a son équivalent dans un formulaire en production, et les utilisateurs les vivent comme ils vivraient l’intervieweur : comme de la grossièreté.

Ce cadrage produit aussi la première et la plus importante des règles, celle qui précède toute mise en page et tout style : chaque champ doit justifier son existence face au coût de la question. Chaque question supplémentaire augmente l’abandon ; chaque réponse collectée est une donnée qu’il faut désormais stocker, sécuriser et assumer. Le geste le plus fort en conception de formulaire, c’est la suppression – le champ que vous retirez bat tout raffinement que vous auriez pu lui appliquer. Le reçu canonique est celui d’Expedia : supprimer un seul champ facultatif, « Société », du formulaire de réservation aurait valu environ 12 millions de dollars par an – les clients y saisissaient le nom de leur banque, puis échouaient à la vérification d’adresse. Un champ, honnêtement interrogé, a battu n’importe quelle refonte. « Facultatif » n’est pas une justification ; c’est une imposition plus petite, mais une imposition quand même. Demandez ce dont vous avez besoin pour conclure la transaction, marquez comme facultatif le rare champ qui l’est vraiment, et reportez tout le reste à plus tard, quand la relation l’aura mérité. (Le camp adverse préfère mettre un astérisque sur chaque champ obligatoire ; quand presque tout est obligatoire, les astérisques deviennent du papier peint.)

Les règles de mise en page

La mise en page d’un formulaire est l’un des rares coins du design où les preuves sont pour ainsi dire établies, ce qui fait de tout écart un choix contre l’utilisateur :

Une seule colonne. Un formulaire est une séquence de questions, et une colonne unique rend cette séquence sans ambiguïté : répondre, descendre, terminer. Les dispositions multicolonnes imposent une décision d’ordre de lecture à chaque ligne – en travers ou vers le bas ? – et les utilisateurs la tranchent de façon incohérente, sautant des champs qu’ils n’ont jamais vus. Dans la comparaison par oculométrie la plus connue, les mêmes champs sur une seule colonne étaient remplis environ quinze secondes plus vite que répartis sur deux. Les exceptions sont les véritables composites qui se lisent comme une réponse unique : ville / région / code postal sur une ligne, une date en trois parties. C’est une question qui porte trois champs, pas trois questions.

Les libellés au-dessus du champ, toujours visibles. Les libellés placés à côté des champs créent un parcours de l’œil en dents de scie ; les libellés placés dans les champs (le placeholder tenant lieu de libellé) disparaissent à l’instant où l’utilisateur commence à taper, c’est-à-dire précisément quand il en a besoin – à mi-parcours d’un long formulaire, chaque champ rempli devient une boîte mystère du genre « c’était quoi, déjà ? ». Les libellés flottants, ce compromis animé, survivent au focus mais rétrécissent à la taille d’une légende et font passer les champs vides pour remplis : une version plus douce du même échange, toujours payée en compréhension. Les placeholders servent aux indications de format (« [email protected] »), jamais à la question elle-même.

La largeur du champ est une information. Un champ de code postal aussi large qu’un champ d’adresse ment sur la forme de la réponse. Dimensionner les champs selon leur contenu attendu – court pour les codes postaux, long pour les adresses – relève du même artisanat que l’espacement qui encode le regroupement : de la géométrie qui communique en silence.

Regroupez par thème, et laissez l’espace faire le regroupement. Contact, livraison, paiement – des grappes de questions liées, avec des coutures nettes entre elles, ces coutures étant faites de blanc plutôt que de cadres ou de filets. Un formulaire qui se lit comme trois petits sujets est psychologiquement plus court que les mêmes champs présentés en un bloc indifférencié.

Les règles de saisie

Le thème de la conception des champs tient en une phrase : la normalisation est le travail du logiciel. Quelle que soit la charge de mise en forme, c’est la machine qui la porte, parce que c’est la machine que ça intéresse.

• Acceptez les réponses négligées. Coupez les espaces superflues – l’espace final d’un e-mail auto-complété a fait échouer plus de connexions qu’il n’en avait le droit. Prenez les numéros de téléphone avec tirets, points, espaces, parenthèses, ou rien du tout. Acceptez le numéro de carte avec ou sans séparations. Si vous savez l’analyser, analysez-le ; rejeter 555 867 5309 parce que vous vouliez 5558675309, c’est faire exécuter à la main votre code de formatage de chaînes par l’utilisateur.
• Ne découpez jamais ce que l’utilisateur perçoit comme une seule chose. Numéros de téléphone en trois cases, dates en trois menus déroulants, codes de vérification en six cellules d’un caractère avec saut de focus fait maison – chacun transforme une réponse mentale unique en casse-tête de navigation et casse en général le collage, la méthode de saisie la plus efficace dont dispose l’utilisateur. (L’exception composite des règles de mise en page tient toujours : une date en trois parties saisies convient – le péché, c’est la cérémonie du menu déroulant et le focus volé, pas l’adjacence. Et pour les codes, la réponse durable est un champ unique avec autocomplete="one-time-code".)
• Convoquez le bon clavier. Sur les appareils tactiles, type="email", inputmode="numeric" et consorts font la différence entre taper une adresse sur un clavier conçu pour ça et chasser le @ à travers des couches de symboles. Cela coûte un attribut.
• Laissez le navigateur aider. Des jetons autocomplete corrects transforment un paiement à douze champs en deux tapotements pour un utilisateur qui revient. Désactiver le remplissage automatique sur les champs d’adresse et de paiement – une superstition héritée, le plus souvent, d’une revue de sécurité qui n’a jamais eu lieu – jette la plus grande accélération disponible pour un formulaire.
• Allez à la rencontre du doigt là où il se pose. Les champs, leurs boutons et tout ce qui se tape respectent la cible tactile minimale de la plateforme – 44 pt sur iOS, 48 dp sur Android. Un champ compact et élégant que le pouce n’atteint pas de façon fiable est un formulaire de bureau déguisé en téléphone.

Les règles du clavier et du remplissage automatique coûtent ensemble quelques attributs :

<input type="tel" autocomplete="tel">              <!-- phone keypad, autofilled -->
<input inputmode="numeric" autocomplete="one-time-code">  <!-- digit pad, code autofills -->

Les règles de validation

Le moment de la validation est l’endroit où les formulaires se montrent le plus souvent hostiles, et la règle est simple : répondez quand l’utilisateur a fini sa pensée. Se déclencher à chaque frappe, c’est crier « e-mail invalide ! » à quelqu’un qui en est au quatrième caractère – critiquer des phrases avant leur fin. L’école opposée ne valide qu’à l’envoi, et elle a un défenseur sérieux : le design system de GOV.UK fait exactement cela, en associant la soumission à un récapitulatif d’erreurs en haut de page, parce qu’un récapitulatif s’annonce aux lecteurs d’écran et donne aux utilisateurs au clavier un point de départ unique pour les réparations. C’est une position cohérente, calibrée pour des services où l’accessibilité est la contrainte déterminante. Pour la plupart des formulaires produit, je tiens malgré tout la position de la sortie de champ : l’utilisateur remplit le champ, passe au suivant, et reçoit un retour à la couture entre deux pensées, tant que la pensée est encore chaude. (Un raffinement : un champ déjà invalide peut être revalidé à chaque frappe, pour que l’état rouge disparaisse à l’instant où la correction arrive plutôt qu’avec un champ entier de retard.)

La rédaction des erreurs passe le même test conversationnel. Une erreur n’est pas un verdict ; c’est une instruction de réparation. « Saisie invalide » échoue au test – invalide comment ? « Cette adresse e-mail n’a pas son @ » réussit. (Et l’instruction doit être vraie au regard de la règle réelle : les numéros de carte comptent légitimement de 12 à 19 chiffres, donc « doit contenir 16 chiffres » n’est pas un message d’erreur, c’est un bug de validation qui rejette tous les porteurs d’Amex.) Placez le message auprès du champ concerné, en toutes lettres – la couleur seule exclut les daltoniens, et le texte est le seul canal perceptible par un lecteur qui ne rend rien – et liez-le à son champ par programmation (aria-describedby), pour que les technologies d’assistance annoncent l’erreur avec le champ au lieu de la laisser échouée à l’écran. Gardez un ton factuel : le travail du formulaire est de faire aboutir l’utilisateur, pas de juger des fautes. Toute la règle en une paire :

<!-- before: a verdict, visually nearby, programmatically stranded -->
<label for="email">Email</label>
<input id="email" type="email">
<span class="error">Invalid input</span>

<!-- after: a repair instruction, announced with its field -->
<label for="email">Email</label>
<input id="email" type="email"
       aria-invalid="true" aria-describedby="email-err">
<span id="email-err">This email address is missing its @</span>

Deux règles structurelles complètent l’ensemble. Ne désactivez jamais le bouton d’envoi comme stratégie de validation – un bouton mort sans explication est une énigme, et le geste suivant de l’utilisateur, c’est de partir ; laissez-le envoyer, puis montrez précisément ce qui demande attention. (Le désactiver pendant un envoi en cours pour éviter un double débit est autre chose : c’est de l’état, pas un jugement.) Et la loi la plus profonde du canon : un envoi échoué préserve chaque frappe du travail de l’utilisateur. Un formulaire qui se vide sur erreur a pris plusieurs minutes de l’effort d’une personne et les a brûlées devant elle. Aucun raffinement visuel ne s’en remet.

Le canon en checklist

La forme opérationnelle de tout ce qui précède, à appliquer à n’importe quel formulaire avant sa mise en production :

Dans un design system, tout cela se durcit dans les composants de formulaire eux-mêmes – un champ texte livré avec son emplacement de libellé au-dessus, son emplacement d’erreur en dessous, sa temporisation de validation intégrée – de sorte que le canon tient par défaut et que la dérive demande un effort. C’est le même argument de systématisation que pour les tokens de mouvement : encoder la décision une fois, ou la rejuger dans chaque fonctionnalité.

Questions fréquentes

Un formulaire doit-il tenir sur une colonne ou sur deux ?

Une seule colonne. Une colonne unique rend l’ordre des réponses sans ambiguïté et mesurablement plus rapide à parcourir ; les dispositions multicolonnes provoquent des champs sautés parce que les utilisateurs tranchent l’ordre de lecture de façon incohérente. L’exception est la réponse composite – ville / région / code postal – qui est une seule question exprimée par des champs adjacents.

Quand la validation d’un formulaire doit-elle se déclencher ?

À la sortie du champ – quand l’utilisateur le quitte – et non à chaque frappe, ni, pour la plupart des formulaires produit, gardée pour l’envoi. La validation à la frappe critique des réponses inachevées ; la validation à l’envoi seul délivre tous les échecs d’un coup, même si le récapitulatif d’erreurs de GOV.UK est le bon choix là où l’annonce par lecteur d’écran est la contrainte déterminante. Un champ déjà marqué invalide peut être revérifié à chaque frappe, pour que l’erreur disparaisse dès la correction.

Peut-on utiliser le texte d’un placeholder comme libellé de champ ?

Non. Le placeholder tenant lieu de libellé disparaît dès que l’utilisateur commence à taper, exactement au moment où il a besoin de se rappeler la question, et transforme chaque champ rempli en donnée sans étiquette au moment de la relecture. Gardez un libellé visible au-dessus du champ et réservez les placeholders aux exemples de format.

Le bouton d’envoi doit-il rester désactivé jusqu’à ce que le formulaire soit valide ?

Non. Un envoi désactivé sans explication est une impasse que l’utilisateur doit diagnostiquer. Laissez-le actif et, à l’envoi, faites apparaître chaque champ non résolu avec une erreur précise et instructive juste à côté – tout en préservant tout ce que l’utilisateur a déjà saisi.