Le bouton «Continuer» du formulaire doit-il être désactivé si la validation est incomplète?
Dans les formulaires, nous voyons souvent le bouton "continuer" inactif jusqu'à ce que tous les champs obligatoires soient remplis:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Est-ce réellement une aide à l'utilisateur ou un obstacle?
J'imagine que le Pro pour cela est que c'est un indicateur visuel pour l'utilisateur qu'il n'a pas fini de remplir le formulaire ou de traiter les erreurs (car même avec la validation en ligne, un utilisateur ne sera pas informé s'il n'a jamais réellement interagi avec un champ ne montrera donc aucune erreur pour ceux à ce stade).
Mais le principal inconvénient de cela (que j'ai également constaté dans les tests d'utilisabilité) est que les utilisateurs ne comprendront pas pourquoi ils ne peuvent pas cliquer sur le bouton.
Le schéma de désactivation du bouton Continuer jusqu'à la fin de la validation offre-t-il réellement une expérience utilisateur négative?
Type d'informations collectées et nombre de champs requis
Cela dépend vraiment du type et de la portée des informations que vous demandez et du nombre de champs à remplir:
J'ai testé et utilisé ce modèle avec succès dans la création de connexion et de mot de passe. Je pense que parce que l'interface est si simple et que le nombre de champs requis est limité, il n'y avait aucune ambiguïté concernant les informations nécessaires pour activer le bouton Continuer.
(À mon avis), les utilisateurs sont généralement axés sur les tâches, donc commencer la tâche avant de terminer la tâche en s'engageant à agir.
À titre d'exemple, considérons le cas d'une page de création de mot de passe avec des exigences de mot de passe spécifiques (la situation pour laquelle j'ai conçu). Dans ce cas particulier, j'ai désactivé le bouton Continuer jusqu'à ce que toutes les règles pour le mot de passe soient remplies, la mise en garde étant que l'utilisateur devait obtenir des commentaires visuels lorsqu'il tapait son nouveau mot de passe et voyait sa saisie répondre à toutes les exigences de mot de passe.
Le système doit toujours tenir les utilisateurs informés de ce qui se passe, grâce à des commentaires appropriés dans un délai raisonnable.
source: 10 heuristiques d'utilisabilité pour la conception d'interface utilisateur
Voici un excellent exemple de cette approche qui intègre également une logique de gamification et vous pouvez tester la vraie chose ici à côté d'autres variantes:
Prévention des erreurs
En règle générale, j'essaie d'éviter (si possible) les messages d'erreur qui ajoutent à la frustration des utilisateurs et érodent leur confiance. Ainsi, au lieu d'afficher un message d'erreur en maintenant un bouton Continuer actif, j'essaierais de transmettre activement des conseils et des informations sur les champs requis quand et où cela est possible.
Encore mieux que de bons messages d'erreur est une conception soignée qui empêche un problème de se produire en premier lieu. Éliminez les conditions sujettes aux erreurs ou vérifiez-les et présentez aux utilisateurs une option de confirmation avant de s'engager dans l'action.
source: 10 heuristiques d'utilisabilité pour la conception d'interface utilisateur
Validation en ligne: fournir des messages d'erreur en contexte
Ci-dessous est un autre grand exemple d'un formulaire simple avec bouton désactivé, les champs sont validés en ligne et le bouton désactivé "secoue" pour indiquer l'incomplétude du formulaire. En ce qui concerne également votre point:
Même avec la validation en ligne, un utilisateur ne sera pas informé s'il n'a jamais réellement interagi avec un champ, il n'affichera donc aucune erreur pour ceux à ce stade.
Toute interaction avec le formulaire se traduit par une progression (coche) ou (message d'erreur en ligne). Le seul cas où cela ne fonctionnera pas est lorsque l'utilisateur clique sur "s'inscrire" sans fournir aucune information qui est hautement improbable/comportement irrationnel et que vous n'avez pas à y répondre.
Si vous traitez des formulaires plus longs et plus complexes, il vaut la peine de tout mettre en œuvre pour structurer votre formulaire en segmentation des informations requis dans de manière significative et en introduisant un processus par étapes/wizard ou un modèle similaire, le cas échéant. Cela vous aidera à optimiser votre conception et à la concentrer sur la prévention des erreurs.
Contenu des messages d'erreur
L'autre domaine que vous devrez peut-être considérer si "Soumettre" ou "Continuer" est activé est:
Il s'agit peut-être d'un cas Edge, mais il convient néanmoins de le mentionner; considérez un formulaire de connexion typique avec le bouton de connexion activé et l'utilisateur clique sur la connexion sans fournir de détails, quel serait le message d'erreur tel que l'utilisateur sans violer la sécurité du système: Le message le plus simple que j'ai vu, lisez ce qui suit: "Nom d'utilisateur ou mot de passe invalide"
Il s'agit d'un décalage évident entre ce que l'utilisateur a fait et ce que le système lui a transmis. Donc, dans ce cas spécifique, je choisirais de désactiver le bouton de connexion jusqu'à ce que les champs obligatoires soient remplis.
Quand un bouton désactivé pourrait-il être utilisé?
Le but d'un bouton désactivé est de prévenir et d'éviter les messages d'erreur et ils peuvent y parvenir de manière optimale lorsque:
- Le formulaire a un nombre limité de champs et les utilisateurs peuvent voir d'un coup d'œil quels champs sont manquants.
- Il y a un accent visuel sur les champs obligatoires et une rétroaction claire lorsque chaque champ est rempli (objectifs qui doivent être atteints pour activer le bouton)
- les étiquettes de champ sont courtes et peuvent être facilement numérisées , par exemple le nom, le nom d'utilisateur, la ville, etc., ce qui renforce le 1er point.
Tous les champs sont obligatoires car ils offrent aux utilisateurs un chemin clair pour activer le bouton et s'engager dans l'action *.
* Il me semble que lorsqu'il y a des champs facultatifs, les utilisateurs peuvent mal interpréter ce qui est réellement nécessaire pour activer le bouton, même si je n'ai pas de preuves pour le supporter.
Le bouton désactivé est-il un obstacle?
Ce n'est clairement pas . C'est un coup de main qui incarne une vieille maxime "Mieux vaut prévenir que guérir" mais cela comporte des mises en garde et nécessite de peser certains des facteurs que j'ai mentionnés ci-dessus et de le tester avec votre public cible pour vous assurer qu'il fait ce qu'il est censé faire.
Concevoir pour des personnes et non des machines
Les messages d'erreur punissent les gens de ne pas se comporter comme des machines. Il est temps de laisser les gens se comporter comme des gens. Lorsqu'un problème survient, nous devrions l'appeler erreur machine, pas erreur humaine: la machine a été mal conçue, exigeant que nous nous conformions à ses exigences particulières. Il est temps de concevoir et de construire des machines conformes à nos exigences. Arrêtez de nous confronter: Collaborez avec nous.
Je suppose que le point que j'essaie de faire valoir est que les "utilisateurs" sont des gens comme nous tous et nous ne devons pas sous-estimer leur intelligence et les traiter avec condescendance:
- Ils liront et comprendront les étiquettes si ce sont clair, lisible et concis
- Ils vérifieront ce dont ils ont besoin si le formulaire est bien structuré et conforme à ce qu'il souhaite réaliser (axé sur les tâches)
Je dois dire que ce comportement entrave l'expérience utilisateur.
Si vous avez déjà lu Don't Make Me Think by Steve Krug alors vous vous rendrez rapidement compte que ce modèle enfreint la règle énoncée dans le titre.
On pourrait se demander, pourquoi est-ce désactivé?
Il n'y a aucun avantage à faire sauter un utilisateur à travers ce cerceau.
Fondamentalement, ce que j'implique, c'est que l'utilisateur est accueilli avec un formulaire qui n'est pas actionnable et par la découverte, ou pire encore la lecture, il devra trouver comment utiliser correctement le formulaire qui lui est présenté.
Une solution de contournement serait d'attirer immédiatement l'attention sur les champs obligatoires, mais cela les ferait paniquer alors qu'ils se demandent pourquoi ils ont été accueillis avec un tas d'erreurs rouges même s'ils n'ont même pas touché le formulaire.
N'empêchez pas l'utilisateur d'accomplir sa tâche prévue de cliquer sur le bouton Soumettre, il est bon de savoir que le formulaire vous permet d'essayer avec un minimum de répercussions. Un léger message d'erreur indiquant "Veuillez vérifier les erreurs de formulaire surlignées en rouge" suffira.
Autres réflexions:
Je ne sais pas sur quels sites Web ou pages vous consultez fréquemment ce site, mais un rapide coup d'œil sur les 10 premiers formulaires de site Web "Contactez-nous" trouvés sur Google semble contredire votre observation.
Mes deux cents:
Si je devais deviner, la désactivation du bouton Soumettre est devenue une fonctionnalité par défaut d'un plugin de validation populaire et les "développeurs" le laissent tel quel.
nous voyons souvent le bouton "continuer" inactif
Je pense que cela peut être faux. Continuer à lire!
Pour ce que ça vaut, je suis en train de mettre à jour certaines anciennes recherches sur les formulaires d'inscription pour les sites Web populaires, et j'ai constaté qu'un pourcentage assez faible - environ 5% ou moins - désactivait le bouton Soumettre (que ce soit la dernière inscrivez-vous ou un continuez bouton de type) jusqu'à ce que les données soient jugées "valides".
Après avoir étudié tant de formes, cela devient un comportement visible plutôt que invisible comportement lorsque le bouton d'envoi est désactivé. C'est pourquoi je pense que vous pouvez sentir que vous le voyez plus souvent que vous ne le faites réellement.
Il y a aussi le problème supplémentaire avec les boutons désactivés, à moins que le formulaire ne fasse un travail remarquable de validation des données à la volée sans distraire l'utilisateur en même temps, alors il empêche l'utilisateur de voir ce qui ne va pas avec le contenu.
Un site qui le fait de manière acceptable est pour un identifiant BBC
Cependant, ils font exceptionnellement clair à la volée ce qui est valide et ce qui ne l'est pas.
Un autre exemple notable d'un formulaire d'inscription qui désactive le bouton est MailChimp, mais ils ne le désactivent que jusqu'au mot de passe est acceptable - pas tout le formulaire - vous pouvez donc entrer un mot de passe et activer le bouton - sans aucune autre donnée valide dans le formulaire.
Ils voient clairement le mot de passe comme quelque chose qui doit absolument être juste avant de pouvoir envoyer le formulaire. Le reste des données peut être validé lors de la soumission. Ils ne désactivent pas le bouton d'envoi pour la connexion.
Le formulaire d'inscription à Mailchimp est, à mon avis, exceptionnellement bon à bien des égards.
GoDaddy est un troisième exemple de site qui désactive le bouton d'envoi. Cependant, ici, ils ne désactivent pas le bouton jusqu'à ce que les données soient toutes valides - les champs doivent simplement être non vides - donc une lettre dans chaque champ fera l'affaire.
Ici, le bouton désactivé aide l'utilisateur à repérer les champs manqués plutôt que invalides des champs.
Donc en résumé:
Si vous voulez vraiment désactiver le bouton jusqu'à ce que toutes les données soient réellement valides alors le formulaire doit être très court et - exceptionnellement bien validé à la volée. Un formulaire long ne sera pas trop clair quant à ce qui ne va pas, et le niveau de validation requis serait trop distrayant pour tous les domaines.
Cela vous mettrait dans une petite minorité, surtout pour une validation complète - quel que soit le sentiment que vous le voyez "souvent" :)
Il ne faut pas désactiver le bouton
Considérez la situation du point de vue de l'utilisateur. Divisez les utilisateurs en deux groupes
- Ceux qui ne croient pas actuellement pouvoir continuer, ne recherchent donc pas un moyen de continuer
- Ceux qui croient qu'ils sont prêts à aller de l'avant et cherchent un moyen de le faire.
Pour l'ancien groupe, la désactivation du bouton "Continuer" n'est qu'un artefact visuel vu dans le coin de sa vision. Il est utile, mais pas plus utile que tout autre graphique décrivant l'état du formulaire. Pour ces personnes, un changement graphique (comme une flèche qui pointe vers le bouton Continuer ou un bouton Continuer en surbrillance) est tout aussi significatif qu'un bouton passant du gris au noir.
Pour ce dernier groupe, ils estiment que le formulaire est rempli. Un bouton désactivé leur fait savoir qu'ils ont tort, mais ne les aide pas à identifier ce qui s'est mal passé. Ils doivent maintenant scanner l'intégralité du formulaire qui, selon eux, est correctement rempli pour la notation manquante indiquant une section incomplète. Cela laisse passer une occasion d'interagir avec l'utilisateur. Cette interaction peut les aider à trouver les sections du formulaire qui ne sont pas entièrement remplies. Rater cette interaction transforme le formulaire en un casse-tête: "les administrateurs Web savent que vous avez fait quelque chose de mal, mais vous devez le trouver."
Étant donné qu'il existe d'autres façons de gérer l'indication graphique qu'un formulaire est complet (j'aime les boutons en surbrillance moi-même) et que le bouton Continuer permet aux utilisateurs de demander de l'aide, je ne vois aucune raison de désactiver le bouton.
Il s'agit d'une méta-réponse tirée des diverses opinions exprimées.
Si vous souhaitez désactiver le bouton, vous devez toujours vérifier les clics et indiquer pourquoi il est désactivé. Cela présente deux avantages: moins d'erreurs sont affichées et si, pour une raison quelconque, vous n'avez pas précédemment expliqué pourquoi le formulaire ne peut pas être soumis, vous pouvez le faire explicitement.
Les boutons sont destinés à être cliqués. Si l'utilisateur voit un bouton, il voudra cliquer. Le bouton désactivé ne devient actif que lorsque toutes les données sont remplies, ce formulaire spécifique n'est pas une bonne expérience. Je dirais plutôt à l'utilisateur (ce que je fais avec les formulaires que je conçois) dès le début que tous les champs sont obligatoires et que vous ne pouvez pas vous inscrire si l'un de ces champs reste vide. Votre formulaire n'est pas un jeu où l'utilisateur doit terminer le niveau auquel il joue pour en débloquer un autre. Juste une pensée :)
Oui le bouton " Continuer " doit être désactivé jusqu'à ce que tous les champs requis soient remplis avec à moins du texte (cela suppose que les champs obligatoires sont désignés comme tels par l'utilisateur d'une manière ou d'une autre). L'opportunité ici est que le système ne peut même pas tenter de continuer jusqu'à ce qu'il ait l'entrée requise de l'utilisateur.
Une fois les champs obligatoires remplis, le bouton " Continuer " doit être immédiatement activé pour indiquer que le système a ce dont il a besoin essayez de continuer.
À partir de là, cliquer sur le bouton " Continuer " exécutera validation complète et pourra renvoyer des messages de validation à l'utilisateur.
Le bouton "Continuer" d'un formulaire devrait être désactivé jusqu'à ce que tous les champs obligatoires aient été remplis et aient passé la validation.
Pourquoi? Eh bien, c'est du bon sens, vraiment:
Imaginez que vous êtes une banque. Et vous avez une configuration de formulaire simple qui permet le transfert d'argent d'une partie à une autre. Vous avez un "De quel compte souhaitez-vous transférer de l'argent?" , un champ "Destinataire" et un champ "Montant à envoyer".
Si l'un de ces champs n'est pas rempli, le transfert ne peut pas avoir lieu. À cet effet, les trois champs sont obligatoires. Sans les informations de tous les champs obligatoires, aucun transfert ne peut avoir lieu.
Maintenant, que se passe-t-il si nous rendons les trois champs obligatoires et que nous l'indiquons à l'utilisateur, et que l'utilisateur entre en effet des informations dans tous les champs obligatoires, mais qu'ils font une erreur dans le champ "Montant à envoyer"?
Disons simplement que l'utilisateur a entré 0,00.
Eh bien, nous ne pouvons pas envoyer 0,00 $. Si le backend n'est pas configuré correctement pour gérer des cas tels que l'envoi de zéro dollar, que pourrait-il se passer? Lorsque l'utilisateur clique sur "Continuer", cela entraîne non seulement une perte de bande passante et de temps, mais également une perte de bande passante et de temps pour votre utilisateur. Et dans les affaires, le temps est égal à l'argent, et si beaucoup de gens font constamment des erreurs ou n'entrent pas dans les détails quand ils devraient l'être, vous créerez effectivement beaucoup trop de frais généraux pour vous-même (en permettant d'utiliser trop de ressources) et moi Je parie que cela finira par provoquer des données incompatibles à un moment donné.
De plus, en tant qu'utilisateur, ne pas valider un formulaire et me permettre de continuer sans me dire que quelque chose ne va pas est très ennuyeux. Surtout quand la page s'actualise et m'oblige à tout remplir une seconde fois.
Je pense qu'il existe un juste milieu. Un bouton désactivé visuellement ne doit pas signifier que cliquer dessus ne fait "rien" comme suggéré. Cela empêchera logiquement l'utilisateur d'avancer en l'absence de tout ce qui est nécessaire pour activer cette action principale, mais il n'y a aucune raison que cliquer dessus ne puisse pas présenter un message d'alerte à l'utilisateur expliquant pourquoi il est désactivé et comment l'activer.
Lors de la conception de certaines pages Web, je suis venu sur ce site pour voir ce que les autres avaient à dire pour prendre certaines décisions. J'ai conclu que la meilleure réponse est "cela dépend".
J'ai pensé à mes propres expériences avec des boutons activés qui ne font que me dire ce que j'ai fait de mal et, parfois sur une page Web mal conçue, tout effacer! Je me sens particulièrement ennuyé lorsque je suis sur un long formulaire et l'erreur est en haut de la page ... que je ne vois pas jusqu'à ce que je clique plusieurs fois sur le bouton Soumettre, puis que je défile vers le haut pour voir le problème. De plus, tous les sites Web ne précisent pas ce qui est requis jusqu'à ce que le bouton Soumettre soit cliqué. Ne m'attrapez pas un mauvais jour avec un site Web qui me dit après le fait que je dois entrer quelque chose!
Je pense que les pages Web devraient être absolument claires sur ce qui est requis sur un formulaire AVANT d'appuyer sur un bouton afin que, si je clique sur le bouton Soumettre avant d'entrer dans un champ obligatoire, je pense, duh, je ne peux pas croire que j'ai raté cela, je savais c'était nécessaire! D'un autre côté, je dois convenir avec Jase que je ne veux certainement pas qu'un bouton Soumettre soit activé sur le site Web de ma banque avant d'avoir entré tous les champs obligatoires! J'utilise le site Web de ma banque plus que tout autre site et le bouton désactivé ne m'a jamais causé de confusion.
Alors, ma conclusion? Si vous avez un formulaire complet avec plusieurs champs, certains sont obligatoires, certains facultatifs, marquez clairement tous les champs obligatoires, activez le bouton Soumettre et, lorsque le formulaire est soumis avec des données requises invalides ou manquantes, mettez en surbrillance les champs problématiques et répertoriez les messages avec les erreurs. Si vous avez un formulaire où tous les champs apparaissent sur la même page ... avec le bouton Soumettre, désactivez le bouton et indiquez clairement ce que l'utilisateur doit faire pour activer le bouton. Le bouton Soumettre peut également être activé; cependant, dans les deux cas, cela devrait très bien fonctionner et offrir une bonne expérience utilisateur ... c'est là que réside la beauté de la conception Web ... à vous de choisir! Enfin, sachez quelle voie est plus difficile à coder, car cela peut également vous aider à prendre une décision dans un sens ou dans l'autre lorsque l'un ou l'autre semble correct ... garder les coûts bas pour le client devrait toujours être une considération.
Oh ... et à quelle fréquence l'utilisateur type "désactive" son code HTML? Je pense que ce n'est pas courant et l'utilisateur moyen (non informatique) ne sait même pas comment le faire, donc je ne pense pas que ce soit une raison suffisante pour en tenir compte lors de la conception d'un site Web convivial. Si l'utilisateur est assez intelligent pour désactiver son HTML, il doit savoir qu'il doit l'activer pour que le site Web soit pleinement fonctionnel !! Bonne conception! :)
Je serai bref et précis, car la plupart des réponses couvrent déjà de nombreux domaines valables et valables.
Est-ce que cela ajoute de la valeur?
Je ne suis pas en mesure de penser à un cas où l'utilisateur verra/devrait regarder le bouton continuer pour savoir s'il a fini de remplir un formulaire. Chaque fois qu'un utilisateur souhaite cliquer sur le bouton, il croit il a terminé le formulaire et le diriger vers toutes les actions requises est nécessaire à ce stade. En principe, cela devrait déjà être clair sous une forme bien conçue, mais le fait que l'utilisateur a cru qu'il avait terminé prouve que ce n'était pas le cas, ainsi se concentrer, clignoter temporairement ou d'une autre manière diriger l'utilisateur est un bon plan d'action.
Qu'en est-il de la validation qui n'est pas synchrone?
Une chose qui n'a pas encore été abordée est que de nombreux formulaires sont des formulaires Web ou autrement dépendants d'Internet et toutes les validations ne peuvent pas être instantanées. Pour donner un exemple typique d'un formulaire d'inscription avec un nom d'utilisateur: le nom d'utilisateur doit être recherché dans la base de données et si le nom d'utilisateur est déjà utilisé, le champ nécessitera la saisie d'un nom d'utilisateur différent. Normalement, c'est une recherche extrêmement rapide, mais que se passe-t-il si l'utilisateur utilise par exemple l'Internet mobile et vient de perdre sa connexion ou a une connexion incroyablement lente? Avec un bouton continuer désactivé, l'utilisateur se retrouvera avec un formulaire rempli et aucun bouton sur lequel cliquer sera plus déroutant que de cliquer sur un bouton et d'attendre la page suivante pour charger lequel un tel utilisateur sur une mauvaise connexion Internet sera utilisé à prendre un peu plus longtemps.
Bien sûr, ce qui précède peut être quelque peu évité si les champs en attente de validation le montrent très clairement, mais ce n'est généralement pas fait et si tous les champs sont vérifiés en direct côté serveur, comme cela est de plus en plus courant, cela pourrait être source de confusion pour l'utilisateur: "Pourquoi y a-t-il un truc qui tourne à côté de mon nom complet?". Donc, si vous souhaitez faire cela, la seule solution à laquelle j'ai pu penser était de mettre un spinner dans le bouton d'envoi désactivé pendant la validation. Le seul danger est que l'utilisateur puisse penser qu'il a déjà envoyé le formulaire par erreur, car un bouton désactivé est souvent associé à un état cliqué/poussé.
Je pense qu'il est mauvais de le désactiver en ce qui concerne la validation des contraintes de formulaire HTML natif. Il enlève toute convivialité de la validation du formulaire, vous laissant juste la validation.
Par exemple, lorsque vous remplissez quelque chose dans le champ a et appuyez sur Entrée, rien ne se passe. Vous n'obtenez aucune rétroaction visible. Vous ne savez pas ce qui est requis en regardant simplement l'interface utilisateur visuelle.
<form>
<input type="text" name="a" required>
<input type="text" name="b" required>
<input type="submit" disabled>
</form>
Où comme si le bouton était activé
<form>
<input type="text" name="a" required value="sometext">
<input type="text" name="b" required>
<input type="submit">
</form>
Maintenant, si vous appuyez sur Entrée après avoir entré quelque chose dans le champ a, vous obtenez une fenêtre contextuelle et le champ de saisie est également concentré
Avoir une validation de formulaire parfaitement structurée sans désactiver le bouton continuer
- Vous n'auriez pas besoin de Javascript
- La page ne se rechargerait pas (économisant ainsi la bande passante)
- Vous obtenez de bons commentaires détaillés dans votre propre langue pour ce qui ne va pas (nombres parlants avec étape, min max ajouté - vous obtenez quelque chose comme: "entrez un nombre valide, les deux nombres valides les plus proches sont x, y")
- Le champ rempli à tort est également ciblé
- Ne rend pas un utilisateur confus quant à la raison pour laquelle il ne peut pas cliquer dessus, en fait c'est le contraire, vous savez maintenant ce qui ne va pas avec le formulaire