UX et HTML5 : aidons les utilisateurs à remplir votre formulaire mobile (Partie 1)

Les formulaires sont l'une des interactions primaires les plus élémentaires que les utilisateurs auront avec vos sites Web (et vos applications mobiles). Ils relient les gens entre eux et les laissent communiquer. Ils les laissent commenter les articles et expliquent à l'auteur qu'ils sont fortement en désaccord avec ce qu'ils ont écrit. Ils permettent aux gens de discuter directement sur une application de rencontres pour rencontrer « celui ». Que ce soit pour les forums, les commandes de produits, les communautés en ligne, la création de compte ou le paiement en ligne, les formulaires font partie intégrante de la vie en ligne des utilisateurs.

Nous sommes en 2018 et nous avons plus d'utilisateurs mobiles que d'utilisateurs d'ordinateurs de bureau dans le monde . Pourtant, nous traitons toujours ces utilisateurs comme des citoyens de seconde classe du Web. Tout le monde écrit et parle tout le temps de l'expérience utilisateur. Alors, pourquoi, pourquoi, pourquoi tant de sites Web et de produits se trompent-ils encore. Pourquoi leur expérience utilisateur mobile est-elle endommagée pour la moitié du monde ? Pourquoi est-ce toujours pénible, pourquoi est-il encore très difficile de réserver un vol et d'ouvrir un compte sous forme mobile aujourd'hui ? Les utilisateurs s'attendent à mieux !

Lectures recommandées : World Wide Web, Not Wealthy Western Web

Ceci est la première partie d'une série de deux articles. Dans celui-ci, je résumerai quelques bonnes pratiques essentielles pour améliorer vos formulaires mobiles, notamment la scannabilité et la lisibilité. Je vais vous guider à travers le placement, la taille et l'optimisation des étiquettes et des entrées. Nous verrons comment choisir le bon élément de formulaire pour réduire les coûts d'interaction. Enfin, vous apprendrez comment prévenir et traiter les erreurs sur les formulaires mobiles.

Dans la deuxième partie, j'examinerai de plus près les fonctionnalités mobiles spécifiques et les éléments de formulaire HTML5, et nous irons au-delà des éléments de formulaire classiques pour créer des applications Web et des sites Web uniques et agréables.

Remarque : Bien que la plupart des améliorations de code dans cet article soient liées au Web (parce que je ne connais pas Swift ou Java), les meilleures pratiques d'utilisation s'appliquent aux applications mobiles .

Conception de formulaire 101 : prioriser la scannabilité et la lisibilité

"Un formulaire est le nom, la valeur, les paires, dans une structure pour stocker des données sur un ordinateur, délivrées sous forme d'étiquettes et de champs de saisie à l'être humain." Ceci est une citation directe de Luke Wroblewski lors d'une conférence. Comme lui, je pense que la plupart des problèmes d'utilisabilité des formulaires proviennent de cette tendance à servir la structure de la base de données aux utilisateurs.

Architecture d'information solide

Pour créer de meilleurs formulaires, vous devez d'abord vous éloigner de la structure de votre base de données. Essayez de comprendre comment les utilisateurs souhaitent remplir les formulaires. C'est là que faire des tests d'utilisabilité et des recherches d'utilisateurs sur vos formulaires devient pratique. Les modèles mentaux des utilisateurs sont un concept UX qui peut vous y aider. Nielsen Norman Group le décrit comme "ce que l'utilisateur pense du système à portée de main". Demandez à votre testeur de réfléchir à haute voix et de vous dire comment il remplirait le formulaire. Quelles étapes attendent-ils ? Qu'est-ce qui vient en premier? Que ce passe t-il après? Cela vous donnera une meilleure idée de la façon de structurer votre formulaire de manière plus conviviale.

Regrouper visuellement des champs qui vont ensemble aidera également les utilisateurs à remplir un formulaire. Dans le code, utilisez la balise fieldset pour les regrouper par programmation. Cela aidera également les lecteurs d'écran à comprendre la hiérarchie.

Si le formulaire est long, n'exposez pas tout par défaut . Soyez intelligent sur ce que vous affichez. Utilisez la création de branches à bon escient pour afficher uniquement les champs dont les utilisateurs ont besoin. Dans un formulaire de paiement, par exemple, n'affichez pas tous les champs détaillés pour toutes les options d'expédition. Cela submergera l'utilisateur. Affichez suffisamment d'informations pour les aider à choisir la bonne option d'expédition. Ensuite, affichez uniquement les détails et les champs liés à ce choix.

La durée d'attention de l'utilisateur se raccourcit avec le temps : demandez des éléments facultatifs à la fin du formulaire. Par exemple, si votre formulaire est une enquête de satisfaction client, demandez des informations démographiques à la fin. Mieux encore, remplissez-les automatiquement, si possible. Demandez aux utilisateurs uniquement ce qui est nécessaire.

Enfin, planifiez à l'avance la localisation : que se passera-t-il lorsque votre formulaire sera traduit ? Que se passera-t-il, disons, pour l'allemand ? Votre conception fonctionnera-t-elle toujours?

Placement des étiquettes et optimisation des entrées

La mise en page à une seule colonne fonctionne mieux

En raison du manque d'espace, vous ne disposez pas d'options infinies pour placer des étiquettes et des champs sur les écrans mobiles :

• Présentez les champs dans une mise en page à une seule colonne . Il n'y a pas de place sur mobile pour plusieurs colonnes. Les formulaires multi-colonnes ne sont pas non plus une bonne idée sur le bureau.
• En mode portrait, il est préférable de placer l' étiquette au-dessus du champ afin que les utilisateurs puissent voir ce qu'il y a dans le champ lorsqu'ils tapent.

