Site icon Blog ARC Optimizer

Sélecteur d'anniversaire


Dans cette nouvelle série d'articles sur l'UX, nous examinons de plus près certains modèles de conception frustrants et explorons de meilleures alternatives, ainsi que de nombreux exemples à garder à l'esprit lors de la construction ou de la conception d'un. Ne manquez pas les suivants: abonnez-vous à notre newsletter pour recevoir des mises à jour .

Vous les avez déjà vues. Des modèles de conception déroutants et frustrants qui semblent vous poursuivre partout où vous allez, d'un site Web à un autre. Il s’agit peut-être d’un bouton de soumission désactivé qui ne communique jamais ce qui ne va pas, ou d’infobulles qui, une fois ouvertes, ne couvrent le champ de saisie que lorsque vous devez corriger une erreur. Ils sont partout, et ils sont ennuyeux nous jetant souvent d'une impasse à l'autre, dans quelque chose qui semble être une souricière bien orchestrée et mal conçue.

Il existe aujourd'hui de nombreux modèles de conception frustrants sur le Web. Dans la nouvelle série d'articles, nous les aborderons un par un. ( Grand aperçu )

Ces modèles ne sont ni malveillants ni malveillants. Ils n’ont pas grand-chose en commun avec les invites de cookies trompeuses ou les mystérieux CAPTCHA déguisés en bornes d’incendie et en passages pour piétons. Ils ne sont pas non plus conçus avec de mauvaises intentions ou un mal à l'esprit: personne ne se réveille le matin dans l'espoir d'augmenter les taux de rebond ou de réduire la conversion.

C'est juste qu'au fil des ans, certaines décisions de conception plus ou moins aléatoires sont devenues largement acceptés et adoptés, et par conséquent, ils sont répétés encore et encore – souvent sans être remis en question ou validés par des données ou des tests d'utilisabilité. Ils sont devenus des modèles de conception établis . Et souvent assez pauvres . Apparaissant encore et encore et encore parmi les plaintes des utilisateurs pendant les tests.

Dans cette nouvelle série d'articles, examinons de plus près certains de ces modèles de conception frustrants et explorons de meilleures alternatives ainsi que de nombreux exemples et questions à garder à l'esprit lors de la construction ou de la conception d'un. Ces informations proviennent de recherches sur les utilisateurs et de tests d'utilisabilité menés par vous-même et des collègues de la communauté, et bien sûr, elles seront toutes référencées dans chacun des prochains articles.

Nous commencerons par un modèle humble et apparemment inoffensif. que nous avions tous connu à un moment donné – le tristement célèbre sélecteur d'anniversaire qui se trouve trop souvent inaccessible, lent et encombrant à utiliser.

Frustrating UX: Birthday Dropdown / Widgets À partir de 2021

Tous Lorsque vous postulez pour un emploi, ouvrez un compte bancaire ou réservez un vol, vous devrez probablement saisir votre date de naissance . De toute évidence, l'entrée est une date et il ne devrait donc pas être très surprenant de voir des interfaces utilisant un widget de type calendrier de sélection de date bien adopté (natif ou personnalisé), ou un menu déroulant pour demander cette entrée spécifique.

Nous pouvons probablement repérer les raisons pour lesquelles ces options sont souvent préférées. Du point de vue technique, nous voulons nous assurer que l'entrée est correcte et détecter les erreurs tôt . Notre validation doit être suffisamment résistante pour valider l'entrée, fournir un message d'erreur clair et expliquer exactement ce que le client doit faire pour y remédier. Nous n'avons tout simplement pas tous ces problèmes avec une liste déroulante ou un widget de calendrier. De plus, nous pouvons facilement éviter toute différence de locale ou de formatage en fournissant uniquement les options qui conviendraient à la facture.

Une vue de calendrier avec une entrée très stricte et explicite requise. Accessible uniquement pour les utilisateurs de souris. La saisie au clavier est désactivée. Il m'a fallu 52 secondes (!) Pour donner mon anniversaire.

Il peut sembler que le meilleur moyen d'éviter que des erreurs ne se produisent soit de concevoir une interface utilisateur de manière à ce que les erreurs soient difficiles à faire. Cela pourrait signifier être strict et explicite dans la conception du formulaire – ne permettant fondamentalement que pour une entrée bien formée. Après tout, fournir une entrée mal formée est impossible si tous les choix disponibles sont bien formés. Mais si l'entrée sera bien formée, elle n'a pas besoin d'être précise, surtout si fournir cette entrée est fatigante et frustrante.

