Validation sans confirmation explicite
Je travaille actuellement sur une application. Cette application comporte certaines fonctionnalités que l'utilisateur peut déverrouiller en entrant un code numérique. J'avais envisagé de mettre une validation automatique dès que l'utilisateur tape le dernier numéro du code.
Je vois de plus en plus ce modèle, mais je me demandais si la validation sans entrée explicite de l'utilisateur, par exemple en cliquant sur un bouton Continuer, a des problèmes liés à la convivialité/utilisateur.
Le problème principal pour moi n'est pas de savoir si la validation peut être effectuée automatiquement, mais que l'utilisateur a un contrôle explicite sur l'action de l'interface. Les utilisateurs doivent avoir un contrôle explicite sur les interactions que l'application leur offre. S'ils n'ont pas de contrôle explicite, ils peuvent se trouver incertain de ce que l'application a fait et ce qui l'a déclenché. Parfois, ils peuvent ne pas savoir exactement quand quelque chose s'est passé parce qu'ils ont peut-être détourné le regard de l'écran.
Vous n'avez pas partagé l'interface, mais l'action dans l'interface est quelque chose comme continuer ou déverrouiller. La validation du code est un processus interne que votre application doit faire avant de donner l'accès à l'utilisateur, mais ce n'est pas quelque chose que l'utilisateur s'attend à être en contrôle. Je pense donc que la question UX réelle ici est de savoir si la fonctionnalité doit être déverrouillée sans le contrôle de l'utilisateur.
Cependant, le contrôle ne nécessite pas de confirmation explicite. Certaines interfaces permettent à l'utilisateur de contrôler sans leur donner une action de confirmation. Par exemple, la saisie de code d'accès sur iOS ne donne pas à l'utilisateur un bouton de confirmation, mais l'indication de progression de la longueur fixe et en temps réel permet à l'utilisateur de rester en contrôle. Dans ce cas, l'absence du bouton de confirmation permet à l'utilisateur de savoir que la saisie du code PASSCODE est tout ce dont ils ont besoin pour satisfaire l'action de déverrouillage.
Étant donné qu'une validation automatique est possible, je suppose que vous utilisez un code de longueur fixe. Dans ce cas, l'interface IOS CodeCode est celle que vous pouvez imiter.
Le problème est que l'utilisateur peut entrer dans le mauvais numéro et obtenir une erreur de validation avant d'avoir eu le temps de le réparer.
Voici tout un tas de raisons pour lesquelles la validation des types d'utilisateurs est problématique: https://adamsilver.io/articles/live-validation-is-problematic/
Bien que je suis d'accord avec les commentaires d'Adam Silver en principe, il existe des moyens d'optimiser les validations en direct pour certaines situations (!).
Par exemple, lors du déverrouillage de votre téléphone avec un code d'accès numérique, il est probable que le périphérique validera le code dès que vous avez entré le chiffre final.
Pour une validation de formulaire plus traditionnelle, affichant une liste de contrôle avec les exigences du champ, qui est mise à jour en temps réel, fournit une approche très conviviale:
(S'il vous plaît, assurez-vous que les différences entre les apparences cochées et non vérifiées sont plus faciles à voir que ce que Apple est ici! soupir )
Dans votre cas particulier, votre question implique que la longueur du code est toujours identique. Vous avez donc un déclencheur bien défini pour la validation.
Un design que j'avais joué avec, affiche une icône grise - pense, "Neutre" - à côté du champ de saisie, peut-être juste un cercle gris. Une fois que l'utilisateur est entré dans l'ensemble du code, remplacez-le par une coche verte ou un "X" rouge dans un cercle (similaire aux icônes d'Apple ci-dessus) pour indiquer si le code est valide ou non.
Pour aider l'utilisateur à éviter les erreurs, donnez-lui un aidant en incluant le texte de l'indice:
Your code will look like this: 123-456-789
Aussi, assurez-vous de valider de manière humaine. E.G., si votre code contient des lettres, mais uniquement les majuscules, ne punissez pas vos utilisateurs si elles entrent des caractères minuscules, à la place.
P.s.: Aussi souvent,;) Nielsen Norman Group a un article détaillé sur le sujet avec de nombreux conseils: Comment signaler des erreurs sous forme: 10 lignes directrices de conception .
Si vous pouvez le faire FAST et en toute sécurité, alors il est agréable d'avoir les commentaires que vous tapez plutôt que de cliquer sur le bouton. (Remarque: votre application devrait probablement aussi valider à nouveau sur le bouton clic sur toute façon.)
Qu'est-ce que rapide signifie:
Cela signifie que cela arrive presque instantanément. La logique pour cela ne devrait pas s'appuyer sur un processus de consommation de temps, tel que l'interrogation d'un service Web, etc. L'utilisateur a besoin de la rétroaction immédiate, s'il en faut une seconde ou plus - attendez que le bouton clique dessus pour le gérer.
Qu'est-ce que -sécurisé signifie:
Eh bien, l'utilisateur peut-il abuser de la fonctionnalité en essayant rapidement beaucoup de codes différents? Peut-être même automatisé? Ce n'est pas vraiment une préoccupation UX, mais certainement une contrepartie de votre conception de candidature.
Bottom Line: Il est bon de donner des commentaires instantanés, tant que vous ne ralentitrez pas le processus.
Informations Complémentaires:
Parfois, la décision est une technique, plutôt que sur l'UX.
Prenez un champ de saisie de carte de crédit par exemple. Souvent, l'utilisateur obtiendra l'impression que le numéro de carte est validé une fois qu'ils tapaient le dernier chiffre. Ceci n'est que partiellement vrai. Ce qui se passe ici, c'est que la carte est validée au format seul (c'est-à-dire un certain sous-ensemble de chiffres de départ valides, et vous pouvez également exécuter un checksum sur le numéro). L'avantage ici est que vous ne gaspillez pas le traitement des serveurs sur un numéro de carte qui n'a aucune chance d'être valide.
Une fois que vous avez soumis le formulaire, les données réelles sont traitées côté serveur et valident complètement.