• En mode paysage, la hauteur de l'écran est réduite. Vous voudrez peut-être mettre les étiquettes à gauche et les entrées à droite . Mais testez-le pour vous assurer qu'il fonctionne.

Pour plus d'informations sur le placement des étiquettes, consultez l'article « Mobile Form Usability: Place Labels Above the Field » du Baymard Institute.

Les étiquettes doivent être claires et visibles et fonctionner sans contexte

N'oubliez pas que dès qu'un champ obtient le focus, le clavier s'ouvre et occupe au moins un tiers de la surface de l'écran. Sur les petits écrans mobiles, les utilisateurs devront également faire défiler pour remplir le formulaire. Cela signifie qu'ils perdront une partie du contexte en remplissant le formulaire. Planifiez en conséquence :

• Vos étiquettes doivent être un texte clair et visible qui peut être lu et compris sans contexte. L'utilisateur doit être en mesure de remplir chaque paire d'étiquettes et de champs en tant que tâche distincte, même s'ils perdent le contexte.

• Évitez le jargon, les abréviations et le langage spécifique à l'industrie chaque fois que vous le pouvez.
• Être cohérent. Si vous utilisez « client » dans une étiquette une fois, tenez-vous-en à ce mot. Évitez d'utiliser des « clients » plus tard, car cela pourrait semer la confusion chez les utilisateurs.
• La taille de la police doit être suffisamment grande. Testez votre formulaire sur de vrais appareils dès que possible et ajustez la taille en conséquence.
• Le texte tout en majuscules peut être difficile à lire pour certains utilisateurs. Vous voudrez peut-être éviter d'utiliser du texte tout en majuscules sur les étiquettes.
• La copie de l'étiquette doit être courte et scannable. Si un champ a besoin d'être clarifié, ne le mettez pas dans l'étiquette. Utilisez plutôt une description de champ.

Meilleure pratique de taille d'entrée

Si possible, la taille de l'élément d'entrée doit correspondre à la taille du contenu attendu . Cela aidera les utilisateurs à remplir rapidement le formulaire et à comprendre ce qui est attendu.

Utilisation de masques pour éviter de diviser les entrées sur mobile

Ne divisez pas les entrées juste pour le formatage . C'est particulièrement gênant sur mobile, où les utilisateurs ne peuvent pas utiliser le clavier pour naviguer entre les champs. Cela nécessite des tapotements supplémentaires juste pour passer au champ suivant pour remplir le formulaire. Vous pensez peut-être : « Mais je mettrai automatiquement le focus sur le champ suivant lorsque j'obtiendrai le nombre requis de caractères dans ce champ ». Cela pourrait fonctionner. Mais vous aurez pris le contrôle de l'UI, qui devient imprévisible pour l'utilisateur. De plus, ce serait pénible si vous les envoyiez automatiquement au champ suivant et qu'ils devaient corriger quelque chose dans le dernier champ. Enfin, il est plus compliqué de deviner ce qui est obligatoire avec les entrées fractionnées. Alors, arrêtons de jouer au jeu « Mais et si » et ne fractionnons tout simplement pas les entrées.

Je comprends : vous voulez toujours pouvoir formater les données de vos utilisateurs en petits morceaux pour les aider à remplir vos champs. Et vous avez parfaitement raison à ce sujet. Pour ce faire, vous pouvez utiliser des masques . Au lieu de diviser une entrée, placez simplement un masque dessus, pour aider visuellement l'utilisateur à le remplir. Voici un exemple vidéo de ce à quoi ressemblerait un masque pour aider les utilisateurs à remplir un champ de carte de crédit :

Les masques aident à prévenir les erreurs en guidant les utilisateurs vers le format correct. Évitez de les dévoiler progressivement — montrez directement le format. Évitez également de mettre de fausses valeurs dans le masque . Les utilisateurs pourraient penser qu'il est déjà rempli. C'est pourquoi j'ai remplacé les chiffres par un petit "X" dans ma démo. Trouvez ce qui fonctionne le mieux pour votre type d'entrée.

Enfin, n'oubliez pas que certaines données peuvent varier d'un pays à l'autre, et parfois le format change également (numéros de téléphone, par exemple). Planifiez en conséquence.

Descriptions de champs efficaces

L'affichage de descriptions de champs efficaces peut faire la différence entre une expérience de formulaire fluide et pénible.

À quoi peuvent servir les descriptions ?

Les descriptions peuvent aider les utilisateurs à bien des égards. Voici quelques exemples.

• Que demandez-vous exactement ?
  

  Pour une raison quelconque liée à la base de données, certaines sociétés d'expédition demandent les champs "Adresse 1" et "Adresse 2". C'est très déroutant pour les utilisateurs, mais vous n'aurez peut-être pas le choix ici. Ajoutez des champs de description pour aider les utilisateurs à comprendre ce qu'ils doivent mettre dans chaque champ.

  

  Il en va de même pour les acronymes et les abréviations. Je sais que j'ai dit que vous devriez les éviter, mais parfois vous ne pouvez pas. Si vous travaillez sur des formulaires complexes pour un secteur particulier, par exemple, ils peuvent avoir leur propre ensemble d'abréviations. Tout nouvel utilisateur qui doit remplir le formulaire ne connaît peut-être pas (encore) ces abréviations. Avoir une description disponible quelque part les aidera.

