Règles de conception

Nos parcours de devis, de souscription sont construits sous forme de formulaires.
Retrouvez dans cette page l'ensemble des règles qu'il faut prendre en compte lors de la conception de nouveaux parcours.
Cette page est à destination des Ux designers, mais pas seulement, car elle permet de prendre conscience qu'il existe un cadre pour la création d'un formulaire.

Information

Les règles ci-dessous sont issues d'un état de l'art constitué à partir de veille (scientifique ou non) et de benchmark.
Si vous pensez qu'il faut ajouter ou préciser des règles, n'hésitez pas à nous contacter : design.system@maif.fr

#principes-generaux

Principes généraux

img-principes-generaux-legende.png

Afin de permettre à l'utilisateur de scanner plus facilement le formulaire, de diminuer sa charge de travail, pour rendre plus digeste la saisie des formulaires (et donc pour optimiser le taux de complétion des formulaires de maif.fr), il est conseillé de suivre ces quelques règles de base :

  • 1 : version "light" du header et du footer
  • 2 : étapier
  • 3 : une étape = une section
  • 4 : CTA primaire
Information

1 élément de formulaire = 1 fonction
Pour éviter toute erreur de conception, l'astuce est de vérifier que le formulaire qui a été conçu répond à cette règle simple et logique : 1 élément de formulaire = 1 fonction. Ainsi, par exemple, un titre de section ne peut pas être un label de champ.

1. Utiliser la version "light" du header et du footer

Lorsque l'utilisateur arrive sur un tunnel de conversion (ex : formulaires devis-souscription) : utiliser les versions light des headers et footers​.
Cela permet de diminuer la densité informationnelle afin que l'utilisateur reste focalisé sur le formulaire​.

2. Découper le formulaire en étapes

Le fait de découper le formulaire en étapes permet d'équilibrer la charge de travail de l'utilisateur.
Équilibrer les étapes les unes des autres, permet aussi de lisser la charge de travail de l'utilisateur. Pour l'équilibrer, il faut prendre en compte le nombre de champs et l'effort consenti pour renseigner ces champs (par exemple, si certaines informations demandées requièrent une recherche approfondie, alors il faudra réduire le nombre de champs).
Ce découpage répond aussi au critère ergonomique de convention, les utilisateurs étant habitués à ce type de découpage, notamment sur les sites d'e-commerce.
Chaque étape doit porter un titre explicite et suffisamment évocateur pour les utilisateurs (critère de compréhension).
Chacune de ces étapes est signifiée dans un wizard (barre-étape) situé en haut de chaque page de formulaire.

3. Découper chaque étape en sections

Lorsqu'une étape comporte un nombre de champs de saisie supérieur à 5, alors il est préférable de découper le formulaire en sections. Cette meilleure structuration de l'information permet une meilleure lisiblité ; ce qui permettra aux utilisateurs de le scanner plus rapidement, et d'en améliorer le taux de complétion.
Chaque section doit être titrée (titre de section) et comporter un maximum de 5 champs de saisie du même thème, Si le nombre excède 5, alors il est préférable de regrouper différemment les champs pour faciliter le travail des utilisateurs.
ll n'y a pas de nombres de sections maximal par étape ; cependant, il faut veiller à ce que chaque étape soit digeste pour l'utilisateur. Dans le cas contraire, le risque est que l'utilisateur stoppe sa complétion, et plus largement que son expérience vécue avec MAIF soit décevante.

4. Terminer chaque étape par un CTA primaire

Pour permettre à l'utilisateur de passer à l'étape suivante, puis pour valider son formulaire, le choix d'un CTA primaire justifié à droite est conseillé. Cela permet d'assurer une cohérence au sein d'un formulaire et entre les différents parcours de maif.fr.
Un CTA secondaire ou un simple lien suffit pour signifier un retour vers une étapes précédente, pour en limiter l'affordance ; le but étant de toujours favoriser la conversion.

#hierarchie-info

Hiérarchie de l'information

Utilisation de l'affordance pour dimensionner la taille des champs

La taille des champs doit être adaptée au contenu attendu.
À noter par exemple que le nombre de caractères attendu pour les numéros de téléphone est toujours le même, ainsi le nombre de caractères est prévisible.

Don't

affordance champs dont
Champs de même longueur

Ici, tous les champs sont de la même taille, l'utilisateur n'a aucun moyen de comprendre, juste en scannant le formulaire, quel type de donnée va lui être demandée.

Disposition des champs sur une même colonne

Pour éviter les mouvements oculaires, les champs doivent être disposés sur une seule colonne.

champs de formulaire alignés sur une colonne
Exemple à suivre

Ici, les champs de saisie sont alignées sur une colonne

Don't

champs disposes en ligne dont
Aligner sur une même ligne

Ici, les champs sont alignés, ce qui accroît les mouvements oculaires de l'utilisateur.

#feedback

Feedback

Mise en avant visuelle du focus

L'objectif est de permettre à l'utilisateur de savoir sur quel champ est positionné son curseur.
Dorénavant un effet graphique est visible lorsque le champ est actif.

Signification des erreurs

Lorsque l'utilisateur commet une erreur ou oublie un champ, lui signifier les erreurs avec un message clair et précis (critère de compréhension) permettra de la corriger avec efficacité. Par ailleurs, une ancre positionnée au niveau de la première erreur (s'il y en a plusieurs) lui permettra de ne pas chercher où se trouve l'erreur dans le formulaire, et donc de la frustration (critère de gestion des erreurs).

