Aidez les utilisateurs à remplir votre formulaire mobile (partie 1)

Testez-vous vos formulaires sur de vrais utilisateurs et sur de vrais appareils? Sinon, vous devriez. Jetons un coup d'œil à certaines des techniques qui peuvent vous aider à passer vos formulaires au niveau supérieur et à aider les utilisateurs à les remplir.

Les formulaires constituent l'une des interactions primaires les plus élémentaires que les utilisateurs auront avec vos sites Web (et applications mobiles). Ils relient les gens et les laissent communiquer. Ils les ont laissés commenter des articles et expliquer à l'auteur comment ils sont en désaccord avec ce qu'ils ont écrit. Ils permettent aux gens de discuter directement sur une application de rencontre pour rencontrer "l'un". 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 représentent une grande partie de la vie en ligne des utilisateurs.

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

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

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

Dans la deuxième partie, je vais examiner de plus près les fonctionnalités mobiles spécifiques et les éléments de formulaire HTML5. et sites Web et applications Web agréables.

Note : Bien que l'amélioration du code dans cet article soit liée au Web (car je ne connais pas Swift ou Java), les meilleures pratiques d'utilisation tenir pour les applications mobiles .

Conception de formulaire 101: priorité à la numérisation et à la lisibilité

"Une fiche est le nom, la valeur, les paires d'une structure pour stocker des données sur un ordinateur comme étiquettes et champs de saisie pour l'être humain. "Ceci est une citation directe de Luke Wroblewski lors d'une conférence. Comme lui, je crois 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.

Strong Information Architecture

Pour créer de meilleurs formulaires, vous devez d'abord faire quelques pas structure. Essayez de comprendre comment les utilisateurs veulent remplir des formulaires. C'est là que les tests d'utilisabilité et la recherche d'utilisateurs sur vos formulaires deviennent pratiques. Les modèles mentaux utilisateur sont un concept UX qui peut vous aider. Nielsen Norman Group le décrit comme "ce que l’utilisateur croit du système en question". Demandez à votre testeur de penser à haute voix et de vous dire comment ils rempliraient 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 manière de structurer votre formulaire de manière plus conviviale.

Le regroupement visuel des champs associés 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 la forme est longue, n'expose pas tout par défaut . Soyez intelligent sur ce que vous affichez. Utilisez les branchements avec sagesse pour afficher uniquement les champs dont les utilisateurs ont besoin. Dans un formulaire de commande, par exemple, n'affichez pas tous les champs détaillés pour toutes les options d'expédition. Cela va submerger l'utilisateur. Afficher suffisamment d'informations pour les aider à choisir la bonne option d'expédition. Ensuite, n'affichez que les détails et les champs liés à ce choix.

Le temps d'attention des utilisateurs est réduit: Demandez des informations facultatives à la fin de du formulaire. Par exemple, si votre formulaire est une enquête de satisfaction de la clientèle, demandez des informations démographiques à la fin. Mieux encore, remplissez-les automatiquement si possible. Demandez aux utilisateurs uniquement ce qui est nécessaire.

Enfin, prévoyez 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?

Optimisation du placement et de l'étiquetage des étiquettes

Fonctionnement optimal de la mise en page à une colonne

En raison du manque d'espace, vous ne disposez pas d'options 19659028] Champs présents dans une mise en page à une colonne . Il n'y a pas de place sur le mobile pour plusieurs colonnes. Les formulaires multi-colonnes ne sont pas non plus une excellente idée sur le bureau

• En mode paysage, la hauteur de l'écran est réduite. Vous voudrez peut-être apposer 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, voir " Mobile Form Facilité d'utilisation: étiquettes de position au-dessus du champ ".

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

Au fur et à mesure qu'un champ se concentre, 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 tout en remplissant le formulaire. Planifiez en conséquence:

• Vos étiquettes doivent être claires, le texte visible peut être lu et compris sans contexte. L'utilisateur doit pouvoir compléter chaque étiquette et chaque paire de champs en tant que tâche distincte, même en cas de perte de contexte.

• Évitez le jargon, les abréviations et les termes spécifiques à chaque secteur.
• Soyez cohérent. Si vous utilisez "client" dans une étiquette une fois, restez avec ce mot. Évitez d'utiliser des "clients" plus tard, car cela pourrait induire les utilisateurs en erreur.
• La taille de la police doit être suffisamment grande. Testez votre formulaire sur des périphériques réels dès que possible et ajustez la taille en conséquence.
• Le texte en majuscules peut être difficile à lire pour certains utilisateurs. Vous voudrez peut-être éviter d'utiliser du texte en majuscules sur les étiquettes.
• La copie de l'étiquette doit être courte et scannable. Si un champ doit être clarifié, ne le mettez pas sur l'étiquette. Utilisez plutôt une description de champ.