• Pourquoi as-tu besoin de cette information?
  Les utilisateurs peuvent être réticents à vous donner des informations personnelles s'ils ne comprennent pas pourquoi vous en avez besoin et ce que vous allez en faire . Mais parfois, vous devez toujours demander ces informations pour des raisons légales (comme la date de naissance pour un site Web qui vend de l'alcool). L'utilisation des descriptions de champs ici aidera les utilisateurs à comprendre pourquoi ce type d'informations est nécessaire.
  
  

  Sur les sites de commerce électronique, vous pouvez demander le numéro de téléphone de l'utilisateur au cas où le livreur aurait besoin de le contacter. C'est une raison légitime. Donc, encore une fois, utilisez des descriptions pour expliquer aux utilisateurs de commerce électronique pourquoi vous avez besoin de leur numéro de téléphone.

  

« Où puis-je trouver les informations ? »
Si vos utilisateurs ont besoin de trouver certaines informations ailleurs pour remplir un formulaire, indiquez-leur où les trouver. J'ai travaillé sur une application mobile qui permet aux utilisateurs de suivre leur maison. Les utilisateurs devaient coupler l'application à l'appareil de surveillance à l'aide d'un numéro de série. Il n'est pas très facile de trouver ce numéro de série sur l'appareil ; cela nécessite quelques instructions. On a rajouté un peu ? à côté du champ du numéro de série. Le bouton ouvre une fenêtre modale qui affiche une image et des indications pour aider l'utilisateur à comprendre où trouver le numéro de série sur l'appareil de surveillance. Les sites de commerce électronique font de même avec les codes promotionnels : ils donnent des indicateurs qui indiquent aux utilisateurs où trouver les codes.



• « Comment dois-je formater les informations ? »
  Certains champs nécessitent un format particulier . Dans ce cas, utilisez des descriptions pour informer les utilisateurs des règles de formatage à l'avance. Voici quelques exemples:
  • Numéro de téléphone : dois-je mettre l'indicatif international (+xx) devant le champ ?
  • Y a-t-il une longueur maximale ? Twitter sur mobile fait du bon travail avec celui-là.
  • Lorsqu'il s'agit de montants monétaires, le format est-il avec une virgule (comme 10 000) ou un espace (comme 10 000) ?
  • Quel format attendez-vous pour les dates ? Je vous laisse vérifier sur Wikipedia quel cauchemar c'est. La différence entre JJ MM AA et MM JJ AA peut causer * beaucoup * de problèmes aux utilisateurs lors de la réservation en ligne.
  Notez que beaucoup de ces problèmes de formatage peuvent être résolus par des masques de saisie. Nous y reviendrons plus tard dans l'article (ou vous pouvez intervenir directement si vous êtes impatient).

  

Comment afficher les descriptions

Dans les exemples ci-dessus, nous avons vu quelques façons d'afficher les descriptions de champs. Voici un résumé de ce qu'il faut faire :

• Les descriptions en ligne doivent être directement visibles et affichées à côté du champ.
• Si vous avez besoin de descriptions plus détaillées avec un contenu lourd, vous pouvez utiliser des info-bulles ou des modaux . Les info-bulles sont généralement déclenchées au survol sur le bureau et au toucher sur le mobile. Il en va de même pour les modaux : ouvrez-le lorsque l'utilisateur appuie sur l'icône d'aide ou sur le lien "voir plus", par exemple.

Soyez prudent avec les espaces réservés

Je comprends : il est tentant de supprimer des champs sur mobile pour gagner de l'espace et d'utiliser des espaces réservés à la place. Nous avons tous emprunté cette voie. Mais s'il vous plaît ne le faites pas. La spécification HML5 est claire à ce sujet : "L'attribut d'espace réservé représente une courte indication (un mot ou une courte phrase) destinée à aider l'utilisateur à saisir des données". Et voici pourquoi :

• L'espace réservé disparaît lorsque l'utilisateur commence à taper. L'utilisateur doit alors compter sur sa mémoire à court terme pour se souvenir de ce qu'il est censé mettre dans le champ . S'ils ne le peuvent pas, ils devront vider le champ pour voir l'indication.
• Il est difficile pour les utilisateurs de revérifier les champs avant de soumettre car les champs n'ont plus d'indications d'étiquette.
• Il est difficile de récupérer des erreurs une fois qu'un champ a été soumis car, encore une fois, il n'y a pas d'étiquette pour aider l'utilisateur.

Même si vous utilisez des espaces réservés avec des étiquettes, vous pouvez toujours rencontrer des problèmes. Il est difficile de faire la différence entre un champ rempli et un champ avec un espace réservé . Je suis un concepteur UX qui écrit sur la conception de formulaires mobiles et même j'ai été trompé la semaine dernière par l'un d'entre eux. Si cela m'arrive, cela arrivera à vos utilisateurs - faites-moi confiance. Enfin, la plupart des espaces réservés ont un texte gris clair, vous pouvez donc également rencontrer des problèmes de contraste.

Si vous souhaitez approfondir ce sujet, il existe un excellent article intitulé "L'attribut d'espace réservé n'est pas une étiquette", ainsi que Joshua Winn et FeedbackGuru expliquent en détail pourquoi c'est une mauvaise idée. Nielsen Norman Group a également écrit un article sur le sujet, intitulé "Les espaces réservés dans les champs de formulaire sont nuisibles".

Les espaces réservés ne sont pas obligatoires dans HTML5 . Du point de vue de la convivialité, vous n'avez certainement pas besoin d'un espace réservé dans chaque champ de votre formulaire. Mais avec l'adoption massive de Bootstrap et d'autres frameworks, il semble que beaucoup de gens se contentent de copier et coller des composants. Ces composants ont des espaces réservés, donc je suppose que les gens se sentent un peu obligés d'ajouter quelque chose à l'espace réservé dans le code ? Si les espaces réservés de votre formulaire ressemblent à "Veuillez remplir votre - étiquette - ici", vous vous trompez.

