Les boutons désactivés devraient-ils donner leur avis lorsqu'ils sont cliqués?
Je me demandais si vous pouviez m'aider avec un problème UX auquel je fais face avec des "boutons désactivés dans Mobile"
Nous avons quelques champs de saisie différents dans le cadre d'un processus d'intégration mobile. Ces formulaires comportent plusieurs champs et nous désactivons actuellement le bouton suivant jusqu'à ce que ces champs soient tous remplis. Mais, si l'utilisateur appuie sur le bouton désactivé, il affichera un message d'erreur en ligne sur les champs de saisie non remplis.
Nous avons débattu de l'opportunité d'une meilleure expérience utilisateur pour afficher des commentaires lorsque l'utilisateur appuie sur le bouton désactivé pour montrer qu'il manque quelque chose ou si les boutons désactivés ne devraient généralement pas avoir de réaction car ils sont désactivés.
Au final, les deux voies conduisent au même résultat. Que ce soit une erreur en ligne ou peut-être une bulle avec des commentaires, l'utilisateur apprend pourquoi il ne peut pas continuer (ce qui respecte visibilité de l'état du système ).
Le point sur les éléments désactivés n'ayant jamais d'action est compréhensible, mais le strict respect de cette règle n'est pas vraiment utile à l'utilisateur. S'il pouvait avoir une meilleure expérience utilisateur avec votre produit pour le petit prix de ne pas respecter une règle à 100%, je dirais que ça vaut le coup. Vous ne le cassez pas complètement de toute façon, vous en déviez légèrement.
Cela étant dit, je pense personnellement que donner cette rétroaction de cette façon pourrait être considéré plus moderne ou "plus cool" . Donc, surtout si vous ciblez un public plus jeune, je dirais que ce serait une amélioration.
Un inconvénient ici peut être que certains utilisateurs, qui sont très habitués aux "anciennes méthodes", pourraient potentiellement trouver cela inattendu et donc ennuyeux. Mais cela semble être une chance plutôt faible.
Également une autre chose à considérer: Utilisateurs ayant une déficience visuelle . Leurs lecteurs d'écran peuvent très bien saisir les messages d'erreur en ligne (pour autant que je sache), mais une bulle de dialogue peut être délicate. À tout le moins, il devrait alors simplement se concentrer sur l'apparence du système.
Quelque chose comme ça semble être une bonne façon de le faire:
Source
Vous pouvez soit l'afficher en cliquant sur le bouton ou avoir un bouton plus petit (?) Placé dessus, qui à son tour ne casse pas le règle du bouton désactivé.
Si ce n'était pas mobile , je dirais qu'il serait préférable d'avoir un message affiché à côté du bouton désactivé disant
Veuillez remplir les champs obligatoires restants (marqués d'un *)
ou certains (orfèvrerie requise).
Mais pour mobile , où vous n'avez pas cet immeuble, avoir le bouton actif (non désactivé) et le faire dire à l'utilisateur quels champs ils ont encore besoin de remplir lorsque cliqué semble raisonnable. Je ne ferais pas le bouton désactivé mais répond toujours aux clics, mais peut-être pourrait-il dire (Impossible d'envoyer encore) vs (lorsque tous les champs obligatoires sont remplis) Envoyer .
N'oubliez pas l'accessibilité. Il y a diverses choses vous pouvez y faire. L'un d'eux est que vous pouvez rendre le "conseil" que l'utilisateur malvoyant entend pour le bouton différent et plus long que ce qui est affiché visuellement, si l'utilisateur utilise les lecteurs d'écran populaires pour mobile (VoiceOver pour iOS, TalkBack pour Android ). Détails ici et ici . Par exemple, le message pourrait indiquer "Veuillez remplir les champs prénom, nom et e-mail". Assurez-vous de tester avec des lecteurs d'écran.
C'est ainsi que le processus d'inscription à Google le fait. Cela devrait être très similaire à votre processus. Notez que le bouton principal est toujours activé, il ne change que sa fonction!
- Vous êtes présenté avec un joli formulaire explicite
- Le bouton Suivant a la couleur principale et peut être cliqué. Notez que le bouton secondaire vous amène à un processus complètement différent (connectez-vous dans ce cas.)
- Après avoir soumis le formulaire invalide via le bouton Suivant, vous faites défiler jusqu'au premier formulaire invalide et tous les contrôles sont validés (même lorsqu'ils ne sont pas sales). Vous verrez donc tous les contrôles invalides sur votre chemin vers le bouton Suivant.
La seule différence pour vous est que vous semblez avoir des champs optionnels. Vous pouvez les marquer avec (facultatif) ou les rassembler sous une forme complètement facultative qui, en plus d'un Suivant, a un bouton Skip (Ceci est très souvent utilisé pour les numéros de téléphone.)
Si votre formulaire devient trop volumineux, demandez-vous si toutes les données requises sont vraiment nécessaires lors de l'inscription. Si l'utilisateur déclenche lui-même des actions qui nécessitent plus de données - comme un achat dans une boutique en ligne - il il est préférable d'exiger uniquement un mode de paiement et une adresse.
En partant du concept de `` décisions éclairées '', il est toujours préférable de fournir aux utilisateurs suffisamment de directives pour qu'ils ne fassent aucune erreur au lieu de leur faire découvrir que ce qu'ils ont fait était tout faux. Si les champs du formulaire doivent être marqués d'un astérisque * ou d'une autre manière avec les autres intentions de conception, le formulaire sera rempli correctement et il ne devrait pas être nécessaire de désactiver le bouton Soumettre. Je recommande de ne pas utiliser de boutons désactivés sauf si cela est vraiment nécessaire.
Pour moi, il semble que vous n'ayez pas désactivé le bouton "suivant", mais que vous ayez changé son comportement. Donc au lieu de
enabled (action a) ↔︎ disabled (no action)
vous avez maintenant
enabled (action a) ↔︎ enabled (action b)
En soi, ce n'est pas nécessairement un problème à moins que vous ne le rendiez réellement désactivé. Si vous le faites, vos utilisateurs s'attendront à ce que les autres boutons "désactivés" aient un comportement. Lorsqu'ils rencontrent un bouton réellement désactivé (c'est-à-dire sans comportement), ils peuvent avoir l'impression que le bouton est cassé, car on s'attend à ce que les boutons "désactivés" donnent un retour (ou au moins aient une action).
Voici, si je comprends bien, votre solution actuelle:
L'utilisateur n'a aucune indication sur lequel des deux derniers boutons réagira à l'interaction.
Considérez plutôt une distinction visuelle entre "activé", "désactivé mais pas vraiment" et "désactivé pour de vrai", par exemple:
De cette façon, vous avez une distinction entre l'état ordinaire, l'état de rétroaction et réellement désactivé.
Je pense que la façon dont vous l'avez décrite est logique. Je voudrais inclure un astérisque sur tous les champs obligatoires, même s'ils sont tous obligatoires. Vous pourriez même avoir une note en haut indiquant que tous les champs sont obligatoires. Tout ce qui peut aider l'utilisateur à comprendre quoi faire sur un formulaire complexe est préférable.
Étant donné que l'espace d'écran vertical mobile est (presque) illimité, je voudrais simplement ajouter un message permanent juste au-dessus du bouton désactivé.
Vous devez indiquer votre nom et votre numéro de mobile et accepter nos conditions générales de vente avant de continuer.
Étant donné que le message n'apparaîtra que si quelqu'un fait défiler jusqu'au bouton Suivant, il ne sera visible que par les utilisateurs qui atteindront le bouton sans avoir rempli tous les champs nécessaires. Et vous pouvez laisser les personnes handicapées = aucune politique de réaction intacte.
En observant comment les utilisateurs utilisent mon application, j'ai vu que les boutons désactivés sont toujours appuyés par une partie importante des utilisateurs, en particulier ceux qui connaissent moins techniquement. Cela s'est produit même lorsque le bouton désactivé était clairement grisé.
Ma solution consiste généralement à déclencher une réponse de validation si un bouton désactivé est enfoncé. L'observation du comportement avant et après la mise en œuvre d'un tel message de validation a en effet eu l'effet souhaité.
L'autre solution consiste à ne pas désactiver le bouton d'action et à afficher un message de validation comme il le ferait normalement ( exemple sur stackexchange).
Je ferais d'abord quelques tests d'utilisabilité pour voir si tout cela est important. Vous ne pouvez pas garantir une expérience utilisateur exceptionnelle sans inclure l'utilisateur, non? Faites des tests d'utilisabilité pour voir si les utilisateurs ne savent pas pourquoi le bouton est désactivé. Vos utilisateurs particuliers pourraient comprendre pourquoi il est désactivé et cela pourrait ne pas être un problème. L'ajout de bulles d'aide ou d'autres éléments ne fait qu'ajouter à la complexité de votre interface dont vous ne savez pas avoir besoin.
Si vos utilisateurs cliquent constamment sur le bouton désactivé, vous devez déterminer pourquoi. Cliquent-ils parce que cela ne semble pas désactivé? C'est peut-être un problème d'accessibilité visuelle? Cliquent-ils parce qu'ils sautent accidentellement l'un des champs obligatoires? J'ai eu cela une fois où l'utilisateur devait cocher la case pour accepter les termes et avec tous les autres contenus à l'écran, ils ne l'ont pas vu. Puis, lorsqu'ils sont arrivés à la fin du formulaire, ils n'ont pas compris pourquoi le bouton était désactivé.