Meilleures pratiques pour la taille des entrées

Si possible, la taille de 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.

Grand aperçu )

Utilisation de masques pour éviter le fractionnement d'entrées sur mobile

Ne divisez pas les entrées uniquement pour le formatage . C'est particulièrement agaçant sur mobile, où les utilisateurs ne peuvent pas utiliser le clavier pour naviguer entre les champs. Il faut simplement appuyer sur le bouton pour accéder au champ suivant afin de remplir le formulaire. Vous pensez peut-être, "mais je mettrai automatiquement l'accent sur le champ suivant lorsque j'obtiens le nombre de caractères requis dans ce champ". Cela pourrait fonctionner. Mais vous aurez pris le contrôle de l'interface utilisateur, qui devient imprévisible pour l'utilisateur. En outre, ce serait difficile si vous les envoyiez automatiquement au champ suivant et que vous deviez 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 si si" et ne divisions pas les entrées .

Je comprends: vous voulez toujours pouvoir formater les données de votre utilisateur en petits morceaux pour les aider à remplir vos champs. Et vous avez parfaitement raison à ce sujet. Pour ce faire, vous pourriez 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 un masque ressemblerait pour aider les utilisateurs à remplir un champ de carte de crédit:

Les masques aident à empêcher les erreurs en guidant les utilisateurs au format correct. Évitez de les révéler progressivement – montrez le format directement. Aussi, évite de mettre de fausses valeurs dans le masque . Les utilisateurs peuvent penser que c'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 de saisie.

Enfin, rappelez-vous que certaines données peuvent varier d'un pays à l'autre et que parfois le format change également (numéros de téléphone, par exemple). Planifier 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 transparente et une expérience douloureuse.

À quoi peuvent servir les descriptions?

. Voici quelques exemples.

• Qu'est-ce que vous demandez exactement?

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

  
  Grand aperçu )
  

  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 peut ne pas être familier (encore) avec ces abréviations. Une description sera disponible quelque part pour les aider.

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

  Sur les sites Web de commerce électronique, vous pouvez demander le numéro de téléphone de l'utilisateur au cas où le livreur doit 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ù trouver l'information?"
Si vos utilisateurs doivent trouver certaines informations ailleurs pour remplir un formulaire, dites-leur où les trouver. J'ai travaillé sur une application mobile qui permet à l'utilisateur de suivre sa maison. Les utilisateurs devaient coupler l'application au périphérique de surveillance en utilisant 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 demande des instructions. Nous avons ajouté un petit bouton ? à côté du champ du numéro de série. Le bouton ouvre un modal qui affiche une image et des indications pour aider l'utilisateur à comprendre où trouver le numéro de série sur le périphérique de surveillance.
Les sites de commerce électronique font la même chose avec les codes promotionnels: ils donnent des indicateurs indiquant aux utilisateurs où trouver les codes.




• "Comment dois-je mettre en forme l'information?"
  Certains champs nécessitent un format particulier . Dans ce cas, utilisez les descriptions pour permettre aux utilisateurs de connaître les règles de formatage au début. 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 un bon travail avec celui-ci.
  • En ce qui concerne les montants monétaires, le format comporte-t-il une virgule (comme 10 000) ou un espace (10 000)? 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 problèmes de formatage peuvent être résolus par des masques de saisie. Nous y reviendrons plus tard dans l'article (ou vous pouvez sauter directement si vous êtes impatient).

  
  

Comment afficher les descriptions

Dans les exemples ci-dessus, nous avons vu quelques manières d'afficher des 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 infobulles ou modaux . Les infobulles sont généralement déclenchées par survol sur le bureau et sur le mobile. Il en va de même pour les modaux: ouvrez-le par exemple lorsque l'utilisateur appuie sur l'icône d'aide ou sur le lien "Voir plus".

Attention aux espaces réservés