Les étiquettes à l'intérieur des champs pourraient néanmoins bien fonctionner pour les formulaires courts dans lesquels les champs sont prévisibles . Les formulaires de connexion sont un bon candidat pour cela. Mais s'il vous plaît, n'utilisez pas l'espace réservé HTML5 pour coder ceci. Utilisez une véritable étiquette dans le code et déplacez-la avec CSS et JavaScript.

Depuis le succès du design matériel d'Android, un motif a commencé à émerger : l'étiquette flottante. Cette étiquette est à l'intérieur du champ lorsque le champ n'est pas rempli, il prend donc un peu moins d'espace vertical sur mobile. Lorsque les utilisateurs commencent à interagir avec le champ, l'étiquette se déplace au-dessus du champ.

Cela semble être un moyen intéressant de gagner de l'espace, sans se heurter aux problèmes de "espaces réservés à la place des étiquettes" cités ci-dessus. Néanmoins, cela ne résout pas le problème des utilisateurs confondant éventuellement un espace réservé avec du contenu rempli.

Réduction des coûts d'interaction pour les formulaires réussis

La réduction du coût d'interaction (c'est-à-dire le nombre de clics, de balayages, etc.) des utilisateurs accomplissant leur tâche vous aidera à créer une expérience de formulaire transparente. Il existe différentes techniques pour y parvenir. Examinons quelques-uns d'entre eux en détail.

Une étude magique sur Internet m'a dit de réduire le nombre de champs

Plus de champs signifie moins de conversions, n'est-ce pas ? Vous avez peut-être rencontré l'étude "nous avons réduit notre formulaire d'abonnement de 11 à 4 champs, et cela a augmenté les conversions de 160 %". C'est un classique. Et si vous regardez leur formulaire de contact, cela a du sens. Pourquoi les utilisateurs voudraient-ils remplir 11 champs uniquement pour contacter l'entreprise ? Vous ne pouvez pas demander un tel engagement à des personnes qui vous connaissent à peine, n'est-ce pas ?

Commencez par ne demander que des informations utiles. Pourquoi avez-vous besoin du sexe d'une personne pour lui créer un compte ? Pourquoi avez-vous deux lignes pour l'adresse si votre formulaire d'abonnement est pour un service en ligne ?

Ne demandez que les informations dont vous avez besoin. Et puis demandez l'information dans son contexte. Si vous avez un site Web de commerce électronique, les utilisateurs pourraient être plus enclins à vous donner leur adresse dans la section d'expédition du processus de paiement que lors de leur inscription. Cela rendra votre formulaire d'inscription e-commerce tellement plus facile à remplir sur mobile !

De plus, ne vous fiez pas aveuglément à toutes les statistiques et études que vous trouvez sur Internet. Vous souvenez-vous de l'étude 11-fields-to-4 ? Eh bien, une autre étude plus récente a montré qu'en réduisant les champs de 9 à 6, les conversions ont chuté de 14 %. Choquant, n'est-ce pas ? Pourquoi? Eh bien, ils ont supprimé les champs les plus attrayants. Pour faire court, ils sont ensuite revenus à 9 domaines, ont mis le plus important en haut, et le tour est joué, les conversions ont augmenté de 19,21 %.

En fin de compte, bien que ces études soient intéressantes, ces sites Web ne sont pas votre site Web. Ne faites pas aveuglément confiance à la première étude que vous trouvez sur Internet.

Alors que peux-tu faire? Test. Test. Et testez !

• Effectuez des tests utilisateur pour voir le temps nécessaire à l'achèvement de votre formulaire mobile.
• Mesurer les abandons.
• Mesurer les problèmes avec certains champs.
• Mesurer la frustration associée à certains domaines. Dans quelle mesure les utilisateurs sont-ils disposés à fournir ces informations ? À quel point cette information est-elle personnelle ?

Optimiser les interactions tactiles

Rendre les commandes tactiles

Si vos champs sont trop petits ou difficiles à atteindre, les utilisateurs feront des erreurs et auront besoin d'interactions supplémentaires pour atteindre leurs objectifs. Vous souvenez-vous de la loi de Fitt ? Vous pouvez également l'appliquer à la conception mobile : rendez vos étiquettes, champs et contrôles de formulaire faciles à utiliser en augmentant la taille de la cible tactile . Pour les étiquettes sur le Web, un peu plus de rembourrage peut augmenter la zone tactile. Parfois, vous devrez également ajouter des marges entre les éléments pour éviter les tapotements manqués.

N'oubliez pas non plus de lier les étiquettes à leurs composants en associant les valeurs for et ID. De cette façon, si l'utilisateur manque un clic sur l'étiquette, le champ correspondant aura toujours le focus.

Steven Hoober a mené des recherches auprès des utilisateurs sur les zones tactiles. Vous trouverez un résumé dans "Designing for Touch". Sur la base de ce qu'il a découvert, il a construit un petit outil de règle en plastique : le modèle tactile mobile. L'outil pourrait vous aider à vous assurer que vos zones tactiles sont suffisamment grandes pour les formulaires mobiles et plus généralement pour la conception mobile.

Pour en savoir plus sur la conception pour le tactile, vous pouvez lire ce qui suit :

• "Conception conviviale pour les doigts : tailles cibles idéales pour les écrans tactiles mobiles"
• "La zone du pouce : concevoir pour les utilisateurs mobiles"

Fournir des commentaires