En pratique, nous commettons en fait des erreurs similaires avec sur- des exigences de mot de passe complexes et rigoureuses également. Il n'est pas rare de voir des gens tellement ennuyés par ces exigences qu'ils mettent des mots de passe sur une note autocollante sur leur écran, ou les cachent dans un fichier personal.txt sur leur bureau, juste pour pouvoir saisissez-les si nécessaire. Les mots de passe Wi-Fi d'entreprise et un SuperPIN complexe pour les services bancaires en ligne en sont de bons exemples.

Il s'avère que les gens sont très créatifs pour contourner les règles en leur faveur, donc quand un système n'est pas utilisable, il n'est pas sécurisé ; et lorsqu'une entrée de formulaire n'est pas utilisable, les données que nous recevons seront moins précises et entraîneront davantage d'erreurs. En fin de compte, cela conduirait bien sûr à des situations où les utilisateurs seraient verrouillés et seraient forcés d'abandonner l'interface utilisateur car ils ne peuvent faire aucun progrès.

Il y a aussi un revers à cette médaille. Nous pourrions bien sûr éliminer toute complexité et toujours fournir un champ de saisie unique, permettant aux utilisateurs de taper ce qu'ils préfèrent. Dans la pratique, cela signifie qu'ils taperont ce qu'ils préfèrent, souvent de manière mal structurée et inefficace.

Dans le cas d'une entrée d'anniversaire, dans les tests d'utilisabilité, les clients saisissent n'importe quoi de ] Juillet à Juillet à 06 à 6 souvent avec des délimiteurs aléatoires et quelques fautes de frappe en cours de route, et avec un ordre de jours mixte, des mois et des années. La validation de cette entrée après l'envoi ne sert pas bien les utilisateurs, car ils ne savent pas quel formatage d'entrée fonctionnerait. De toute évidence, cela ne répond pas non plus à nos besoins.

Avec notre conception, nous devons fournir des conseils simples et respectueux ainsi qu'une implémentation technique accessible. Cela nous amène à certains inconvénients courants des sélecteurs de dates et des listes déroulantes indigènes.

Les pièges des sélecteurs de dates indigènes et des listes déroulantes

Malheureusement, les sélecteurs de dates indigènes incités par viennent avec beaucoup de cauchemars d'accessibilité . Au moment de la rédaction de cet article, lorsqu'ils sont utilisés prêts à l'emploi, ils ne sont pas un choix très accessible pour à peu près tout type de saisie de date. Non seulement il y a beaucoup de problèmes de lecteur d'écran, mais aussi des problèmes de mise au point et de mise en page, des messages d'erreur déroutants et génériques.

J'ai vu un bon nombre d'implémentations désactivant complètement la saisie au clavier (voir ci-dessus), obligeant les clients à utiliser la date native widget calendrier de picker exclusivement . Et c'est douloureusement, douloureusement lent. Sans retour au clavier, les utilisateurs doivent se lancer dans un long voyage entre des jours, des mois et des années, prenant des dizaines et des dizaines de tapotements ou de clics .

Bien que nous connaissions la date immédiatement, le L'interface nous invite à naviguer entre les dates, puis trouver notre date dans l'aperçu mensuel une fois que nous y sommes. C'est la raison pour laquelle ces expériences sont frustrantes.

Vue d'agenda native de Chrome. Cela ne peut être affiché que pour les utilisateurs de souris. Les dates non valides sont différenciées ne peuvent pas être sélectionnées. ( Source de l'image )

Dans cette optique, les menus déroulants sont beaucoup plus rapides et plus faciles à parcourir. Ils sont accessibles par défaut, et plutôt que de naviguer entre les mois et les années, il suffit de localiser les bons numéros dans 3 listes – jours, mois et années. Mais les listes déroulantes sont encore lentes . Ils ont des problèmes de zoom . Pincer les options de défilement est fatigant. Ils prennent beaucoup de place. La liste des années est longue. Et lors de la spécification de l'entrée, nous devons appuyer sur le contrôle, puis faire défiler (généralement plus d'une fois), rechercher et sélectionner la cible, puis passer à la liste déroulante suivante. Ce n’est pas non plus exaltant .

