Dois-je masquer le bouton Continuer jusqu'à ce que les tâches soient terminées?
Dans un assistant en plusieurs étapes, certaines étapes présentent à l'utilisateur une liste de tâches qui doivent être effectuées avant de passer à l'étape suivante.
Chaque tâche de la liste ouvre une fenêtre contextuelle où l'utilisateur termine la tâche.
J'ai trois solutions possibles pour le bouton continuer:
a) Montrez-le tout le temps. Si l'utilisateur clique dessus avant que toutes les tâches soient terminées, l'utilisateur recevra des informations sur ce qui doit être fait avant de pouvoir continuer.
b) Afficher un bouton désactivé, qui est activé lorsque toutes les tâches sont terminées. Dans son état désactivé, le bouton affichera un message générique indiquant que toutes les tâches doivent être terminées avant de pouvoir continuer.
c) Cachez le bouton et affichez-le uniquement lorsque toutes les tâches sont terminées.
Mon application Web a le même flux de travail et nous montrons une version désactivée du bouton Continuer qui est activé lorsque tous les champs du formulaire ont été saisis. Si l'utilisateur clique sur le bouton Continuer sans entrer toutes les informations, un message utilisateur s'affiche dans la fenêtre contextuelle, donc je pense que B est la meilleure solution.
L'option A peut être frustrante pour l'utilisateur car il peut cliquer sur Continuer et obtenir un message d'erreur. Le bouton Continuer désactivé fournit une indication visuelle conventionnelle dont ils ont besoin pour terminer les tâches avant de pouvoir continuer.
L'option C peut prêter à confusion pour l'utilisateur car il ne saura pas qu'il y a une prochaine étape ou s'il peut continuer. En outre, il n'est pas recommandé de masquer les commandes de navigation principales. J'espère que cela vous aidera!
C'est un anti-modèle pour désactiver visuellement les opportunités, désactiver fonctionnellement les opportunités ou masquer les opportunités. VEUILLEZ ne pas le faire. Je vais plaider pour les trois.
Désactiver ou masquer les opportunités est l'une de mes plus grandes bêtes noires, d'autant plus qu'il s'agit de suringénierie de la solution:
- C'est toujours un effort d'ingénierie et de conception supplémentaire de cacher ou de désactiver quoi que ce soit par intermittence.
- La validation des données côté client n'est qu'une des nombreuses façons dont la sauvegarde des données (ou un autre résultat final) pourrait échouer, donc même si la validation côté client réussit, et que vous "affichez" et "activez" votre bouton, il pourrait y avoir être toujours une erreur lorsque l'utilisateur clique sur Continuer, et vous devez toujours gérer cette erreur de manière agréable. Par exemple, la validation côté serveur peut échouer, il peut y avoir une défaillance du réseau ou d'un autre serveur, il peut y avoir une erreur de système de fichiers sur l'appareil, etc.
- Parfois, la validation côté client est incorrecte (obsolète ou boguée) ou échoue simplement à "afficher" ou "activer" le bouton au bon moment. Cela bloquerait complètement un sous-ensemble d'utilisateurs, et il est difficile de détecter ce type d'erreur - en général, vous attendez qu'un utilisateur contacte le support et que ces informations soient transmises aux personnes qui peuvent y remédier.
En résumé, votre effort supplémentaire de conception et d'ingénierie crée plus de risques que de valeur. Même si vous pensez que vous pouvez atténuer les risques à 100%, il s'agit toujours d'un anti-schéma, comme expliqué ci-dessous.
————————————————
De la plus offensive à la moins offensive:
Pourquoi ne devriez-vous pas cacher des opportunités?
Tout d'abord, pourquoi devriez-vous cacher quelque chose ? Vous devez cacher des objets à des fins de confidentialité ou de sécurité. Maintenant, pourquoi y a-t-il la possibilité? Il sert à deux fins: la communication sur l'utilité de l'application et un mécanisme permettant à l'utilisateur de communiquer ses intentions et ses convictions à l'application. Donc, vous ne devez pas cacher les opportunités à moins que vous n'essayiez de rendre l'utilitaire de votre application privé ou sécurisé. Supposons à ce stade que vous n'essayez pas de garder le secret ou de sécuriser le fait que votre application a la capacité de Continue, et donc vous avez rendu le bouton visible en permanence. À ce stade, notons les avantages d'une accessibilité visible:
- L'utilisateur peut le découvrir - il peut en apprendre davantage sur les capacités de l'application.
- Connaître les capacités de l'application motive à l'utiliser et accomplit des tâches sur le chemin de la réalisation de ces capacités. Par exemple. ils sont plus motivés à remplir le formulaire car ils savent qu'à la fin ils peuvent "continuer".
- Les utilisateurs expérimentés savent où le trouver et - c'est un peu drôle - mais savoir que vous l'avez trouvé, même si pour une raison quelconque vous n'êtes pas autorisé à l'utiliser en ce moment, est vraiment important et satisfaisant pour l'expérience utilisateur. Si vous ne le trouvez pas, vous vous demandez s'il est déplacé ou si votre mémoire vous fait défaut, et vous finissez généralement par regarder autour de vous pendant un certain temps et finissez par perdre confiance en l'application. Ont-ils supprimé la fonctionnalité? Est-ce cassé? Vont-ils le déplacer tous les quelques mois?
Pourquoi ne devriez-vous pas désactiver fonctionnellement les opportunités?
Nous l'avons abordé dans la section précédente. Cela se résume au deuxième objectif d'une accessibilité: en tant que mécanisme permettant à l'utilisateur de communiquer ses intentions et ses convictions à l'application. C'est un point de confusion majeur. La plupart des concepteurs et des développeurs prennent l'avantage à leur valeur nominale: un bouton qui dit "continuer" continuera lorsque vous cliquez dessus, ou un bouton qui dit "supprimer" supprimera lorsque vous cliquez dessus. C'est le but ultime, mais le bouton est bien plus que cela. En cliquant sur un bouton, l'utilisateur communique un ou plusieurs des éléments suivants:
- ils ont l'intention d'effectuer une action
- Capturer l'intention de l'utilisateur est un miracle. Vous devez absolument utiliser ces informations à votre avantage - vous avez un utilisateur prêt et disposé à vos côtés. Guidez-les à travers l'entonnoir.
- ils croient que l'action se produira quand ils cliquent dessus
- L'utilisateur vient de vous communiquer quelque chose qu'il n'a pas d'autre moyen de transmettre qu'en cliquant sur le bouton: il pense avoir satisfait aux critères pour effectuer cette action. S'ils ne le font pas, c'est l'occasion idéale de les guider et le meilleur moment pour communiquer avec eux, car ils interagissent activement avec l'application.
- ils croient qu'ils sont censés cliquer dessus
- Peut-être qu'ils sont un nouvel utilisateur avec une expérience passée différente, ou peut-être qu'ils sont nouveaux sur Internet (sans blague), ou peut-être qu'ils sont un peu flous aujourd'hui (ou tous les jours). Mais pour une raison quelconque, ils ont cliqué sur ce bouton en pensant que cela ferait l'affaire. Ce ne sera pas ... mais encore une fois, c'est l'occasion idéale de les entraîner vers le succès - évidemment, ils ont déjà parcouru toutes les autres communications dans l'interface utilisateur pour cliquer sur ce bouton. Le bouton a attiré leur attention, alors dirigez leur attention sur ce qu'ils devraient réellement faire (tout ce qu'ils doivent réparer).
Enfin, Pourquoi ne devriez-vous pas désactiver visuellement l’opportunité?
Tout simplement parce qu'une accessibilité handicapée n'est pas une accessibilité. Depuis que vous vous êtes donné la peine de faire correspondre le style visuel des boutons qui ne font rien, vous avez réussi à informer l'utilisateur qu'il ne fait rien. Par conséquent, cela n'attirera pas leur attention, ils ne croiront pas qu'ils sont censés cliquer dessus, ils ne croiront pas que cela fera quoi que ce soit, et donc ils ne croient pas qu'ils ont un moyen de communiquer leurs intentions ou leurs croyances ( ou confusion) pour vous. Ils pourraient chercher autre chose sur la page, mais que se passe-t-il s'ils continuent à le manquer en raison d'une autre défaillance UX ou d'une défaillance de code? Il serait tellement plus facile et plus rapide de cliquer sur le bouton sur lequel ils croient qu'ils sont prêts à cliquer, puis vous pourriez leur donner des conseils clairs sur la suite des choses. En d'autres termes, l'utilisateur est "perdu" dans l'interface plutôt que "tôt" pour cliquer sur le bouton.
Si les tâches sont obligatoires, et qu'elles ne devraient l'être que pour les fonctionnalités qui améliorent l'expérience, comme la sélection de la couleur d'une veste avant de procéder à l'achat, alors mon conseil serait d'avoir le bouton visible, mais désactivé.
Ceci, combiné à une bonne utilisation des champs de marquage en option et à la messagerie, devrait permettre à vos utilisateurs de suivre les étapes sans problème.
Oui, nous ne voulons pas ennuyer les gens, cela ne veut pas dire que nous ne devrions pas utiliser de contrôles pour nous assurer que le résultat attendu pour l'utilisateur est correct et qu'ils ne sont pas ennuyés en arrivant à la fin d'un processus et avoir à revenir à une page pour terminer une action que nous n'avions pas appliquée, même si elle était requise.
Défi du cadre: la plupart du temps, le flux de travail "assistant" en plusieurs étapes qui ne vous permettra pas de continuer (ou même de voir) ce qu'il va vous demander jusqu'à ce que vous ayez terminé ce qu'il vous demande en ce moment est hostile à l'utilisateur et est un motif sombre. Pour l'utilisateur, on a l'impression qu'on lui demande de fournir des informations avant de savoir si cela va être bénéfique pour lui, ou s'il va être en mesure de mener à bien l'ensemble de l'opération - cela peut se révéler ils n'ont pas d'informations supplémentaires dont ils auront besoin à une étape ultérieure, ou qu'une étape ultérieure leur dira qu'ils ne sont pas qualifiés pour continuer.
Le bon UX, si tout mettre sur une seule page est trop écrasant, est un processus paginé qui:
- vous permet de vous déplacer librement d'avant en arrière sans saisir toutes les informations
- indique clairement que vous pouvez le faire
- vous indique clairement si vous avez omis les informations qui seront nécessaires avant de pouvoir terminer l'ensemble du processus
- indique clairement si votre travail partiel sera ou peut être enregistré si vous abandonnez le processus ou le mettez de côté jusqu'à plus tard
J'ai récemment travaillé sur un assistant similaire en plusieurs étapes qui a aidé les médecins à trouver les licences médicales appropriées.
TL/DR: nous sommes allés avec l'option bouton désactivé.
Puisque nous avons suivi une approche progressive et étape par étape où la réponse à chaque question a guidé les questions suivantes, le CTA "Continuer" devait être après chaque réponse. Veuillez noter que toutes les questions étaient obligatoires sur ce flux.
Pour cela, nous avons testé les deux approches suivantes
- Afficher un bouton "continuer" actif qui indique l'état "actif" - quoi qu'il arrive.
- Affichage d'un bouton "Continuer" désactivé qui devient actif lorsque l'utilisateur a effectué l'action/la sélection unique nécessaire pour continuer.
Nous n'avons pas testé la troisième option de masquer le CTA `` Continuer '' car nous pensions essentiellement que ce n'était pas intuitif avec une réflexion insuffisante de l'état du système.
Nos constatations étaient les suivantes:
- La deuxième option (désactiver le bouton jusqu'à ce qu'il soit pertinent) a fourni un repère visuel aux utilisateurs sur les zones d'action sur lesquelles se concentrer.
- Si les utilisateurs essayaient de cliquer sur le bouton désactivé (ce qui arrivait très rarement), ils reviendraient intuitivement à la question en raison de l'indication fournie par l'état désactivé (décoloré).
- Garder le bouton toujours actif tout au long (option 1) a dérouté les utilisateurs car ils cliquaient sur le bouton sans répondre à la question connexe et le message d'erreur suivant a introduit une hésitation et les a ralentis.
Pour ces raisons, nous avons opté pour l'option 2 (boutons désactivés).
Quelques éléments à garder à l'esprit lors de la sélection de l'option 2 (bouton désactivé)
- Il est idéal pour les flux où les entrées ne sont que des sélections de vocabulaire fermées (boutons radio, cases à cocher, etc.) et non des entrées de texte. Parce qu'avec des entrées de texte, la machine ne saurait pas si le formulaire est vraiment complet afin d'activer le bouton "Continuer".
- Le bouton doit être visible lorsque les utilisateurs abordent la question afin que les utilisateurs puissent voir l'état du bouton changer.
- En outre, il est idéal pour les flux où chaque étape n'a qu'une seule question, pour rendre cohérente l'interaction du bouton "Continuer". (c'est-à-dire: vous obtenez la question suivante uniquement après avoir cliqué sur continuer).
J'espère que cela t'aides!
Je pense que la deuxième approche est la voie à suivre. L'utilisateur sait alors déjà où il peut continuer et qu'il y a d'autres étapes à venir.
la troisième approche peut également fonctionner, j'aurais besoin de voir des maquettes pour cela. Cela peut être vraiment élégant, mais le danger de confondre l'utilisateur est là. Je pense que le second est économique, fiable et convivial.
Où est l'option D? Affichez le bouton dans l'état activé et affichez également des instructions indiquant clairement que le formulaire doit être rempli avant de continuer. De cette façon, vous laissez quelque chose à découvrir. L'utilisateur aurait pu (et aurait dû) lire les instructions, mais s'il ne le fait pas, il peut toujours cliquer sur le bouton et obtenir des commentaires sur la suite des opérations.
Je conseille de ne pas crier d'alertes ou de messages d'erreur, mais de montrer ou de flasher poliment les instructions ou d'afficher des informations supplémentaires sur ce qui doit être fait. Pour les lecteurs d'écran, vous pouvez utiliser aria-live=“assertive” car il a la priorité de savoir ce qui se passe après le clic.