Les utilisateurs mobiles n'ont pas de souris (sans blague), ils n'obtiennent donc pas le retour de "clic" que les utilisateurs de bureau obtiennent lorsqu'ils appuient sur un bouton. Les utilisateurs de formulaires mobiles ont besoin de commentaires clairs lorsqu'ils interagissent avec des éléments :

• Fournissez un état de focus pour le champ de formulaire avec lequel l'utilisateur interagit.
• Fournir un retour visuel lorsque l'utilisateur interagit avec un bouton .

Je ne suis pas un grand fan de l'effet d'entraînement du design matériel sur les boutons. Mais je dois admettre que les animations sur Android fournissent un retour clair lorsque l'utilisateur interagit avec un bouton.

Honorer l'ordre des boutons suivant et précédent

Enfin, respectez les boutons suivant et précédent sur les claviers mobiles. Les utilisateurs peuvent les utiliser pour parcourir rapidement les champs. L'ordre tabindex doit correspondre à l'ordre visuel des champs et des composants.

Évitez les listes déroulantes sur mobile si possible

Les listes déroulantes (l'élément de sélection HTML) sur le Web nécessitent de nombreux onglets et interactions. Par conséquent, comme l'a dit Luke Wroblewski, ils devraient être l'assurance-chômage de dernier recours. De nombreux autres composants de l'interface utilisateur fonctionnent mieux que les listes déroulantes dans de nombreuses situations.

Les commandes de segment et les boutons radio sont de bonnes alternatives aux listes déroulantes si vous avez entre deux et quatre options. Pourquoi masquer les options sous une liste déroulante alors que vous pouvez toutes les afficher directement sur un seul écran ? Notez que, comme les boutons radio, les commandes de segment s'excluent mutuellement.

Une liste de pays est un bon candidat pour un composant. Une liste déroulante de plus d'une centaine de pays est un cauchemar d'interaction sur mobile. C'est OK si vous cherchez l'Afghanistan (au début de la liste) ou le Zimbabwe (à la fin de la liste). Si vous cherchez le Luxembourg, vous vous retrouverez dans un jeu de défilement pour arriver au milieu de la liste, aller trop loin sur la lettre M, essayer de revenir sur L, etc.

Les longues listes déroulantes peuvent être remplacées par des champs de saisie de texte prédictifs . Lorsque l'utilisateur commence à taper L, l'interface propose neuf pays. S'ils ajoutent un U - voila! — C'est le Luxembourg. Quatre interactions au lieu de deux, contre jusqu'à six ou sept interactions de défilement avec le menu déroulant.

Si vous avez besoin que les utilisateurs choisissent une date, oubliez de la diviser en une liste déroulante jour, mois et année comme les gens ont l'habitude de le faire sur des formulaires papier. Remplacez plusieurs listes déroulantes de dates par un sélecteur de dates . L'entrée HTML5 type=date fonctionne dans la plupart des cas. Mais vous pourriez avoir des besoins particuliers et finir par créer votre propre sélecteur de date en JavaScript, surtout si vous êtes dans le secteur de la réservation (hôtels, voitures, vols).

Dans son article "Mobile DropDowns Revisited", Klaus Schaefers explique comment l'utilisation d'un sélecteur de date pour les dates d'arrivée et de départ a rendu les interactions 60 % plus rapides.

Tenons-nous en aux réservations. Supposons que l'utilisateur ait besoin d'ajouter plusieurs voyageurs à son itinéraire. Vous pouvez **remplacer le menu déroulant* par un *stepper** pour sélectionner le nombre de passagers. Un stepper est une commande qui permet à l'utilisateur d'augmenter et de diminuer des valeurs simplement en appuyant sur les boutons + et - . Cela a tendance à être plus rapide lorsque moins de six personnes doivent être ajoutées. C'est aussi plus intuitif. Vous trouverez ci-dessous un exemple de stepper utilisé dans l'application Airbnb native d'Android pour sélectionner les invités, et sur le site Web optimisé pour les mobiles de Kayak pour ajouter des passagers.

Une dernière alternative aux listes déroulantes est la vue en liste. Les options seraient répertoriées dans une sous-vue spécifique, sous forme de boutons radio , par exemple. C'est principalement ainsi que fonctionnent les paramètres Android.

Devenir intelligent avec l'auto-complétion

Si vous souhaitez réduire le coût d'interaction de votre formulaire, soyez intelligent. Ne demandez pas d'informations que vous pouvez détecter automatiquement ou deviner en fonction d'autres informations que les utilisateurs vous ont fournies. Saisie semi-automatique et préremplissage autant que vous le pouvez.

Lieux et adresses

Si l'utilisateur recherche un lieu ou doit saisir une adresse, vous pouvez lui proposer la saisie semi-automatique pour l'aider. Au fur et à mesure qu'ils tapent, une API remplira le reste de l'adresse pour eux. Cela réduit également les erreurs.

Vous pouvez utiliser :

• API Google Adresses
• Algolia Places, basé sur OpenStreetMap

En France et dans de nombreux autres pays, vous pouvez deviner la ville en fonction de l'indicatif régional. Ainsi, si un utilisateur français entre un indicatif régional, vous pouvez automatiquement compléter automatiquement ou au moins proposer la ville. Mon pays, le Luxembourg, est petit (ne vous moquez pas de moi). Mon indicatif régional est lié à ma rue. Donc, si j'entre mon indicatif régional, le formulaire devrait même pouvoir suggérer ma rue.

Cartes de crédit

Un autre domaine où la détection automatique est facile est celui des cartes de crédit. Vous n'avez pas besoin de demander à l'utilisateur quel type de carte de crédit il possède. Vous pouvez le détecter automatiquement en fonction des nombres initiaux qu'ils entrent. Il y a même une bibliothèque qui peut faire le travail pour vous.

Utilisation de la saisie semi-automatique HTML5 (remplissage automatique)

L'attribut HTML autocomplete peut préremplir les champs en fonction des entrées précédentes de l'utilisateur. Cet attribut a un état activé et désactivé. Certaines personnes intelligentes ont commencé à travailler sur une spécification pour la rendre plus puissante et pour étendre l'attribut de saisie semi-automatique pour les champs de formulaire. Le WHATWG a également une liste intéressante.

Chrome et d'autres navigateurs mobiles prennent déjà en charge certaines des valeurs étendues pour les cartes de crédit et les noms. Cela signifie que les utilisateurs peuvent pré-remplir des formulaires avec leur nom et les données de leur carte de crédit qu'ils utilisent sur d'autres sites Web.

Bref, lorsque vous devez choisir entre différents systèmes, comptez le nombre d'interactions que chacun va nécessiter.

Des erreurs se produisent : gestion des erreurs dans les formulaires mobiles

La dernière étape de notre parcours vers de meilleurs formulaires mobiles consiste à gérer les erreurs et les fautes. On peut essayer de réduire les erreurs pour alléger la charge cognitive de l'utilisateur. Nous pouvons également les aider à se remettre d'erreurs, car quelle que soit la qualité de la conception de votre formulaire, des erreurs se produisent.

Éviter les erreurs lors du remplissage des formulaires

« Mieux vaut prévenir que guérir », disait ma mère. C'est également vrai pour la conception des formulaires : la prévention des erreurs améliorera l'expérience de votre formulaire mobile.

Limitation de format explicite

« Soyez conservateur dans ce que vous faites. Soyez libéral dans ce que vous acceptez des autres. Ce principe de robustesse peut également être appliqué aux champs de formulaire. Si possible, laissez l'utilisateur entrer des données dans n'importe quel format.

Si vous pensez devoir limiter ce qu'un utilisateur peut saisir dans le champ, commencez par vous demander « pourquoi ». Dans le domaine de l'expérience utilisateur, nous avons une technique appelée « les trois pourquoi ». Si la réponse est "parce que la base de données bla bla", il est peut-être temps de changer les choses. Par exemple, pourquoi refusez-vous les caractères spéciaux comme e, a et o dans le champ du nom d'utilisateur ? J'ai écrit un article expliquant à quel point les formulaires sont grossiers pour moi lorsque j'essaie d'entrer "Stéphanie" comme nom d'utilisateur. J'essaie toujours de trouver une bonne raison à cela (en dehors des raisons de la base de données).

Si vous avez une bonne raison d' exiger un format spécifique de la part des utilisateurs, indiquez-le dès le départ . Vous pouvez utiliser des espaces réservés HTML5 pour donner aux utilisateurs un indice sur ce à quoi les données devraient ressembler, mais encore une fois, soyez prudent avec ceux-ci. Vous pouvez également utiliser toutes les techniques de description de champ expliquées au début de cet article. Enfin, les masques de saisie peuvent guider les utilisateurs vers le bon format.

Marquage des champs obligatoires (et facultatifs)

N'attendez pas que les utilisateurs soumettent un formulaire à moitié rempli pour leur indiquer les champs obligatoires. Si un champ est obligatoire, les utilisateurs doivent le savoir . Le marquage des champs obligatoires avec un astérisque ( * ) et une légende est devenu un modèle standard pour les formulaires. La bonne partie est qu'il ne prend pas beaucoup de place. Le problème est qu'il n'a aucune valeur sémantique, il peut donc causer des problèmes d'accessibilité s'il est mal codé et si vous vous fiez aux habitudes des gens avec l'interaction des formulaires.

Vous pouvez à la place marquer explicitement les champs obligatoires et facultatifs avec les mots « requis » (ou « obligatoire ») et « facultatif ». L'Institut Baymard et Luke Wroblewski sont d'accord là-dessus. Cela évite l'ambiguïté avec les longs formulaires sur mobile, comme lors de l'utilisation d'un scroller, de la poursuite d'autre chose, puis du retour et de l'oubli si les champs obligatoires étaient marqués d'un astérisque ou autre chose.

Finalement, la décision sur la façon de marquer ces champs dépendra de la conception et de la longueur du champ et du contexte. La meilleure façon de savoir si vous avez pris la bonne décision est, encore une fois, de tester le formulaire.

Valeurs par défaut sensibles

Faites attention aux options sélectionnées par défaut dans les formulaires . Lorsque j'ai postulé pour mon emploi précédent, il y avait un formulaire d'information. L'état civil était facultatif. Ils ont fait du premier élément de la liste déroulante, "divorcé", le champ par défaut. Donc, je pouvais soit ne pas répondre (car c'était un champ facultatif) et laisser le système croire que j'étais divorcé, soit corriger cela et divulguer mon état civil réel même si je ne le voulais pas.

