Améliorer la saisie des dates dans nos funnels

Contexte général de la saisie de date

Permettre à nos utilisateurs de vivre une meilleure expérience passe parfois par des détails. Lors de la complétion d’un formulaire de devis-souscription, un grain de sable peut devenir un gros caillou, avec des conséquences dommageables, aussi bien pour l’utilisateur que pour l’entreprise.

La saisie d’une date en est l’exemple parfait. Ce sujet est identifié depuis longtemps dans le collectif des designers MAIF.

Il existe 3 types de date :

• la date dont on sait qu’elle est lointaine (exemple : une date d’anniversaire dans le contexte maif.fr),
• la date dont on sait qu’elle est majoritairement proche (exemple : la date de début d’un contrat d’assurance),
• la date dont on ne peut pas savoir si elle est proche ou lointaine (exemple : la date d’obtention du permis de conduire qui peut être proche pour un jeune conducteur mais lointaine pour un conducteur chevronné).

Au départ de notre réflexion sur ce sujet, nous nous sommes notamment basés sur un article de Raphaël Yharrassarry[1].

Pour la saisie des dates proches, le choix avait été fait d’utiliser les date pickers natifs, dont le fonctionnement est géré soit par l’OS (iOS pour un iPhone ou Android pour un smartphone type Samsung), soit par le navigateur (Chrome, Firefox, etc…). De ce fait, en termes d’utilisabilité, les dates pickers sont différents et ne se valent pas. Deux des plus grands avantages de ces champs date : ils sont accessibles aux personnes en situation de handicap et plus simples à maintenir.

Pour les dates lointaines, l’article de R. Yharrassarry indique qu’un champ de saisie unique (sans date picker) permettrait une saisie plus efficiente. Le souci : en HTML, les inputs de type « date » en mobile ouvrent toujours le calendrier ; seule la vue desktop permet une saisie au clavier. On a donc dû bricoler, déjà, à l’époque, pour la vue mobile afin de réaliser un champ date qui, au focus, déploie le clavier numérique, et pas un calendrier : c’est alors un input type “tel” qui avait été utilisé.

Et malheureusement, bon nombre de développeurs utilisaient uniquement le date picker (input type « date »), ne sachant pas qu’un autre champ existait : finalement le champ de saisie unique n’a été que très peu utilisé avant notre expérimentation.

Constats, analyse et problématique

Malgré ces efforts, bon nombre de designers ont constaté des problèmes d’utilisabilité dans le champ de saisie unique (principalement dans la prévention et la gestion des erreurs), comme l’impossibilité de placer le curseur précisément entre 2 caractères ; ou encore la touche « suppr » qui effaçait des groupes de 2 caractères (ce qui pose un problème aux utilisateurs qui saisissent en regardant leur clavier mais pas l’écran).

Au clic entre les 2 m, le groupe mm est sélectionné avec impossibilité d’afficher l’insert clignotant

La saisie de date lointaine génère de nombreuses erreurs, qui semblent être à l’origine d’abandons de parcours. Sur ce point, l’analyse de la data fournie par le plan de marquage nous a beaucoup aidés. Elle indiquait souvent une chute importante entre l’étape où les informations personnelles étaient demandées et celle d’après. L’analyse de session replay avec Content Square[2] a affiné notre hypothèse : on constatait des récurrences de clics sur le champ date ; au moment de la saisie de la date de naissance notamment.

Exemple de session replay sur un champ date dans un parcours de devis MAIF

Les champs date n’étaient pas accessibles. Nous avons la volonté de produire des composants de formulaires accessibles à court/moyen terme : c’est l’occasion de mutualiser des travaux qui permettent d’accessibiliser nos composants en améliorant leur utilisabilité.

Un autre problème : nous héritons du design des dates pickers natifs des OS lorsque nous les utilisons. Cela nous semble d’ailleurs incroyable qu’Apple et Google n’aient pas conscience des soucis d’utilisabilité de leurs composants pour la saisie de date lointaine (affordance du changement d’année pour Android et mois-année pour iOS) ou du moins qu’ils ne l’améliorent pas.

Moyen d’accès aux autres mois et années sur iOS

Moyen d’accès au changement d’années sur Android

Hypothèses

Une hypothèse s’affine alors : fatigués de cliquer mois par mois pour arriver jusqu’à leur mois de naissance, certains utilisateurs, ne comprenant pas comment utiliser un date picker, finissent tout simplement par quitter le funnel. En plus de frustrer un utilisateur, on perd un potentiel sociétaire, et nous ne lui laissons pas une image positive de la MAIF. Tout le monde est perdant.

Forts de nos enseignements passés, nous formulons 2 hypothèses :

• La saisie de date lointaine est plus efficiente et satisfaisante via un champ date unique
• La saisie de date proche est plus efficiente et satisfaisante via un date picker natif

Conception et spécifications