Les rouleaux de calendrier iOS sont affichés après avoir tapé sur la commande de date. ( Source de l'image )

Il n'est donc pas rare de voir des listes déroulantes considérées comme l'interface utilisateur de dernier recours et généralement remplacées par des boutons (par exemple pour les filtres), des bascules, des commandes segmentées ou des boîtes de saisie semi-automatique qui combinent la flexibilité d'une zone de texte avec l'assurance d'une -box. Les listes déroulantes ne sont pas mauvaises en soi; ce sont juste les utilisateurs qui passent beaucoup plus de temps que nécessaire à remplir les données qu'ils contiennent.

Et puis il y a une question sur les valeurs par défaut . Alors qu'avec les listes déroulantes, nous n'avons souvent aucune entrée ( mm / jj / aaaa ), avec un sélecteur de date, nous devons fournir un point de départ pour la vue du calendrier. Dans ce dernier cas, ironiquement, la date de «début» se trouve généralement juste autour de la date à laquelle le formulaire est rempli, par ex. 15 mai 2021 . Cela ne semble pas optimal bien sûr, mais quelle devrait être la bonne date ? Nous devons commencer quelque part, n'est-ce pas?

Eh bien, il n'y a vraiment pas de bonne date cependant. Nous pourrions commencer tôt ou tard, il y a 3 mois ou demain, mais dans le cas d'un sélecteur d'anniversaire, toutes ces options sont de pure conjecture. Et en tant que tels, ils sont quelque peu frustrants: sans aucune entrée, les clients peuvent avoir besoin de faire défiler tout le chemin de 1901 à la fin des années 1980, et avec certains ensembles d'entrées ils devront le corriger, souvent en sautant des décennies d'avant en arrière. Cette interaction exigera une précision irréprochable dans le défilement.

Quel que soit le choix que nous faisons, nous aurons tort presque tout le temps . Cela sera probablement différent pour un site Web de réservation d'hôtel, ou un service de livraison de nourriture, et de nombreux autres cas d'utilisation – mais pas pour une entrée d'anniversaire. Ceci nous amène à la conversation sur la façon d'évaluer objectivement la bonne conception d'une entrée de formulaire.

Évaluation de la qualité de la conception de formulaire

La conception peut être considérée comme une question très subjective. Après tout, chacun semble avoir sa propre opinion et ses préférences sur la bonne approche pour un problème donné. Mais contrairement à tout type d'expression de soi ou d'art, le design est censé résoudre un problème. La question est donc de savoir dans quelle mesure une conception particulière résout un problème particulier. Plus le rendu de l’intention du concepteur est sans ambiguïté, moins les clients commettent d’erreurs, moins ils sont interrompus, meilleure est la conception. Ces attributs sont mesurables et objectifs .

D'après ma propre expérience, les formulaires sont l'aspect le plus difficile de l'expérience utilisateur. Il y a donc de nombreuses facettes difficiles allant de la microcopie et de la mise en page du formulaire à la validation en ligne et aux messages d'erreur. Obtenir des formulaires correctement nécessite souvent de faire remonter correctement les erreurs de back-end et les erreurs tierces au front-end et de simplifier une structure sous-jacente complexe en un ensemble de champs de formulaire prévisibles et raisonnables. Cela peut facilement devenir un cauchemar frustrant dans les applications héritées complexes et les intégrations tierces.

Comment pouvons-nous mesurer objectivement si un design est bon ou mauvais, comme un sélecteur de date dans cet exemple? Nous n'aimons peut-être pas les listes déroulantes, mais ce n'est pas une raison pour ne pas les utiliser. ( Grand aperçu )

Ainsi, quand il s'agit de conception de formulaire dans nos projets, nous essayons toujours de mesurer la qualité d'une solution particulière en fonction des 9 attributs suivants:

  • Modèle mental
    Dans quelle mesure notre conception de formulaire s'intègre-t-elle dans le modèle mental du client? Lorsque nous demandons des informations personnelles, nous devons demander exactement le minimum de ce qui nous est nécessaire pour aider nos clients à démarrer. Nous ne devrions pas demander de détails sensibles ou personnels (sexe, anniversaire, numéro de téléphone) sauf si nous avons une bonne raison pour cela, et l'expliquer dans l'interface utilisateur.
  • Complexity
    Combien d'éléments d'entrée affichons-nous par page, sur mobile et sur ordinateur? Si un formulaire contient 70 à 80 champs de saisie, plutôt que de les afficher tous sur une seule page ou d’utiliser une mise en page à plusieurs colonnes, il peut être judicieux d’utiliser un modèle de liste de tâches pour décomposer la complexité en des morceaux plus petits et gérables.
  • Vitesse de saisie
    De combien de temps et d'efforts le client a-t-il besoin pour remplir correctement les données? Pour une entrée donnée, combien de tapotements / frappes / opérations sont nécessaires pour remplir le formulaire avec des données données avec précision, en supposant qu'aucune erreur n'est commise en cours de route.
  • Accessibilité
    Quand on parle de la vitesse de saisie, nous Nous devons nous assurer que nous prenons en charge divers modes d'interaction, principalement les utilisateurs de lecteurs d'écran et les utilisateurs de claviers. Cela signifie des étiquettes correctement définies, de gros boutons, des étiquettes placées au-dessus du champ de saisie et des erreurs correctement communiquées, parmi bien d'autres choses .
  • Évolutivité
    Si jamais nous devions traduire l'interface utilisateur dans une autre langue ou l'adapter à un autre facteur de forme, dans quelle mesure serait-il simple et combien de problèmes cela causera-t-il? (Un exemple typique de solution problématique est un modèle d'étiquette flottante, et nous en parlerons dans un autre article.)
  • Gravité des interruptions
    À quelle fréquence interrompons-nous les clients, que ce soit avec des fileurs de chargement, tôt ou une validation en ligne tardive, le gel de certaines parties de l'interface utilisateur pour ajuster l'interface en fonction de l'interface utilisateur fournie (par exemple, une fois qu'un pays est sélectionné), la fréquence des données mal préremplies ou des données incorrectement corrigées automatiquement?
  • Taux de réussite du formulaire [19659040] Combien de clients remplissent avec succès un formulaire sans une seule erreur? Si un formulaire est bien conçu, la grande majorité des clients ne devraient jamais voir aucune erreur. Par exemple, cela nécessite que nous puissions accéder au remplissage automatique du navigateur, l'ordre de tabulation est logique et les modifications sont classiques et évidentes.
  • Vitesse de récupération
    Quelle est la proportion de clients qui réussissent à découvrir l'erreur, le réparer et passer à l'étape suivante du formulaire? Nous devons suivre la fréquence d'apparition des messages d'erreur et les messages d'erreur les plus courants. C’est aussi la raison pour laquelle il est souvent judicieux d’abandonner le service client et de vérifier avec lui ce dont les clients se plaignent souvent.
  • Taux d’échec du formulaire
    Combien de clients abandonnent le formulaire? Cela se produit généralement non seulement en raison de la complexité du formulaire, mais également parce que les clients ne peuvent pas trouver un moyen de corriger une erreur en raison de validateurs agressifs ou de boutons "Soumettre" désactivés. Cela arrive aussi parce que le formulaire demande trop d'informations sensibles et personnelles sans raison valable.

Pour comprendre le fonctionnement d'un formulaire, nous exécutons des études d'utilisabilité avec les clients accédant à l'interface sur leur propre machine – que ce soit un appareil mobile, une tablette, un ordinateur portable ou un ordinateur de bureau – sur leur propre système d'exploitation, dans leur propre navigateur. Nous demandons d'enregistrer l'écran, si possible, et d'utiliser un protocole de réflexion à voix haute pour suivre où et comment et pourquoi les erreurs se produisent. Nous étudions également la vitesse à laquelle le client passe d'un champ de formulaire à un autre, lorsqu'il fait une pause et réfléchit, et quand la plupart des erreurs se produisent.

De toute évidence, le nombre de tapotements ou de clics n'est pas toujours suggèrent que l'entrée a été simple ou lourde. Mais certains modes d'entrée peuvent être plus susceptibles de générer des erreurs ou de créer de la confusion, et d'autres peuvent être des valeurs aberrantes nécessitant juste beaucoup plus de temps par rapport aux autres options. C'est ce que nous recherchons dans les tests.

Voyons maintenant comment nous pouvons l'appliquer au problème d'entrée d'anniversaire.

Concevoir une meilleure entrée d'anniversaire

Si quelqu'un vous demande votre anniversaire, vous aurez probablement une chaîne particulière de chiffres à l'esprit. Il peut être commandé en jj / mm / aaaa ou mm / jj / aaaa mais ce sera une chaîne de 8 chiffres que vous répétez dans toutes sortes de documents depuis

Nous pouvons puiser dans ce modèle simple de ce qu'est une entrée d'anniversaire avec un champ simple à entrée unique qui combinerait les trois entrées – jour, mois et année. Cela signifierait que l'utilisateur taperait simplement une chaîne de 8 chiffres, en restant constamment sur le clavier.

L'utilisation d'une seule entrée pour une date est ambiguë et difficile à valider. L'utilisation de plusieurs entrées pour la date n'est pas ambiguë et beaucoup plus facile à valider. Conçu par Adam Silver . ( Grand aperçu )

Cependant, cette approche soulève quelques problèmes:

  • nous devons prendre en charge le formatage automatique et le masquage,
  • nous devons expliquer la position du jour / mois ,
  • nous devons prendre en charge le comportement du bouton Retour arrière à travers l'entrée,
  • nous devons suivre et masquer / afficher / afficher en permanence le masquage,
  • nous devons prendre en charge les sauts dans une valeur spécifique (par exemple, le mois),
  • nous devons minimiser les clics de rage et la navigation dans l'entrée pour modifier une valeur spécifique sur les appareils mobiles,
  • Si la création automatique n'est pas utilisée, nous devons trouver un ensemble de règles de nettoyage et de validation pour prendre en charge tout type de délimiteurs.

Dans son livre sur Form Design Patterns Adam Silver soutient que utilise plusieurs entrées à la place. d'une entrée est rarement une bonne idée, mais c'est une bonne option pour les dates . Nous pouvons clairement communiquer ce que chaque entrée représente et nous pouvons mettre en évidence l'entrée spécifique avec des styles de focus. De plus, la validation est beaucoup plus facile, et nous pouvons communiquer facilement quelle partie spécifique de l'entrée semble être invalide, et comment la corriger.

Nous pourrions soit transférer automatiquement l'utilisateur d'une entrée vers le next lorsque la saisie est terminée, ou autoriser les utilisateurs à se déplacer seuls entre les champs. À première vue, le premier semble meilleur car l'entrée ne nécessiterait que 8 chiffres, tapés les uns après les autres. Cependant, lorsque les gens corrigent des erreurs, ils ont souvent besoin de tampons d'entrée – espace dans le champ d'entrée pour corriger l'entrée existante.

Par exemple, il est courant de voir des personnes tapant 01, se rendant compte qu'ils ont fait une erreur, puis en changeant l'entrée en 010, et en supprimant le premier 0, juste pour finir avec une chaîne inversée (et correcte) – 10 . En évitant une transition automatique d'un champ à l'autre, nous pourrions causer moins de problèmes et rendre l'interface utilisateur un peu plus prévisible et facile à gérer.

Pour expliquer l'entrée, nous aurions besoin de fournir étiquettes pour le jour, le mois et l'année, et peut-être aussi montrer un exemple de l'entrée correcte. Les libellés ne doivent pas être des libellés flottants mais peuvent vivre confortablement au-dessus du champ de saisie, avec tous les indices ou exemples que nous souhaitons afficher. De plus, chaque entrée peut également être mise en évidence sur la mise au point.

Modèle de conception, comme suggéré par Adam Silver de l'équipe Gov.uk. ( Aller à la démo )

Au fil des ans, je n'ai pas pu déceler un seul problème avec cette solution pendant des années de tests, et il n'est pas surprenant que le modèle utilisé sur Gov.uk aussi.

Quand vous avez besoin d'un sélecteur de date après tout

Bien que la solution ci-dessus soit probablement plus que suffisante pour une entrée d'anniversaire, elle peut ne pas être suffisante pour des situations plus générales. Nous pourrions avoir besoin d'une entrée de date moins littérale qu'un jour de naissance, où les clients devront choisir un jour plutôt que le fournir (par exemple " premier samedi de juillet" ). Dans ce cas, nous pourrions améliorer les trois champs de saisie avec un widget de calendrier que les utilisateurs pourraient également utiliser. Une entrée par défaut dépend de la date actuelle ou d'une date future que la plupart des clients ont tendance à choisir.

<img loading = "lazy" decoding = "async" importance = "low" width = "800" height = " 897 "srcset =" https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_400/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/0daea1f0 -f4b4-48f1-a540-4f91da6225b3 / 10-birthday-picker.png 400w,
https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_800/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/0daea1f0-f4b4-48f1- a540-4f91da6225b3 / 10-birthday-picker.png 800w,
https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_1200/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/0daea1f0-f4b4-48f1- a540-4f91da6225b3 / 10-birthday-picker.png 1200w,
https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_1600/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/0daea1f0-f4b4-48f1- a540-4f91da6225b3 / 10-birthday-picker.png 1600w,
https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_2000/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/0daea1f0-f4b4-48f1- a540-4f91da6225b3 / 10-birthday-picker.png 2000w "src =" https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_400/https://cloud.netlifyusercontent.com/assets/ 344dbf88-fdf9-42bb-adb4-46f01eedd629 / 0daea1f0-f4b4-48f1-a540-4f91da6225b3 / 10-birthday-picker.png "tailles =" 100vw "alt =" Adam fournit un simple exemple de code
pour le Modèle de date mémorable dans son
Quitter la version mobile