Faites également attention au sexe. Encore une fois, offrez une option aux personnes qui ne veulent pas le divulguer ; expliquez clairement pourquoi vous demandez son sexe ; mieux encore, demandez des pronoms ou ne demandez pas si vous n'en avez pas vraiment besoin. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• Lors de la connexion
  Dans un formulaire de connexion, une option de masque/démasquage du mot de passe améliorerait considérablement l'expérience utilisateur.
  Amazon a une histoire intéressante d'itération sur les mots de passe dans son formulaire de connexion. Il avait une version dans laquelle vous ne pouviez pas voir le mot de passe. La prochaine itération a permis aux utilisateurs de le révéler. Ensuite, le mot de passe était révélé par défaut et vous pouviez le masquer. Voici à quoi cela ressemblait en 2015 :

  

  Amazon a testé la dernière version et 60 % des personnes se sont méfiées. Ainsi, ils ont remplacé la case non cochée "masquer le mot de passe" par une case cochée "afficher le mot de passe". Cela afficherait le mot de passe en caractères plus petits, sous le champ, pendant que l'utilisateur tapait. Voici à quoi cela ressemble au moment de la rédaction de cet article :

  

  Comme vous pouvez le voir, il y a toujours place à l'amélioration.

Validation en ligne

Si vous connaissez les principes d'utilisabilité, vous connaissez peut-être la loi Gestalt de proximité. Sur mobile, évitez le résumé des erreurs en haut de la page, sans informations contextuelles, après que l'utilisateur a appuyé sur le bouton d'envoi.

