Nous avons plusieurs formulaires différents dans le cadre d'une application médicale basée sur le Web. Ces formulaires ont plusieurs champs - 10-20 selon le formulaire. Chacun a au moins 5 champs obligatoires. Nous désactivons actuellement le bouton Enregistrer jusqu'à ce que ces champs obligatoires soient tous remplis.
Nous avons débattu de l'opportunité d'une meilleure expérience utilisateur pour activer le bouton d'envoi par défaut, puis afficher un message d'erreur (et mettre en surbrillance les champs obligatoires manquants) si le bouton d'envoi est cliqué avant que tous les champs obligatoires soient remplis.
Des recherches ou des opinions judicieuses sur ce qui pourrait être mieux? Nous nous penchons vers cette dernière approche car nos formulaires sont assez longs - leur permettre de soumettre puis de trouver des erreurs pourrait être plus efficace que la charge cognitive de la recherche dans le formulaire pour voir pourquoi le bouton n'est pas activé.
Si le bouton est simplement désactivé, les utilisateurs
Je suggère donc de dire à vos collègues exactement ce que vous nous avez dit, à savoir que
leur permettre de soumettre puis de rechercher des erreurs pourrait être plus efficace que la charge cognitive de rechercher dans le formulaire pour voir pourquoi le bouton n'est pas activé.
Si le bouton d'envoi est désactivé, vous devez absolument dire à l'utilisateur pourquoi il en est ainsi.
Alors pourquoi ne pas afficher un court message indiquant la cause du bouton désactivé lorsque c'est le cas?
Ce court message pourrait être affiché sous le formulaire - peut-être en rouge ou surligné d'une autre manière. Et puis cette approche offre la meilleure expérience utilisateur à mon avis.
Vous devrez probablement implémenter l'autre approche de toute façon, pour les utilisateurs sans javascript ou autre ...
La valeur ajoutée en laissant le bouton "Soumettre" activé est que l'utilisateur ne se soucie pas de ce qui est requis. je clique sur soumettre et je veux en finir.
Nous nous efforçons d'indiquer quand quelque chose n'est pas encore valide:
Ils peuvent toujours cliquer sur OK, mais en cas de problème, nous attirons rapidement et facilement leur attention sur l'élément non valide. Nous y avons même mis l'accent sur le clavier, afin qu'ils puissent faire des choses importantes:
Grâce à ma propre utilisation du logiciel (et j'ai observé d'autres utilisateurs), je ne me soucie pas de ce qui est requis. Et j'ai appris que le logiciel ne me permettra de sauvegarder que si tout est fait. Et le logiciel va même focus les éléments dont je dois m'occuper.
Donc ma procédure dans le logiciel est devenue:
La meilleure pratique lors de la soumission du formulaire est de désactiver le bouton de soumission (et d'indiquer une sorte d'état occupé) pour éviter la soumission en double. Je ne ferais rien qui pourrait perturber ce problème, ce qui, je pense, désactiverait le bouton pour toute autre raison.
Je vois d'où vous venez, mais vraiment, si vous désactivez le bouton pour une raison, l'utilisateur doit trouver cette raison. Le bouton désactivé est un indicateur indirect des besoins. Mieux vaut indiquer ces exigences directement et éviter l'étape supplémentaire - cela réduira le nombre de formulaires remplis.
Vous pouvez également envisager de valider les champs en ligne (avec validation après avoir rempli le champ), afin d'éviter quelque peu le problème. Cela aide également lorsque les formulaires sont longs et que la soumission a le potentiel de mettre en évidence de nombreuses erreurs. Vous faites probablement déjà une sorte de validation afin de détecter s'il faut activer le bouton d'envoi, donc ce ne peut pas être un grand pas pour faire la validation en ligne? Gardez l'indicateur de réussite bien en évidence, permanent et en dehors du champ du formulaire.
En savoir plus sur le sujet de la validation en ligne sur le site A List Apart , il y a quelques informations utiles, y compris la question de savoir si la validation en ligne est appropriée pour un formulaire donné. Par exemple, il est plus utile sur des questions plus difficiles, mais l'incohérence de l'avoir sur certaines mais pas sur toutes les questions est discutable.
(Envisagez des tests A/B pour vérifier que ces changements améliorent vos résultats)
Les problèmes (IMO) liés à la désactivation du bouton d'envoi - et, je présume, à l'utilisation de type javascript pour valider et afficher les messages - sont doubles. Tout d'abord, l'utilisateur doit réanalyser la page entière pour identifier ce qui n'est pas valide et se rendre compte qu'il doit avoir mis quelque chose de mal. Il s'agit d'une charge cognitive élevée et/ou d'un affichage assez difficile des messages appropriés.
Cependant, deuxièmement, une validation plus complexe (c'est-à-dire sur plusieurs champs), et si vous effectuez une validation au fur et à mesure, l'utilisateur verra des messages d'erreur clignoter à l'intérieur et à l'extérieur, ou des messages montrant sur des champs qu'ils n'entrent pas actuellement.
Je préférerais voir un bouton qui vous permet de "progresser" - alors soumettez les modifications, validez votre entrée et continuez. Cela ressemble à ce que je veux faire. La désactivation d'un bouton indique que ce n'est pas une action viable, c'est-à-dire que soumettre le formulaire (valider et passer) n'est pas quelque chose que je devrais m'attendre à faire. Parfois, lorsque cela est clairement indiqué, la désactivation du bouton pour l'entrée REQUISE est OK, mais pas pour l'entrée INVALIDE.
Tous, à mon humble avis, bien sûr !!!
... Notez que j'ai dit "valide", pas "complet". Il y a une belle section dans À propos de Face sur les formulaires incomplets. Le conseil est que si vous pouvez utiliser le formulaire dans un état incomplet, faites-le et trouvez un autre moyen d'acquérir le reste des informations. Cela ne fonctionne que si vous avez des personnes qui examinent régulièrement les formulaires et ajoutent des informations requises, cependant - qui peuvent ne pas correspondre au contexte d'utilisation de vos utilisateurs.