À ce moment-là de la réflexion, la décision est prise (et financée) de réaliser une étude pour évaluer l’utilisabilité de différents composants de saisie de date.

Comme l’article sur lequel nous basons notre réflexion commence un peu à dater, que les composants d’interface ont eux aussi évolué dans le temps, nous décidons de mettre à l’épreuve 4 types de composants :

• Le champ de saisie unique actuel (sans amélioration ni accessibilisation), pour avoir un repère, une “condition contrôle”. Parmi les défauts de ce champ on retrouve :

• le placeholder de ce champ disparait au focus : le format de saisie attendu disparait donc lui aussi
• le message d’erreur se place avant même la fin de la saisie de l’utilisateur
• on ne peut pas placer le curseur où on souhaite dans le champ
• Certaines dates “impossibles” sont automatiquement remplacées (par exemple, la saisie du nombre 13 pour le mois est automatiquement remplacée par le nombre 12, une année n’étant composée que de 12 mois)

Composant de saisie de date “champ date unique actuel”

• 3 champs distincts (un pour le jour, un pour le mois, un pour l’année), qui présente l’avantage de réduire considérablement les risques d’erreur en base de données. Nous décidons de ne pas avancer le focus automatiquement, à la suite des conseils de nos experts accessibilité. Cependant, cette fonctionnalité, si elle permet d’accessibiliser le composant nous refroidit un peu sur son appétence et son efficience.

Composant de saisie de date “3 champs distincts”

• Les date pickers « natifs » : aka “input type date” pour nos amis intégrateurs. Eux sont gérés par les OS et/ou les navigateurs. Ils sont accessibles et présentent le gros avantage d’être bien plus simples à maintenir techniquement. On décide juste d’ajouter un sous-label avec le format de saisie attendu pour l’affichage desktop, qui autorise la saisie au clavier.

Composant type “date picker natif”

• Un nouveau champ de saisie unique, sur le principe du champ de saisie actuel, avec une meilleure prévention et gestion de l’erreur, qui respecte les règles d’accessibilité.

Composant de saisie de date “nouveau champ de saisie unique”

Pour permettre la meilleure utilisabilité possible, des spécifications détaillées sont écrites. Parmi les améliorations implémentées du nouveau composant de saisie de date unique :

• le message d’erreur n’apparait qu’en sortie de focus
• le retour arrière est possible caractère par caractère
• le curseur peut être placé n’importe où dans le champ et ne sélectionne plus un groupe de 2 caractères : l’insert clignote à l’endroit désiré par l’utilisateur
• on décide aussi de ne plus forcer certaines dates, de ne pas présumer d’une erreur de l’utilisateur et de ne pas la corriger automatiquement.

Développement React et réalisation de l’application de test

Chacun des composants a donc été développé avec la technologie React, puis recetté.

Ensuite, une application de test a été développée par Pierre Weber (développeur front), puis déployée sur notre serveur d’expérimentations creative.maif.fr.

Expérimentation

Pour réaliser l’expérimentation, et éviter tout biais, nous avons choisi de faire appel à Ludotic, et plus précisément à l’expertise, notamment en statistiques, de Sébastien Chalmé (UX researcher) : nous souhaitions en effet que les résultats soient statistiquement significatifs.

Conditions de test réalisés dans nos locaux à Niort, avec Sébastien Chalmé (Ludotic)

En ce qui concerne le recrutement des participants à cette étude, nous avons fait appel à des salariés MAIF (qui ne font pas partie de notre service pour éviter, de nouveau, tout biais). Cela nous semblait raisonnable dans la mesure où cette expérimentation ne portait pas sur la compréhension d’une offre ou d’un service, mais uniquement sur l’utilisabilité de saisie de dates. Un grand merci à eux pour leur participation.

Chacun des 30 participants a saisi 64 dates, proches et lointaines, sur desktop et mobile (iOS ou Android, suivant le mobile du participant) sur les 4 types de composants, dans un ordre contrebalancé, en plusieurs séries et avec des pauses.

Nous souhaitions analyser les 3 composantes de l’utilisabilité[3] :

• L’efficacité : “l’utilisateur réussit à utiliser le système comme désiré”.
  Dans notre étude : le nombre de réussites / d’abandons et le nombre d’erreurs de saisies au final
• L’efficience de la complétion : “l’utilisateur effectue sa tâche facilement en mettant en œuvre un minimum de ressources“
  Dans notre contexte : la durée de saisie pour chaque date, le nombre d’erreur/de corrections par rapport à un comportement optimal, Le moyen utilisé pour saisir la date -au clavier, à la souris, un mélange des 2-, la saisie du 0 devant les unités
• La satisfaction : “Le système est agréable à utiliser”.
  Ici, la facilité ressentie et le temps perçu et au final le tri des composants dans l’ordre de préférence en fin de session.

Nous avons choisi de faire saisir des dates écrites en toutes lettres, avec des espaces plus importants entre chaque élément de date (jour, mois et année) afin d’en faciliter la lecture.