Au lieu de cela, les messages d'erreur doivent être situés à proximité des erreurs elles-mêmes .

Validation en temps réel

Vous n'avez pas non plus besoin d'attendre que les utilisateurs cliquent sur le bouton Soumettre. Vous pouvez valider les champs et afficher les commentaires pendant que l'utilisateur les remplit .

Quelques conseils :

• Comme mentionné précédemment, les champs de mot de passe bénéficieraient d'une validation en temps réel et d'un retour sur chaque frappe.
• Vous pouvez également souhaiter valider les noms d'utilisateur en temps réel lors de la création des comptes, pour vous assurer qu'ils sont disponibles. Twitter fait du bon travail à cet égard.
• Ne validez pas chaque frappe. Attendez que l'utilisateur ait fini de taper. (Utilisez le blur JavaScript pour les formulaires Web ou attendez quelques secondes pour détecter l'inactivité.)

Note : *Mihael Konjevic a écrit un bel article sur « Inline Validation in Forms : Designing the Experience ». Il explique le concept de « récompenser tôt, punir tard ».*

"Si l'utilisateur saisit les données dans le champ qui était dans un état valide , effectuez la validation après la saisie des données."

"Si l'utilisateur saisit les données dans le champ qui était dans un état invalide , effectuez la validation lors de la saisie des données."

La couleur compte

Je ne dis pas que la couleur compte juste à cause de ma couleur de cheveux actuelle roux, rose et violet. La couleur compte vraiment dans la conception des formulaires.

Il existe certaines conventions sur le Web que vous ne voulez pas enfreindre. Les utilisateurs non daltoniens savent que le rouge correspond aux erreurs, le jaune aux avertissements et le vert presque toujours à la confirmation ou au succès. Il est préférable de s'en tenir à ces trois couleurs. Cependant, le rouge peut rendre les gens anxieux. L'utilisateur pourrait penser qu'il a fait une très grave erreur. L'utilisation d'orange ou de jaune pour les messages d'erreur pourrait causer moins de panique. Le problème avec le jaune et l'orange est qu'il est difficile de trouver des teintes adaptées aux daltoniens.

En parlant de daltonisme : la couleur ne devrait pas être le seul moyen de transmettre un message d'erreur . C'est un critère d'accessibilité.

Dans l'exemple ci-dessous à gauche, le champ avec une erreur est en orange, et le champ qui a été corrigé est devenu vert. J'ai utilisé un outil de test daltonien pour prendre la capture d'écran au milieu : vous ne pouvez plus distinguer la bordure grise par défaut de la bordure verte. L'ajout de quelques icônes dans la dernière capture d'écran garantit que les messages d'erreur sont transmis aux personnes daltoniennes.

Récupération après des erreurs : rédaction de messages d'erreur conviviaux

À ce stade, nous avons fait tout notre possible pour aider les utilisateurs à remplir nos formulaires et éviter les erreurs. Mais parfois, malgré tous nos efforts, des erreurs se produisent. Il est temps de comprendre comment aider les utilisateurs à se remettre de ces erreurs.

Tout d'abord, rappelez-vous : ne détournez pas le contrôle du système. Si un problème n'est pas critique, l'utilisateur doit pouvoir continuer à interagir avec autant que possible le reste de l'interface. Évitez les messages d'erreur d'alerte JavaScript et les modaux qui bloquent les utilisateurs dans la mesure du possible. De plus, si votre formulaire nécessite une autorisation, demandez-la dans le flux d'utilisation. Si l'autorisation n'est pas accordée, ne considérez pas cela comme une erreur, car ce n'est pas le cas. Faites attention à la copie que vous utilisez ici.

Vous n'êtes pas un robot, et vos utilisateurs non plus

Les robots sont cool, je sais. Mais vous n'êtes pas un robot, et vos utilisateurs non plus. Pourtant, tant de messages d'erreur sont encore si mal écrits. Voici quelques conseils concernant les messages d'erreur conviviaux :

• Ne jamais afficher un message d'erreur brut, comme "Une erreur de type 2393 s'est produite. Le serveur n'a pas pu terminer l'opération. Au lieu de cela, expliquez ce qui s'est passé en langage humain et pourquoi cela s'est produit .
• N'affichez jamais un message d'erreur sans issue, comme "Une erreur s'est produite". Suggérez plutôt des moyens de récupérer de l'erreur . Rédigez une copie exploitable.
• N'affichez jamais un message d'erreur vague, comme "Un serveur avec le nom d'hôte spécifié est introuvable", avec un bouton "Réessayer". Au lieu de cela, rendez les messages d'erreur informatifs et cohérents . S'il vous plaît, ne parlez pas comme un robot.
• Ne présumez pas que les gens connaissent le contexte d'un message. Vos utilisateurs ne sont pas des geeks férus de technologie. Expliquez-leur plutôt dans un langage simple, sans jargon technique, comment récupérer de cette erreur .