Je comprends: il est tentant de supprimer des champs et utilisez des espaces réservés à la place. Nous avons tous parcouru cette route. 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 un court indice (un mot ou une phrase courte) destiné à 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 se fier à la mémoire à court terme pour se souvenir de ce qu'il est censé mettre sur le terrain . S'ils ne peuvent pas, ils devront vider le champ pour voir l'indication.
• Il est difficile pour les utilisateurs de vérifier les champs avant de les soumettre car les champs n'ont plus d'indications d'étiquette. [19659029] difficile de récupérer des erreurs une fois qu'un champ a été soumis car, là encore, 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 avoir 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 designer UX qui écrit sur la conception de formulaires mobiles et même la semaine dernière, j'ai été trompé par l'un d'entre eux. Si cela m'arrive, cela arrivera à vos utilisateurs – croyez-moi en cela. Enfin, la plupart des espaces réservés ont un texte en gris clair, vous pouvez donc avoir des problèmes de contraste.

Si vous voulez approfondir ce sujet, il existe un excellent article intitulé " L'attribut d'espace réservé n'est pas une étiquette mais aussi Joshua Winn et FeedbackGuru aller dans le détail sur 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 facilité d'utilisation, 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 ne font que copier et coller des composants. Ces composants ont des espaces réservés, alors je suppose que les gens se sentent obligés d'ajouter quelque chose à l'espace réservé dans le code? Si les balises de votre formulaire ressemblent à «Veuillez remplir votre étiquette – ici», vous le faites mal.

Les étiquettes situées à l'intérieur des champs pourraient néanmoins convenir aux formes courtes dans lesquelles les champs sont prévisibles . Les formulaires de connexion sont un bon candidat pour cela. Mais veuillez ne pas utiliser la balise HTML5 pour coder ceci. Utilisez une véritable étiquette dans le code et déplacez-la avec CSS et JavaScript.

Grand aperçu )

Depuis le succès de la conception matérielle d'Android, un modèle a commencé à apparaître: l'étiquette flottante . Cette étiquette se trouve à l'intérieur du champ lorsque le champ n'est pas renseigné. Il faut donc un peu moins d'espace vertical sur le 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 la place, sans rencontrer les problèmes de "caractères génériques" mentionnés ci-dessus. Néanmoins, cela ne résout pas le problème des utilisateurs qui confondent peut-être un espace réservé avec un contenu rempli.

Réduction du coût d'interaction pour les formulaires réussis

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

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

Plus de champs signifient moins de conversions, n'est-ce pas? Vous avez peut-être rencontré le "nous avons réduit notre formulaire d'abonnement de 11 à 4 champs, et cela a entraîné une augmentation des 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 simplement pour contacter la société? Vous ne pouvez pas demander un si grand engagement de personnes qui vous connaissent à peine, non?

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

Demandez uniquement les informations dont vous avez besoin. Et ensuite demander les informations en 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 qu'à l'enregistrement. Cela facilitera grandement la saisie de votre formulaire de commerce électronique sur mobile!

De plus, ne faites pas confiance à toutes les statistiques et études que vous trouvez sur Internet. Rappelez-vous l'étude 11-to-4? Une autre étude plus récente a montré que la réduction des champs de 9 à 6, les conversions ont chuté de 14% . Choquant, n'est-ce pas? Pourquoi? Eh bien, ils ont enlevé les champs les plus attrayants. Bref, ils sont retournés dans 9 champs, ont placé le plus important sur le dessus et voilà, les conversions ont augmenté de 19,21%.

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

Alors, que pouvez-vous faire? Tester. Tester. Et testez!

• Effectuez des tests utilisateur pour voir l'heure de finalisation de votre formulaire mobile.
• Mesurez les pertes.
• Mesurez les problèmes avec certains champs.
• Mesurez la frustration associée à certains champs. Dans quelle mesure les utilisateurs sont-ils prêts à donner cette information? Comment ces informations sont-elles personnelles?

Optimisation des interactions tactiles

Rendre les contrôles conviviaux

Si vos champs sont trop petits ou difficiles à atteindre, les utilisateurs commettent des erreurs et ont besoin d'interactions supplémentaires pour atteindre leurs objectifs. Rappelez-vous la loi de Fitt ? Vous pouvez également l'appliquer au design mobile: Rendez vos étiquettes, champs et commandes 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 surface tactile. Parfois, vous devrez également ajouter des marges entre les éléments pour éviter les taps manqués.

N'oubliez pas non plus de lier les étiquettes avec leurs composants en appariant pour et les valeurs d'ID.

Steven Hoober a mené des recherches sur les utilisateurs sur des zones tactiles. Vous trouverez un résumé dans " Designing for Touch ". Basé sur 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 formes mobiles et plus généralement pour la conception mobile.

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