Exemple de date à saisir écrite en toutes lettres

Entre chaque série de saisie, les participants devaient renseigner des questionnaires avec des échelles graduées de 0 à 10, afin d’évaluer les critères subjectifs de satisfaction, de difficulté et de rapidité perçue notamment.

L’étude fera l’objet d’un billet de blog chez Ludotic : pour plus de précisions sur son protocole, l’analyse de ses résultats, n’hésitez pas à le consulter.

Résultats

Le composant qui arrive en dernière position est le date picker. Il engendre le plus d’abandons et d’erreurs (en mobile, un peu plus sur Android que sur iOS). Il a été jugé comme étant le moins satisfaisant, le moins rapide et le moins facile pour saisir une date, qu’elle soit proche ou lointaine.

Il est suivi par les 3 champs de saisie, jugé assez moyennement satisfaisant, moyennement rapide et facile. Pour autant, la saisie d’une date est beaucoup plus rapide qu’avec un date-picker. Tel qu’on pouvait le prévoir, le focus qui ne passe pas automatiquement d’un champ à un autre engendre de la frustration, principalement chez les utilisateurs qui utilisent souvent ce type de composants qui peuvent être implémentés avec un changement de focus automatique d’un champ à l’autre (de jour à mois, puis de mois à année) lors de la saisie.

Le champ unique actuel (avant accessibilisation), est le premier dans l’ordre de préférence, jugé très satisfaisant, très rapide et très facile. Le temps de saisie est plus rapide qu’avec les 3 champs et le date picker.

Le nouveau champ de saisie unique arrive 2e dans l’ordre de préférence. Il n’y a pas de différence significative dans la durée de saisie des dates avec le champ unique actuel. Un dysfonctionnement sur la condition Samsung de test a eu un gros impact sur les résultats : par manque de temps nous n’avons recetté que sur iPhone (nous avons utilisé nos smartphones personnels qui étaient des iPhones) mais pas sur Android (que nous n’avions pas), et l’ajout du slash automatique n’a pas fonctionné.

Recommandations et prochaines étapes

A la suite de l’analyse des résultats, nous avons décidé de conserver le champ de saisie unique et accessible en corrigeant les bugs et en y apportant encore quelques améliorations (l’ajout automatique du zéro dans les unités notamment) pour la saisie de dates lointaines, comme la date de naissance, ou de l’obtention du permis de conduire.

Pour les dates proches, nous avons décidé de garder l’utilisation du date picker, malgré les résultats de l’expérimentation. En effet, nos dates proches concernent principalement la date de début d’un contrat. Pour aider les utilisateurs dans la saisie de ce type de date (« je dois assurer mon appartement dès le 1er samedi de mars », par exemple), l’ouverture d’un calendrier permet un repère (la combinaison jour-date). Or cette étude ne permettait pas d’évaluer la nécessité d’un repère dans le calendrier, pour associer une date à un jour précis (il n’y avait pas de consigne du type “samedi prochain”). Cela nous permettra par ailleurs de suivre l’évolution du design des date pickers par Apple et Google notamment, d’en analyser la data, et peut-être de faire évoluer nos recommandations dans le temps.

Aujourd’hui, le composant a été développé avec React par les développeurs front, et il a été intégré dans notre librairie de composants. C’est le même composant qui permet, en fonction de son paramétrage, d’être soit “date proche” ou “date lointaine”, afin d’éviter toute multiplication de composants et éliminer les potentiels doutes des développeurs.

Enfin, chaque designer indiquera si le champ appelle soit une date proche ou une date lointaine dans les spécifications d’interface.

Un grand merci à Pierre Weber, Maxime Claveau, Benjamin Papillault, Jérôme Gatefin ainsi que Sébastien Chalmé. L’implication de chacun a permis de mener à bien ce projet, et d’aboutir à une solution implémentable, accessible et utilisable par chacune des squads de la Digital Factory MAIF. Mille mercis à François Jouachim et Julia Goudeau-Piveteau pour m’avoir soutenue tout au long de cette étude.

[1]. “Le choix de la date”, Raphaël Yharrassarry, 2014. https://blocnotes.iergo.fr/concevoir/le-choix-de-la-date/

[2]. Le session replay, solution de Content Square, est un outil d’analyse qui permet de suivre le comportement d’utilisateurs (échantillon). Il s’agit d’une reconstitution d’une session utilisateur. Toutes les informations enregistrées sont anonymisées (que ce soit la saisie de l’utilisateur ou les textes de la page web, par exemple les titres ou les labels des champs). Cela permet de suivre les clics, hovers ou swipe, et de suivre les erreurs remontées sur le site. https://contentsquare.com/fr-fr/produit/modules/session-replay/

[3].Définition de l’utilisabilité selon la norme ISO 9241–11:2018 https://www.usabilis.com/definition-utilisabilite-usabilite/)