Don't

exemple affordance do
Adresse e-mail erronée
exemple affordance do
Date erronée

#utilisabilite

Utilisabilité

Copier/coller

Pour faciliter la saisie dans les formulaires et éviter des erreurs, le copier-coller est possible dans l'ensemble les champs de formulaires. Cette bonne pratique d'utilisabilité est aussi une bonne pratique d'accessibilité.

Champs obligatoires

Il est préférable d'indiquer aux utilisateurs les champs optionnels que les champs obligatoires. Et si un champ est optionnel, la meilleure pratique est de ne pas l'afficher à l'utilisateur pour optimiser la rapidité de complétion du formulaire.

Don't

img-champ-obligatoire-optionnel-dont1.png
Astérisque en fin de label

Boutons radio / dropdown

Les boutons radios sont à privilégier lorsqu'il y a moins de 6 options à afficher à l'utilisateur. Lorsque le nombre de valeur est supérieur, il est possible d'utiliser une liste déroulante (dropdown).

Don't

img-radio-dropdown-dont1.png
Radio ≥6
img-radio-dropdown-dont2.png
Liste déroulante < 7

Checkbox ou bouton radio versus toggle

Le toggle (interrupteur) est un élément à privilégier pour "activer" ou "désactiver" un élément, sans bouton de validation à la suite, la checkbox (case à cocher) permet d'ajouter un élément, une option. Un bon moyen de trancher entre les deux options : si un bouton de validation suit les options à choisir, alors c'est une checkbox qu'il faut utiliser.

Don't

img-checkbox-toggle-dont1.png
Toggle

Éviter d'utiliser des placeholders

Pour donner un exemple ou autre, il faut essayer d'éviter d'avoir recours aux placeholders. Des études ont montré que des utilisateurs pensaient le champ déjà saisi, ce qui générait une erreur (et de la frustration côté utilisateur). Pour ce faire, il vaut mieux avoir recours aux sous-labels.
Une exception est possible lorsque certains champs sont plus compréhensibles avec un masque qui indique le format attendu (champ date, champ de numéros de carte bancaire...). Ces masques ne comportent pas de caractères alphanumériques.

Don't

img-placeholders-dont1.png
Exemple de données saisies dans les champs

Double saisie de champ

Dans la mesure du possible, il est préférable d'éviter de doubler les champs de saisie pour l'utilisateur. Lorsque le bénéfice attendu est supérieur à la potentielle frustration engendrée, alors on tolère la double saisie (exemple : il est possible de demander une confirmation de l'email de l'utilisateur si ce dernier est le seul moyen pour lui d'avoir accès à son compte).
Pour les mots de passe, il est très fortement déconseillé de demander une double saisie. Dans ce cas précis, il est préférable de laisser la possibilité à l'utilisateur de voir sa saisie.

Don't

img-double-saisie-dont1.png
Numéro de téléphone
img-double-saisie-dont2.png
Mot de passe

#accessibilite

Accessibilité

Utilisation de la touche TAB

Il est nécessaire de faire en sorte que la touche TAB permette à l'utilisateur de passer de champ en champ dans un formulaire.

Bonnes pratiques associées (Issues des cheklists OPQUAST) Le site est intégralement utilisable au clavier [lien externe] Le focus clavier n'est ni supprimé ni masqué.[lien externe]

Veiller à utiliser les bonnes balises html

Pour les utilisateurs qui utilisent des lecteurs d'écrans, cette bonne pratique est primordiale. En effet, respecter la sémantique html permet aux déficients visuels de ne pas être perdus dans l'interface. Ainsi, un titre de section ne peut pas être utilisé comme label de champ de formulaire. De la même façon, un champ de formulaire doit toujours être accompagné de son étiquette (label).

Éviter d'utiliser les tootips "i"

Parce que ces tooltips demandent à l'utilisateur une action supplémentaire et que les lecteurs d'écran ne les lisent pas, il est préférable d'éviter d'utiliser les tooltips "i" à la faveur des sous-labels, pour apporter des explications essentielles à la complétion, des exemples etc...

Don't

img-tootips-dont1.png
Utilisation du picto d'information en fin de label

Lorsqu'une information est indispensable à la complétion d'une question, le tooltip i n'est pas suffisant. Il faut privilégier un sous-label qui guidera plus facilement l'utilisateur. Ici, par exemple, une location de moins de 30 jours par an est trop floue pour qu'un utilisateur comprenne immédiatement ce à quoi cela fait référence.

Les don't en résumé

img-champ-longeur-egal-dont1.png
Champs de même longeur
img-2champ-aligne-1ligne-2-dont1.png
Alignement sur 2 colonnes
img-message-erreur-dont3.png
Message d'erreur non explicite
img-champ-obligatoire-optionnel-dont1.png
Légende d'astérisque en fin de label
img-radio-dropdown-dont1.png
Boutons radio trop nombreux
img-checkbox-toggle-dont1.png
Pas d'action de validation avec un toggle
img-placeholders-dont1.png
Placeholder induit en erreur
img-double-saisie-dont1.png
Double saisie
img-tootips-dont1.png
Tooltip i pour une info indispensable à la complétion