Fournir des commentaires

Les utilisateurs mobiles ne disposent pas de souris (sans blague), ils n'obtiennent donc pas le retour "clic" les utilisateurs obtiennent en appuyant sur un bouton. Les utilisateurs de formulaires mobiles ont besoin d'une rétroaction claire lorsqu'ils interagissent avec des éléments:

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

Je ne suis pas très fan de l'effet d'entraînement des boutons sur la conception du matériau. Mais je dois admettre que les animations sur Android fournissent des informations claires lorsque l'utilisateur interagit avec un bouton.

Honorez le bouton Suivant et Précédent

. Les utilisateurs peuvent les utiliser pour naviguer rapidement dans 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 Luke Wroblewski l’a dit, ils devraient être l’UI de dernier recours . De nombreux autres composants de l'interface utilisateur fonctionnent mieux que les menus déroulants 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 lorsque vous pouvez les afficher toutes directement sur un seul écran? Notez que, comme les boutons radio, les contrôles de segment s'excluent mutuellement.

Une liste de pays est un bon candidat pour un composant. Une liste déroulante de plus de cent pays est un cauchemar d’interaction sur mobile. Ce n'est pas grave si vous recherchez l'Afghanistan (au début de la liste) ou le Zimbabwe (la fin de la liste). Si vous êtes à la recherche de Luxembourg, vous vous retrouverez dans une partie de défilement pour atteindre le milieu de la liste, allant trop loin vers la lettre M, en essayant de revenir à L, etc.

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

Si vous souhaitez que les utilisateurs choisissent une date, oubliez de la diviser en un menu déroulant jour, mois et année comme les utilisateurs ont l'habitude de le faire sur des formulaires papier. Remplacer plusieurs listes déroulantes par un sélecteur de date . 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 permis des interactions 60% plus rapides.

Restons fidèles à l'activité de réservation. 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 un contrôle qui permet à l'utilisateur d'augmenter et de diminuer les 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 moteur pas à pas utilisé dans l'application Airbnb native d'Android pour sélectionner des invités et sur le site Web optimisé pour mobile de Kayak pour ajouter des passagers.

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

Mise au point automatique avec achèvement automatique

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 ou deviner automatiquement en fonction d'autres informations que les utilisateurs vous ont données. Autocomplétion et remplissage autant que possible.

Lieux et adresses

Si l'utilisateur recherche un lieu ou doit saisir une adresse, vous pouvez proposer une saisie automatique pour les aider. Au fur et à mesure de leur frappe, une API remplit le reste de l'adresse pour eux. Cela réduit également les erreurs.

Vous pouvez utiliser:

En France et dans de nombreux autres pays , vous pouvez deviner la ville en fonction de l'indicatif régional. So, if a French user enters an area code, you could automatically auto-complete or at least propose the city. My country, Luxembourg, is small (don’t make fun of me). My area code is linked to my street. So, if I enter my area code, the form should even be able to suggest my street.

Credit Cards

Another area where auto-detection is easy is credit cards. You don’t need to ask the user what type of credit card they have. You can auto-detect this based on the initial numbers they enter. There’s even a library that can do the job for you.

Using HTML5 Autocompletion (Autofill)

The HTML autocomplete attribute can prefill fields based on the user’s earlier inputs. This attribute has an on and off state. Some smart people have started working on a specification to make this more powerful and to extend the autocomplete attribute for form fields. The WHATWG also has an interesting list.

Chrome and other mobile browsers already support some of the extended values for credit cards and names. This means that users can prefill forms with their name and credit card data that they use on other websites.

In short, when you must choose between different systems, count the number of interactions each is going to require.

Mistakes Happen: Handling Errors In Mobile Forms

The last step on our journey towards better mobile forms is handling errors and mistakes. We can try to reduce mistakes to ease the user’s cognitive load. We can also help them recover from errors, because no matter how great your form design is, mistakes happen.

Avoiding Errors While Filling The Forms

“Prevention is better than a cure,” my mother used to say. That’s also true of form design: Preventing errors will improve your mobile form’s experience.

Explicit Format Limitation

“Be conservative in what you do. Be liberal in what you accept from others.” This robustness principle can be applied to form fields as well. If possible, let the user enter data in any format.

If you think you need to limit what a user can enter in the field, start by asking yourself “why”. In the user experience field, we have a technique called “the three whys”. If the answer is “because blah blah database”, maybe it’s time to change things. For instance, why do you refuse special characters like é, à and ö in the user name field? I wrote an article explaining how rude forms are to me when I try to enter “Stéphanie” as a user name. I’m still trying to figure out a good reason for that (apart from database reasons).