Méfiez-vous de la langue que vous utilisez dans les messages

Quoi que vous écriviez, évitez de rendre les gens stupides à propos d'une erreur. Si possible, omettez les mots négatifs ; ils ont tendance à effrayer les gens et à les rendre encore plus anxieux. Utilisez plutôt un ton courtois, positif et affirmatif.

Ne blâmez pas les utilisateurs pour les erreurs ; blâmez plutôt le système. Le système ne gardera pas rancune, je le promets. Attirez l'attention de l'utilisateur sur la façon dont le système n'a pas pu traiter l'action et expliquez-lui comment trouver une solution .

Une petite astuce consiste à lire votre propre message à haute voix. Cela vous aidera à entendre si cela fonctionne ou est trop dur ou trop décontracté, etc.

Vous pouvez également faire preuve de créativité avec les messages d'erreur et incorporer des images et de l'humour pour les rendre moins menaçants. Cela dépendra vraiment de l'identité et du ton de votre marque.

Pour vous aider à rédiger un meilleur message d'erreur, je vous suggère de lire ce qui suit :

• "Une liste de contrôle de microcopie en 6 points pour les équipes de produits sans rédacteurs UX"
• "L'art du message d'erreur : écrire une copie claire et utile lorsque les choses tournent mal"

Il est temps de soumettre le formulaire

L'utilisateur a rempli le formulaire, il n'y a plus d'erreurs et tout semble bon. Enfin, il est temps de soumettre le formulaire !

La première règle est de ne pas masquer le bouton d'envoi . Sérieusement! Je me demande quel esprit tordu a eu cette idée, mais je l'ai vue sous certaines formes. Le bouton d'envoi ne s'afficherait qu'une fois que tous les champs obligatoires auraient été remplis sans aucune erreur. Il est dérangeant pour l'utilisateur de se demander si quelque chose ne va pas ou si le bouton du formulaire n'a pas été chargé ou si le site Web est cassé, etc.

Si vous ne voulez pas que les utilisateurs puissent appuyer sur le bouton d'envoi s'il manque des champs obligatoires ou s'il y a des erreurs de validation, utilisez l'attribut HTML disabled sur l'entrée d' submit . Vous devrez réactiver le bouton en utilisant JavaScript une fois que le formulaire sera valide et prêt à être soumis.

Si vous avez une incitation à l'action principale et secondaire, utilisez la couleur, la taille et le style pour afficher la hiérarchie .

Si vous vous demandez si le bouton de confirmation doit venir avant ou après le bouton d'annulation, moi aussi (et beaucoup d'autres personnes). Si vous créez une application native, respectez les directives du système d'exploitation. C'est devenu particulièrement amusant depuis qu'Android a changé la position des boutons dans sa quatrième version. Sur le web, c'est plus compliqué car il n'y a pas vraiment de consignes. Quel que soit le système d'exploitation, voici quelques directives générales pour les boutons d'envoi optimisés pour les mobiles :

• Donnez à l' appel à l'action des verbes descriptifs et actionnables.
• Fournir un retour visuel lorsque l'utilisateur appuie dessus.
• Si vous avez deux boutons, faites ressortir l'action principale .
• À moins que vous ne travailliez sur un formulaire d'entreprise de back-office très spécifique (auquel cas vous aurez beaucoup de difficultés à optimiser pour le mobile), évitez un bouton de réinitialisation . Les utilisateurs pourraient le confondre avec le bouton d'envoi et perdraient toutes leurs données par accident.

Conclusion

Dans cette première partie, j'ai abordé de nombreuses petites techniques pour faire passer votre formulaire au niveau supérieur et aider les utilisateurs à le remplir. Certaines de ces directives générales et bonnes pratiques mobiles peuvent ne pas fonctionner 100 % du temps - c'est le hic avec les meilleures pratiques. Alors, testez toujours vos formulaires sur de vrais utilisateurs et de vrais appareils, et adaptez les directives aux besoins et à l'expérience spécifiques de vos utilisateurs.

Effectuez également des tests de régression et des tests fonctionnels automatisés, encore une fois, sur de vrais appareils. L'émulateur mobile de Chrome ne suffira pas à tester les formulaires optimisés pour le toucher. Je dis cela car j'avais lancé un site e-commerce avec un formulaire de recherche qui ne fonctionnait pas sur mobile. Nous n'avons fait que des tests automatisés à l'aide d'un émulateur. Voici ce qui s'est passé. Le formulaire de recherche était caché sous une icône de recherche. Vous pouvez appuyer sur le bouton, ce qui ouvre une boîte avec le champ de recherche. Cela a fonctionné en émulant un survol de souris comme un événement tactile. Nous avons testé en appuyant sur le bouton, et cela a ouvert la boîte. Personne n'a essayé de lancer une recherche. Ainsi, personne (pas même le client) n'a vu que le champ de recherche disparaissait dès que les utilisateurs essayaient d'interagir avec. Qu'est-il arrivé? Lorsque l'élément d'entrée a obtenu le focus, le bouton a perdu l'état de survol, il a donc fermé la boîte avec le champ. Les tests automatisés n'ont pas pu détecter cela car l'entrée ne perdait pas de vue. Nous avons donc lancé un site e-commerce sans fonctionnalité de recherche sur mobile. Pas une super expérience.

Dans la deuxième partie de cette série, nous verrons des techniques plus avancées spécifiques au mobile. Nous verrons comment utiliser les fonctionnalités HTML5 intéressantes pour formater les champs et comment utiliser les fonctionnalités mobiles pour faire passer l'expérience utilisateur mobile au niveau supérieur.