If you have a good reason to require a specific format from users, state this up front. You can use HTML5 placeholders to give users a hint about what the data should look like, but again, be careful with those. You could also use all of the field description techniques explained at the beginning of this article. Finally, input masks can guide users towards the right format.

Marking Mandatory Fields (And Optional Ones)

Don’t wait for users to submit a half-completed form to tell them about required fields. If a field is mandatory, users should know about it. Marking mandatory fields with an asterix (*) and a legend has become a standard pattern for forms. The good part is that it does not take much space. The problem is that it has no semantic value, so it can cause accessibility issues if poorly coded and if you rely on people’s habits with form interaction.

You could instead explicitly mark both mandatory and optional fields with the words “required” (or “mandatory”) and “optional”. Both Baymard Institute and Luke Wroblewski agree on that. This avoids ambiguity with long forms on mobile, such as when using a scroller, proceeding with something else, then coming back and not remembering if mandatory fields were marked with an asterisk or something else.

Eventually, the decision on how to mark those fields will depend on the design and length of the field and on the context. The best way to know whether you’ve made the right decision is, again, to test the form.

Sensible Defaults

Be careful about default selected options in forms. When I applied for my previous job, there was an information form. The marital status was optional. They made the first element in the dropdown, “divorced”, the default field. So, I could either not answer (because it was an optional field) and let the system believe that I was divorced, or correct this and disclose my actual marital status even if I did not want to.

Also, be careful about gender. Again, have an option for people who don’t want to disclose it; make clear why you’re asking for their gender; better yet, ask for pronouns, or don’t ask if you don’t really need to. 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.

• When Logging In
  In a login form, a mask/unmask password option would tremendously improve the user experience.
  

  
  A button to show and hide the password in a form.

  Amazon has an interesting history of iterating on passwords in its login form. It used to have a version in which you could not see the password. The next iteration allowed users to reveal it. Then, the password was revealed by default, and you could hide it. This is what is looked like in 2015:

  
  

  Amazon tested the last version, and 60% people got suspicious. So, they replaced the “hide password” unchecked checkbox with a “show password” checked box. This would show the password in smaller characters, under the field, while the user typed. This is what it looks like at the time of writing this article:

  
  

  As you can see, there’s always room for improvement.

Inline Validation

If you are familiar with usability principles, you might know the Gestalt law of proximity. On mobile, avoid the summary of errors at the top of the page, with no contextual information, after the user has tapped the submit button.

Instead, error messages should be located close to the errors themselves.

Real-Time Validation

You also don’t need to wait until users hit the submit button. You can validate fields and display feedback while the user is filling them in.

A few tips:

• As mentioned earlier, password fields would benefit from real-time validation and feedback on each keystroke.
• You might also want to validate user names in real time when accounts are being created, to make sure they’re available. Twitter does a good job of that.
• Don’t validate every keystroke. Wait until the user has finished typing. (Use JavaScript blur for web forms, or just wait a few seconds to detect inactivity.)

Note: *Mihael Konjević has written a nice article on “Inline Validation in Forms: Designing the Experience.” He explains the concept of “reward early, punish late.”*

“If the user is entering the data in the field that was in a valid state, perform the validation after the data entry.”

“If the user is entering the data in the field that was in an invalid state, perform the validation during the data entry.”

Color Matters

I’m not saying that color matters just because of my current ginger, pink and purple hair color. Color really matters in form design.

There are some conventions on the web that you don’t want to break. Non-colorblind users know that red is for errors, yellow is for warnings, and green is almost always for confirmation or success. It’s best to stick with these three colors. Red can make people anxiousthough. The user might think they’ve made a really serious mistake. Using orange or yellow for error messages could cause less panic. The problem with yellow and orange is that it’s hard to find colorblind-friendly hues of them.

Speaking of colorblindness: Color should not be the only way to convey an error message. This is an accessibility criterion.

In the example below on the left, the field with an error is in orange, and the field that has been corrected has turned green. I used a colorblind testing tool to take the screenshot in the middle: You can’t distinguish between the default gray border and the green one anymore. Adding some icons in the last screenshot ensures that the error messages are conveyed to colorblind people.

Recovering From Errors: Writing User-Friendly Error Messages

At this point, we’ve done everything we can to help users fill our forms and avoid errors. But sometimes, despite our best effort, mistakes happen. It’s time to figure out how to help users recover from those mistakes.

First, remember: Don’t hijack control of the system. If a problem isn’t critical, the user should be able to continue interacting with as much of the rest of the interface as possible. Avoid those JavaScript alert error message and modals that blocks users whenever possible. Also, if your form needs some permission, request it in the flow of use. If permission is not granted, do not consider this an error because it is not. Be careful about the copy you use here.

You’re Not A Robot, And Neither Are Your Users

Robots are cool, I know. But you’re not a robot, and neither are your users. Yet so many error messages are still so poorly written. Here are a few tips when it comes to human-friendly error messages:

• Never show a raw error message, like “An error of type 2393 has occurred. Server could not complete the operation.” Instead, explain what happened in human language and why it happened.
• Never show a dead-end error message, like “An error has occurred.” Instead suggest ways to recover from the error. Write actionable copy.
• Never show a vague error message, like “A server with the specified hostname could not be found”, with a “Try again” button. Instead, make error messages informative and consistent. Please don’t sound like a robot.
• Don’t assume that people know the context of a message. Your users are not tech-savvy geeks. Instead, explain to them in plain language, without technical jargon, how to recover from this error.

Beware The Language You Use In Messages

Whatever you write, avoid making people feel stupid about a mistake. If possible, leave out negative words; they tend to scare people and make them even more anxious. Use a courteous, positive, affirming tone instead.

Don’t blame users for mistakes; blame the system instead. The system won’t hold a grudge, I promise. Shift the user’s attention to how the system could not process the action, and explain to them how to find a solution.

A little trick is to read your own message out loud. It will help you hear whether it works or is too harsh or too casual, etc.

You could also get creative with error messages and incorporate imagery and humour to make them less threatening. This will really depend on your brand’s identity and tone, though.

To help you write better error message, I suggest you read the following:

Time To Submit The Form

The user has filled in the form, there are no more errors, and everything looks good. Finally, it’s time to submit the form!

The first rule is, don’t mask the submit button. Seriously! I wonder what twisted mind came up with this idea, but I’ve seen it in some forms. The submit button would be displayed only once all required fields were filled in without any errors. It’s disturbing for the user to wonder whether something is wrong or the form’s button has not loaded or the website is broken and so on.

If you don’t want users to be able to hit the submit button if there’s missing mandatory fields or there are validation errors, use the disabled HTML attribute on the submit input. You will need to re-enable the button using JavaScript once the form is valid and ready for submission.

If you have a primary and secondary call to action, use color, size and styling to show the hierarchy.

If are wondering whether the confirmation button should come before or after the cancellation button, so am I (and a lot of other people). If you are building a native app, stick to the OS guidelines. It’s become particularly fun since Android changed the button positions in its fourth version. On the web, it’s more complicated because there are no real guidelines. Regardless of the OS, here are some general guidelines for mobile-optimized submit buttons:

• Give the call to action descriptive, actionable verbs.
• Provide visual feedback when the user taps it.
• If you have two buttons, make the primary action stand out.
• Unless you’re working on a very specific back-office enterprise form (in which case, you’ll have a lot of challenges optimizing for mobile), avoid a reset button. Users might confuse it with the submit button and will lose all of their data by accident.

Conclusion

In this first part, I’ve discussed a lot of little techniques to take your form to the next level and help users fill it in. Some of these general guidelines and mobile best practices might not work 100% of the time — that’s the catch with best practices. So, always test your forms on real users and real devices, and adapt the guidelines to your users’ specific needs and experience.

Also, do some regression and automated functional testing — again, on real devices. Chrome’s mobile emulator won’t be enough to test touch-optimized forms. I say this because I had launched an e-commerce website with a search form that didn’t work on mobile. We only did automated testing using an emulator. Here is what happened. The search form was hidden under a search icon. You could tap on the button, which opened a box with the search field. It worked by emulating a mouse hover as a touch event. We tested tapping on the button, and it opened the box. Nobody tried to launch a search. So, nobody (not even the client) saw that the search field disappeared as soon as users tried to interact with it. What happened? When the input element got focus, the button lost the hover state, so it closed the box with the field. Automated testing was not able to catch this because the input was not losing focus. So, we launched an e-commerce website without search functionality on mobile. Not a super experience.

In the second part of this series, we will see more advanced mobile-specific techniques. We will see how to use cool HTML5 features to format fields and how to use mobile capabilities to take the mobile user experience to the next level.

(lf, ra, al, il)