Capsule Design #13 : Des formulaires pour toutes et tous !

Terminons la saison avec un sujet qui peut sembler anodin, mais qui est pourtant récurrent et souvent primordial dans un projet impliquant du design d’interface : les formulaires !

De la bonne compréhension de leurs caractéristiques aux obligations légales de conception en passant par nos astuces (sourcées !) pour les rendre moins rébarbatifs aux utilisateurices, Manuel et Arnaud reviennent dans cette Capsule Design sur ces éléments d’interface incontournables.

Bel été, bonne écoute à tous et à toutes, rendez-vous à la rentrée !

Manuel : Bonjour à tous et à toutes, ici Manu, développeur front-end au sein de l’Agence LunaWeb et bienvenue dans le dernier épisode de la saison de Salut les Designers !

Très content d’avoir pu vous proposer cette année encore 10 podcasts, merci aux invité.e.s de cette saison et à l’accueil que vous avez réservé à la Capsule Design, notre format en compagnie d’un.e membre de l’agence.

Terminons la saison avec un sujet qui peut sembler anodin, mais qui est pourtant récurrent et important dans une démarche de design UX et UI, les formulaires et plus particulièrement, les bonnes pratiques à intégrer lors de leur conception.

Pour en parler, je suis avec Arnaud, UX/UI Designer à l’agence avec qui je travaille sur VEGA, notre solution interne pour améliorer la collaboration entre les pôles design et technique.

Nous lui avons d’ailleurs dédié notre dixième Capsule Design, n’hésitez pas à l’écouter si ce n’est pas encore fait. Salut Arnaud, comment ça va ?

Arnaud : Salut Manu, ça va bien, merci, j’espère que toi aussi.

Manuel : Oui oui, ça va bien. Pour lancer la discussion et poser un contexte clair, est-ce que tu peux expliquer de quoi on parle quand on évoque un formulaire ?

Arnaud : On a plusieurs formes possibles quand on parle d’un formulaire. Par exemple, on a le formulaire de contact, qui est un peu le le plus courant. C’est ce qui va permettre de rentrer en communication avec un service en ligne.

Ça permet aussi d’envoyer, par exemple, son nom, son prénom, un email, un numéro de téléphone, etc. On va avoir à l’intérieur, des champs textuels qui vont permettre de rédiger librement, ou des champs qui vont être un peu plus restreints et dans lesquels on va pouvoir choisir des éléments via une boîte de dialogue.

On a d’autres options possibles aussi qui sont les cases à cocher, les boutons radio qui vont permettre de sélectionner une option à travers un groupe de possibilités.

Les formulaires, c’est quelque chose que l’on utilise possiblement toutes et tous quotidiennement, sur nos sites et applications.

Et après, on a des formulaires qui ont bien d’autres formes. Par exemple, en dehors du formulaire de contact, des choses qu’on utilise assez souvent, ça va être des formulaires pour se connecter, pour s’inscrire, pour commander, pour payer en ligne. Et puis même, on va dire dans le truc le plus simple et qu’on utilise dès qu’on ouvre un navigateur, ça va être de faire une recherche sur Google ou sur n’importe quel autre moteur de recherche.

Il faut savoir aussi que c’est quelque chose qu’on va vraiment retrouver partout. Par exemple, quand on veut ouvrir notre application pour envoyer un message, et c’est quelque chose qu’on fait possiblement toutes et tous quotidiennement, là aussi, on va utiliser un formulaire.

Manuel : Ok, donc ce sont des éléments essentiels pour un grand nombre de services en ligne. On imagine donc que s’ils sont mal conçus, alors on exclut très vite un grand nombre d’utilisateurices ?

Arnaud : Exactement. En fait, le formulaire, il vient créer du lien entre les utilisateurs, les utilisatrices et le service en ligne. Je vais reprendre encore l’exemple du formulaire de contact, mais s’il ne fonctionne pas bien, ça aura un énorme impact sur les résultats et sur le taux de transformation attendu, par exemple.

Le formulaire créé du lien entre les utilisateurices et le service. Si je n’arrive pas à utiliser le seul moyen de liaison dont je dispose pour interagir lui, il est probable que je m’en aille.

Concrètement, en tant qu’utilisateur, si je n’arrive pas à utiliser le seul moyen de liaison dont je se pose pour interagir avec ce service en ligne ou avec ce site, je m’en vais. Et c’est important, c’est pour ça que je le souligne, parce qu’aujourd’hui, on a de plus en plus de sites et de services en ligne qui ne proposent pas d’alternative physique ou par téléphone. C’est hyper dommage parce que ça va exclure un grand nombre de personnes.

Manuel : On est bien d’accord.

Ça m’amène justement à un sujet qui est plutôt évident, mais ô combien important qui est l’accessibilité. Est-ce que tu peux nous en parler un peu dans le cadre de la conception d’un formulaire ?

Arnaud : Carrément. C’est même d’ailleurs notre première recommandation, peu importe le projet, et puis c’est l’un des sujets phares de l’agence. C’est la première chose à avoir en tête en conception et c’est même le premier contrôle qualité à effectuer.

Déjà, ce sujet, il n’est pas réservé qu’au formulaire. C’est un sujet de conception globale et il concerne l’ensemble des sites et des services en ligne. Aujourd’hui, pour parler un petit peu chiffre, la Fédération des aveugles, des comptes en France 1,7 million de personnes qui sont atteintes de troubles de la vision. On va parler d’aveugles, évidemment, mais aussi de malvoyants moyens, des gens qui ont une incapacité visuelle sévère. Ça peut être en vision de loin, donc des gens qui ne vont pas forcément distinguer un visage à quatre mètres.

L’accessibilité des formulaires est un sujet majeur de la conception web. En France, c’est 1,7 million de personnes qui sont atteintes de troubles de la vision.

Et en vision de près, là où la lecture est vraiment impossible. Dans le monde, selon l’OMS, tout à l’heure, je parlais justement des chiffres français. L’oms dit qu’on est à 253 millions de personnes qui présentent une déficience visuelle. C’est assez énorme. Et là, on ne parle vraiment que des troubles de la vision. Il faut également comprendre que là, on parlait vraiment des troubles de la vision, mais il y a aussi les handicaps cognitifs, moteurs et même auditifs. Dans le cadre d’un formulaire, ça le concerne un peu moins.

Mais si on parle d’accessibilité, c’est des handicaps qu’il faut prendre en compte en conception. On a dans ces handicaps-là des handicaps qui sont persistants. C’est tous les chiffres que je viens de donner.

En plus des handicaps persistants, il faut aussi compter les handicaps situationnels, qui peuvent nous toucher toutes et tous et arriver à n’importe quel moment.

Ça, c’est quelque chose dont on parle peu, mais on a aussi des handicaps qui sont situationnels. Pour ça, on est toutes et tous concernés et ça peut arriver à n’importe quel moment. On peut être handicapé temporairement ou même avec, je ne sais pas, un reflet dans l’écran de notre téléphone.

Manuel : Je rebondis justement sur la partie handicap auditif. Malheureusement, les formulaires sont aussi concernés par ce handicap, puisque dans le cadre de CAPTCHA, qui sont là pour vérifier si on n’est pas un robot, on est bien une personne humaine qui répond aux formulaires, il peut arriver qu’il y ait une alternative – d’ailleurs, c’est c’est quelque chose de recommandé – auditive.

Et dans ces cas-là, si cette alternative-là n’est pas accessible, automatiquement, ces personnes-là ne vont pas être en mesure de répondre correctement ou de soumettre leur formulaire comme il faut.

Arnaud : Oui, tout à fait. Merci d’avoir précisé. Tout ça pour dire qu’il faut qu’on porte attention, justement, à ce besoin d’accessibilité. Ne pas le prendre en compte, c’est hyper discriminant et c’est mettre de côté une grande partie de la population. On ne s’en rend pas compte au quotidien, mais la plupart des handicaps sont imperceptibles. Et dans notre bulle quotidienne, on ne va pas forcément s’en rendre compte.

Manuel : Exactement. Et pour cela, on a plusieurs moyens à disposition. Le plus emblématique en France, c’est le RGAA, avec ces 106 critères qui a été créé et continue d’évoluer pour guider au mieux les différentes parties prenantes d’un projet dans chaque prise de décision. Ce sont des critères qui sont officiels.

D’ailleurs, on s’est formé à la réalisation d’audit d’accessibilité à l’agence pour pouvoir mieux évaluer nos réalisations et proposer cela à nos clients. Ça permet vraiment de vérifier l’état d’un site ou d’un service, aussi bien graphiquement que techniquement.

Cet audit me semble être un excellent point de départ pour commencer à revoir de fond en comble un site, un service ou même un formulaire ciblé.

Arnaud : À noter d’ailleurs, je précise qu’à partir du 28 juin 2025, toutes les entreprises privées, excepté les entreprises de moins de 10 personnes ou dont le chiffre d’affaires ou le bilan n’excède pas 2 millions d’euros, seront concernées par cette obligation d’accessibilité.

Le RGAA et ces 106 critères a été créé pour concevoir de manière accessible et continue d’évoluer pour guider au mieux les différentes parties prenantes d’un projet dans chaque prise de décision.

Je le précise parce qu’actuellement, le champ d’application, il est un peu plus restreint puisqu’il concerne tous les sites publics ainsi que toutes les entreprises générant plus de 250 millions de chiffre d’affaires. Pour ça, je rentre pas dans le détail, mais j’invite toutes les auditrices et les auditeurs à se renseigner en détail sur cette directive via le site accessibilite.numerique.gouv.fr et également via le site numerique.gouv.fr dans laquelle nous, on a pu recueillir cette actualité.

Manuel : Raison de plus pour pas négliger cette partie ! Pour rentrer un peu plus dans le vif du sujet, je te propose de nous parler des standards qui contribuent à concevoir un formulaire à la fois accessible et utilisable.

Est-ce que tu peux nous donner des points d’attention sur lesquels il faut se concentrer ?

Arnaud : Dans l’idéal, on recommande d’abord de placer tous les éléments qui vont constituer votre formulaire dans une seule colonne, que ce soit sur mobile ou sur desktop. Je précise sur mobile et sur desktop, parce que sur mobile, on est un peu conditionné par la place qu’on a.

Sur desktop, on est un peu tenté de s’étaler sur toute l’horizontalité de l’écran. Donc, évidemment, si on place tout sur une colonne, on aura plus de longueur, mais sur l’axe horizontal, évidemment, on aura pas mal de vide. C’est quand même beaucoup plus efficace. Je vais expliquer pourquoi.

L’idée, c’est que les yeux puissent lire et découvrir via un rythme très linéaire, chaque élément qui vont constituer le formulaire. Sinon, les yeux vont se balayer à droite, à gauche. Et c’est un peu moins fluide, justement, à lire et à découvrir.

Même si sur Desktop, cela génère des espaces vides qui peuvent faire tiquer en termes de mise en page, placer l’ensemble des champs d’un formulaire sur une même colonne reste une première bonne pratique à appliquer.

Si vous voulez en savoir plus, moi, je vous invite à lire l’excellent article d’Édouard Scott sur le site de Baymar Institute. On pourra peut-être placer l’article dans la bio de ce podcast. On sait que Les espaces vides, ça peut crisper pas mal de personnes, mais c’est dommage parce que c’est un peu grâce à eux que le regard est guidé vers tous les éléments stratégiques.

Ensuite, on recommande de respecter ce qu’on appelle les normes de de chaque élément qui vont composer le formulaire. On peut en lister plusieurs. D’abord, déjà, on va avoir du texte qu’on va retrouver à différents endroits et qui sont hyper indispensables pour identifier ce qu’on demande et ce dont il est question.

Ensuite, on va avoir des champs de saisie libres ou plus restreints via des boîtes de dialogue. On va avoir des cases à cocher et des boutons radio. Et enfin, des boutons qui permettront notamment de valider toutes les données.

Manuel : Il en existe encore pas mal d’autres, mais on a bien conscience que tous les détaillés ici ne seraient pas très radiophoniques.

Pour autant, est-ce que tu peux nous donner quelques exemples importants à garder en tête, selon toi ?

Arnaud : Je vais prendre l’exemple du champ de saisie, qu’on voit souvent justement sur les formulaires. L’un des éléments les plus importants, selon moi, c’est vraiment le label. Je reviens encore au texte. C’est un petit texte qui va se retrouver, justement, en général, au-dessus de la zone de saisie et qui permet d’identifier le champ. Exemple, si on me demande mon prénom sur un formulaire, il sera écrit prénom.

C’est d’ailleurs un élément qu’il ne faut surtout pas confondre avec ce qu’on appelle le « placeholder », qui est souvent présent en niveau de gris, plus ou moins lisible selon le champ de formulaire, et qui se trouve dans la zone d’interaction du champ de saisie. C’est vraiment dans le petit carré, le petit rectangle dans lequel on va commencer à taper des trucs.

Ça peut paraître anodin, mais la bonne gestion du label, du placeholder et de l’aide à la saisie est quelque chose de très important sur un champ, notamment pour être correctement énoncées par les lecteurs d’écran.

Nous, on recommande de ne pas l’utiliser parce qu’il n’est pas toujours bien lu par le lecteur d’écran et il est souvent peu visible. Et une fois qu’on a commencé à écrire, il disparaît. Il y a un autre élément qui est moins connu, mais justement qui permet d’affirmer encore plus, de détailler encore plus ce petit label et ce module d’identification, c’est ce qu’on appelle l’aide à la saisie.

Ça va être une zone de texte additionnelle qui va permettre de spécifier des détails sur ce qui est attendu dans le champ. Par exemple, un mot de passe qu’on va demander lors d’une inscription. On va écrire « mot de passe » dans le label et on va préciser dans l’aide à la saisie, justement, le nombre de caractères minimum, les exigences de sécurité attendues.

Manuel : Et j’en profite, justement, pour remettre une petite couche sur les labels parce qu’ils doivent non seulement être présents visuellement pour chaque champ, mais aussi leur être associés au sein du HTML pour être correctement énoncées par les lecteurs d’écran.

Arnaud : Exactement. Tu fais bien de le préciser. En tout cas, sur les champs de saisie, je pense que j’ai à peu près fait le tour sur ce qui est vraiment important.

Maintenant, on a un autre élément dont j’ai parlé, c’était les cases à cocher, les boutons radio. Et là-dessus, on a un fonctionnement qui est un petit peu différent. Déjà, ces éléments, ils sont souvent introduits par une question ou une légende qui vont permettre de renseigner l’utilisateur sur l’action qu’on attend de lui. Et de manière standard, on va les reconnaître par la présence d’un petit élément graphique qui va précéder justement ce fameux label qui va venir nommer l’option proposée. On va avoir un petit carré si c’est une case à cocher et on va avoir un petit cercle s’il s’agit d’un bouton radio.

Les cases à cocher et les boutons radio sont aussi des éléments qu’il faut bien spécifier, car ils sont très courants dans un formulaire mais pas aussi bien reconnus qu’on ne le pense.

Et utiliser l’un ou l’autre, ça a vraiment énormément de sens parce que la case à cocher permet aux utilisateurs et aux utilisateurs de sélectionner une ou plusieurs options dans une liste, alors que le bouton radio, lui, permet vraiment de ne choisir qu’une seule option dans un groupe existant.

Et visuellement, ces éléments, ils sont conçus pour afficher deux états : activé et désactivé.

Encore une fois, je vais encore parler de label, le texte, il est hyper important pour renseigner l’utilisateur sur l’action qu’on attend de lui, que ce soit au niveau de la légende qui va introduire ces éléments, au niveau de l’intitulé de l’option proposée, voire même dans un texte additionnel pour préciser s’il est possible de sélectionner une ou plusieurs options.

On a des différences de formes d’un bouton radio ou d’une case à cocher dont j’ai parlé, donc le fameux carré et le rond, qui ne sont pas connus de la plupart des gens. Donc c’est important de préciser ça de manière très claire.

Manuel : Et du coup, j’ouvre une petite parenthèse, ce que tu as mentionné, la légende. Il faut savoir que lorsqu’on a plusieurs choix possibles, elle est indispensable.

Typiquement, lorsque l’on demande le genre de l’utilisateurice, on devrait avoir comme légende votre genre et chaque bouton radio aura comme label le choix à proposer. Par contre, pour la case à cocher liée au RGPD, elle est dispensable puisque la réponse est unique. Et… je ferme cette parenthèse.

Arnaud : Héhé.

Manuel : Si tu veux bien, j’aimerais que tu nous parles également des standards de conception plus globaux à respecter.

Arnaud : Je vais parler du premier qui me semble important, c’est les contrastes. Ils sont normés par le RGAA, dont Manu, tu as parlé précédemment. Pour ça, on va demander un rapport de 4.5 sur 1 pour du texte qui a une taille inférieur à 24 pixels et un rapport de 3 sur 1 pour des éléments graphiques, comme le champ de saisie ou même les petits carrés, les petits cercles qui sont les indicateurs d’état qu’on va retrouver dans une case à cocher ou un bouton radio.

La vérification des contrastes, elle n’est pas exclusive au formulaire. Ça va s’appliquer à tous les éléments porteurs d’informations et c’est des points à vérifier absolument pour proposer quelque chose d’accessible. Je parlais des rapports 4.5/1, 3/1, ça peut sembler un peu flou. Il faut savoir que c’est des choses qu’on va retrouver en testant les contrastes via des outils bien précis..

Il y a plein d’outils qui existent. Si vous voulez en utiliser en ligne pour le tester, il y a Colorable, par exemple, ou alors, si, par exemple, vous utilisez Figma, il y a des plugins comme Contrast ou même Stark, qui est un peu plus global et je crois qui est même présent sur sketch et sur d’autres logiciels de conception.

Les contrastes de couleurs et la taille du texte sont deux éléments importants à bien concevoir sur des formulaires accessibles. Deux caractéristiques qui peuvent être testées via des applications des plugins d’outils de design

C’est toujours bien de tester justement ces contrastes au fur et à mesure de l’avancée de son projet en conception. Le deuxième standard, ça va être la taille des éléments. Pour les textes, on en a beaucoup parlé. Nous, on vous recommande de pas être en dessous de 14 pixels, et ce, sur l’ensemble de votre service.

Il y a juste une petite nuance que je me permets de préciser concernant le texte qui va être présent dans la zone de saisie d’un champ. Nous, on vous recommande de ne pas être en dessous de 16 pixels, déjà pour plus de confort d’écriture et de lecture et pour éviter d’avoir une sorte de petit zoom intempestif qui apparaît lors d’une interaction sur iOS.

En termes de taille, nous, on vous recommande de passer la zone de saisie sur une hauteur de 40 pixels minimum, de manière à en faciliter l’interaction, notamment sur les supports tactiles. À noter que la taille recommandée d’un élément interactif est plutôt de 44 pixels sur 44 pixels.

Manuel : Ok. En tout cas, dans tout ce que tu as évoqué jusqu’à présent, on comprend bien que le contenu textuel a une grande importance.

Mais une fois qu’on a fait en sorte que celui-ci soit au bon endroit, visible, lisible et accessible, il reste encore toute la partie rédactionnelle, non ?

Arnaud : Effectivement, et c’est hyper important de soigner cette partie sur laquelle nous devons aussi faire notre part en tant que professionnel. Déjà, si on se met dans la peau d’une personne qui doit remplir un formulaire, on sait que ce n’est pas une tâche qui est forcément aisée. C’est même assez rarement, en vérité, un moment agréable.

Après, tout dépend du contexte, des informations demandées, de la longueur du formulaire, du niveau de connaissance attendu pour le remplir, etc. Si on soigne en conception la rédaction et la microcopie des formulaires, on va vraiment augmenter les chances de complétion. Idéalement, chaque label dans un champ doit être compréhensible par toutes et tous.

Si on soigne en conception la rédaction et la microcopie des formulaires, on augmente les chances de complétion. Idéalement, chaque label doit être compréhensible par toutes et tous.

Par exemple, on va déconseiller d’utiliser du jargon professionnel qui pourrait être traduit facilement par des mots simples. On va essayer d’éviter aussi d’utiliser des termes qui sont utilisés, par exemple, uniquement en interne et qui ne va pas parler à des personnes ciblées par le formulaire. On va éviter aussi des termes vagues ou des termes abstraits qui peuvent être ambigus. L’idée, c’est vraiment d’être le plus clair possible, de vraiment se mettre à niveau sur sa base d’utilisateur.

Encore une fois, c’est une marotte de l’agence, mais on recommande ici de s’intéresser aux utilisateurices qui vont utiliser le service. C’est possible via des études à mener en amont sur le terrain, si le projet le permet, et quand ce n’est pas possible, via des études accessibles en ligne.

Manuel : El Famoso, expérience utilisateur !

Arnaud : C’est ça.

Manuel : Tu en as parlé tout à l’heure en évoquant les difficultés qu’on peut avoir à remplir un formulaire. Concrètement, comment on fait pour simplifier cette tâche et la rendre la moins désagréable possible ?

Arnaud : La réponse la plus courte, c’est de réduire le nombre de champs et des éléments demandés, donc de réduire son formulaire. Conserver vraiment que ce qui est essentiel, éviter de laisser traîner des champs facultatifs avec l’espoir qu’ils soient remplis par l’utilisateur.

On sait que ce n’est pas toujours possible avec certains formulaires de collecte d’informations, mais c’est un peu une balance à à faire lors de la conception. Lors du design, c’est d’ailleurs là où il va falloir vraiment discuter longuement avec toute l’équipe projet.

Et d’ailleurs, pour ça, on a un critère ergonomique qu’on appelle la charge de travail. C’est un des points importants des critères d’évaluation de Bastien et Scapin. Et concrètement, ce critère, il va évaluer la brièveté et la densité des informations qui sont présentes sur une page. Concrètement, plus on va avoir d’éléments sur la page, plus ça peut être compliqué à analyser et à effectuer. Ne pas porter attention à ce critère, c’est prendre le risque de laisser l’utilisateur se décourager et quitter la page.

Plus on va avoir de champs dans un formulaire, plus ça sera compliqué à analyser et à effectuer. Ne pas porter attention à ce critère de “Charge de travail”, c’est prendre le risque de laisser l’utilisateurice se décourager et quitter la page.

Notre rôle, à nous, c’est de sensibiliser le commanditaire à ce genre de choses. On est concepteur, donc on n’aura pas toute l’amplitude qu’il faut pour contrôler chaque élémen t présent sur le formulaire, mais on a la responsabilité de donner les meilleurs conseils pour en faciliter l’usage et pour augmenter le taux de complétion.

En vrai, c’est vraiment dans à l’intérêt de tout le monde.

Manuel : Ouais, mais tu sais tout comme moi que ce n’est pas toujours possible et que certains formulaires très avancés vont demander énormément d’informations. Et dans ces cas-là, tu préconises quoi, toi ?

Arnaud : Déjà, parce que je pense qu’il ne faut pas se résigner trop vite, avant même la conception, il faut vraiment absolument interroger le besoin du formulaire ou du service en ligne. On sait, on peut aller très, très loin techniquement, mais parfois, on peut légitimement se demander si un passage de relais par téléphone ou même en physique ne seraient pas plus efficaces pour atteindre les objectifs.

Ça peut sembler aller un petit peu à contre courant, mais le tout numérique, ce n’est pas toujours la solution idéale à tous les besoins. Il faut savoir doser et encore une fois, s’intéresser à celles et ceux qui vont utiliser ce formulaire et ce service en ligne.

Ça peut sembler un peu à contre courant, mais le tout numérique n’est pas la solution à tous les besoins. Il faut savoir peser le pour et le contre et s’intéresser à celles et ceux qui vont utiliser le formulaire en ligne.

Néanmoins, et pour te donner quand même une réponse, il faut garder en tête que certains services en ligne sont devenus très courants depuis quelques années et vont offrir un intérêt particulier. Par exemple, tout à l’heure, on parlait d’accessibilité et en d’accessibilité.

Et en accessibilité, évidemment, il y a des choses qui ne vont pas pouvoir être effectuées en ligne par certaines personnes, qu’on va devoir mettre en accessibilité. Il y a des choses qui ne sont pas possibles. Il faut savoir qu’il y a des gens aussi qui ne peuvent potentiellement pas se déplacer ou pas téléphoner et qui seront bien contentes d’avoir justement accès à un service en ligne pour pouvoir faire certaines démarches.

Manuel : Je fais partie des gens qui détestent le téléphone, donc ça me va très bien, en effet.

Arnaud : Il faut peser le pour et le contre, mais si je recentre sur les fameux services en ligne qui sont devenus super courants et très utilisés, on a tous beaucoup payé en ligne ou réalisé des estimations diverses avec des calculateurs interminables.

Et dans ce genre de contexte, on va retrouver des formulaires à l’étape. Et ça, c’est une excellente solution pour ne pas intimider l’utilisateur à l’ouverture de la page, c’est-à-dire envoyant un formulaire hyper long et pour le laisser qui vont avancer pas à pas.

Plusieurs études vont d’ailleurs montrer que ce genre de modèle de conception peut augmenter le nombre de conversions d’un formulaire déjà long. Pareil, je pourrais mettre un petit lien dans la bio, justement, à ce sujet.

Pour découper des formulaires trop longs, il est possible de créer des étapes, pour ne pas intimider l’utilisateurice à l’ouverture de la page et y intégrer une estimation de complétion réaliste (et on insiste sur le “réaliste”).

Pour les découper correctement, nous, on recommande d’y intégrer déjà une estimation réaliste. Vraiment, j’appuie le mot réaliste du temps de complétion dès la première étape. C’est une estimation qui peut même être faite dès le bloc de mise en avant du formulaire, par exemple.

Et autre moyen aussi intéressant, c’est ce qu’on appelle un indicateur de progression. Pour ça, on peut avoir un étapier, ou une sorte de barre de progression ou même via du texte qui va indiquer étape 1 sur 4, etc.

Manuel : Oui, c’est quelque chose qu’on retrouve souvent dans les tunnels d’achat ou ce genre de choses.

Et j’ajoute juste un petit élément qui est souvent oublié, parce qu’un peu technique aussi, mais il s’agit des attributs HTML dit autocomplete, puisqu’ils permettent d’indiquer au navigateur l’interface sur laquelle l’utilisateur interagit avec le site, quelles données est attendues au sein du champ, histoire que le navigateur puisse les renseigner automatiquement, quand c’est possible. 

Donc voilà, c’est vrai que ça peut faciliter pas mal le travail, notamment pour les adresses, etc.

Tu parlais d’estimation, d’indicateur de progression, mais est-ce que tu peux nous parler des autres indicateurs qui permettent de donner un retour visuel ou informatif sur les différentes interactions qui peuvent se produire ?

Arnaud : En effet, avant d’aller au bout du formulaire, on sait que les utilisatrices vont devoir effectuer plusieurs clics, vont devoir scroller, taper au clavier, au clavier virtuel, même s’ils sont sur mobile, avant de cliquer sur le bouton de soumission finale. Il peut y avoir énormément d’interactions. Toutes ces actions, toutes ces interactions, elles doivent être visibles, elles doivent être ressenties par l’utilisateur pour qu’il n’ait pas l’impression d’interagir dans le vide. Il va donc falloir faire en sorte, encore une fois, que tout soit le plus fluide possible.

Pour guider l’utilisateurice dans un formulaire, toutes ses actions, toutes ses interactions, doivent être visibles, ressenties, qu’il et elle n’ait pas l’impression d’interagir dans le vide.

Et la première chose à soigner, c’est ce qu’on appelle le focus. Si on prend l’exemple d’un champ de saisie, ça va être un état secondaire qui va donner l’information aux utilisateurs et utilisatrices qui peuvent commencer à taper au clavier.

Ensuite, ça peut être intéressant d’anticiper l’affichage des focus, parce que ça fait partie des critères RGAA. Et pour ça, on peut commencer à poser une réflexion sur le contraste, par exemple, ou utiliser le focus qui est disponible par défaut par le navigateur. Les focus, comme c’est des états supplémentaires, il faut bien penser à vérifier que ceux-ci soient suffisamment différents d’un point de vue formel avec l’état initial de votre élément.

Quand je vous parle justement de contraste, il faut aussi qu’il y ait un contraste différent entre l’état initial de votre champ et avec le focus pour que ce soit bien compris.

Manuel : Je mets ma petite casquette technique, pardon.

Arnaud : Vas-y.

Manuel : Puisque concrètement, ce qu’il faut savoir, c’est que dans le cadre des champs de formulaire, c’est quelque chose qui est nativement implémenté par le navigateur. Donc ce n’est pas un effort supplémentaires. Par contre, il peut être surchargé ou en tout cas modifié si jamais on veut pouvoir avoir quelque chose plus proche de la DA du site.

Néanmoins, il faut faire attention parce que s’il n’existe plus, certains utilisateurices ne vont pas être en mesure de savoir où est-ce qu’ils se situent et s’ils peuvent recommencer à renseigner, comme tu disais, l’information dans le champ.

Arnaud : Tout à fait. Autre chose, ça va être les messages d’erreur qui vont venir renseigner l’utilisateur dans le cas où, par exemple, certains éléments obligatoires n’ont pas été complétés dans le champ ou tout simplement mal renseignés, ça peut arriver, après une première soumission du formulaire.

C’est des messages qui sont hyper importants parce qu’ils évitent justement à quelqu’un de de se bloquer dans un formulaire. Ça nous est tous arrivé, enfin, toutes et tous arrivé, je pense, d’être coincés dans un formulaire à cause d’une erreur impossible à identifier. On ne sait pas pourquoi.

Manuel : C’est extrêmement frustrant.

Arnaud : Le formulaire ne veut pas se valider. Donc c’est assez pénible. Et c’est là où, tout simplement, on peut quitter le site ou le service. Donc l’idéal, c’est évidemment d’être super précis, de bien soigner la rédaction de chaque question, de tous les labels, et de ne pas hésiter à proposer une aide la saisie pour limiter l’apparition de ces messages d’erreur. Il vaut mieux prévenir que guérir. Après, on sait que ça peut toujours arriver.

Chez LunaWeb, nous, on a d’ailleurs fait le choix peu commun de placer nos messages d’erreur entre le label et la zone d’interaction. C’est, selon nous, la meilleure pratique possible pour optimiser nos champs au lecteur d’écran, et ce, pour plusieurs raisons.

Chez LunaWeb, on a fait le choix peu commun de placer nos messages d’erreur entre le label et la zone d’interaction. C’est la meilleure pratique possible pour optimiser les champs au lecteur d’écran.

Déjà, les fonctionnalités de saisie automatique de navigateur peuvent masquer les messages. Par exemple, si vous êtes dans une recherche, vous commencez à taper quelque chose, souvent, vous allez avoir une petite boîte de dialogue qui va apparaître en dessous et qui pourrait masquer potentiellement cet élément.

Les claviers virtuels aussi peuvent les masquer. Ça dépend comment tout ça est fait, mais ça peut arriver. C’est plus logique aussi en termes de lecture pour un lecteur d’écran, parce qu’on va avoir label, message d’erreur, saisie.

C’est un choix qui est peu commun, on le sait, mais c’est plus naturel, selon nous, pour les utilisateurs de lecteurs d’écran, d’avoir un retour d’erreur avant d’accéder au champ. Pour ça, nous, on s’est appuyé, entre autres, sur un article d’Adrien Roselli, on vous mettra encore une fois la source dans la bio du podcast.

Enfin, en dernier lieu, on a le feedback de la délivrance qui va signer la fin du formulaire. C’est l’écran de validation final ou la boîte de dialogue qui va indiquer que le formulaire a été complété et envoyé avec succès.

L’idéal à cet endroit-là, c’est d’en profiter pour fournir des informations complémentaires. Par exemple, je ne sais pas, après une prise de rendez-vous en ligne, on l’a pour beaucoup toutes et tous fait avec Doctolib par exemple, ça peut être intéressant de donner un récapitulatif des pièces à apporter, du lieu, de l’heure de rendez-vous, etc.

Il y a aussi le “feedback de la délivrance” qui vient signer la fin du formulaire. Cet écran de validation final, ou cette boîte de dialogue, qui va indiquer que le formulaire a été complété et envoyé avec succès. L’idéal à cet endroit-là, c’est d’en profiter pour fournir des informations complémentaires.

La question peut aussi se poser d’envoyer un mail automatique de récapitulatif ou de confirmation. Ça, c’est vraiment un choix à peser, qui est important à discuter dès les premières phases de conception, parce que ça peut avoir un impact considérable à l’échelle d’un service en ligne populaire.

Déjà, ça peut vite polluer les boîtes mail. Ce genre d’envoi cumulé, ça va consommer un très grand nombre de ressources et c’est quelque chose à prendre en compte si vous souhaitez éco-concevoir votre service. Ils vous y encouragent, évidemment.

Manuel : Je pense qu’on a fait déjà un beau tour d’horizon des et que nos auditeurs ont la tête déjà bien remplie aussi.

Pour résumer, selon toi, c’est quoi les choses les plus importantes à garder en tête ?

Arnaud : Je ne sais pas si je vais bien les dire dans l’ordre, mais on en a beaucoup parlé, l’accessibilité et les standards. C’est le truc sur lequel vraiment se concentrer on en a parlé pendant tout le podcast, donc je ne vais pas trop m’étendre là-dessus, mais c’est vraiment un truc à garder en tête et à bien creuser.

Ensuite, la sobriété, avoir une démarche d’écoconception, faire attention à la rédaction, à la microcopie, à l’UX writing. Tout ça, c’est des éléments qui sont des bons alliés pour bien optimiser, justement, la conception de nos formulaires. Ensuite, là, on parlait d’accessibilité, de standard et tout.

Pour s’assurer de la bonne conception des formulaires d’un projet à l’autre, il faut concevoir ou utiliser un système de design. Il permettra de standardiser un très grand nombre d’éléments d’interface, dont les formulaires.

Nous, on vous recommande de préparer votre standard ou d’en utiliser un en atomic Design à minima. Si vous utilisez Figma, faites-vous un fichier sur Figma, ou sur sketch ou Adobe XD, si ça existe toujours.

On l’a évoqué dans l’introduction. On en a parlé dans d’autres capsules, mais nous, à l’agence, on a notre système à nous qui s’appelle VEGA et qui nous a aidé à standardiser un très grand nombre de choses qui ont été dites précédemment. Ce standard, cette base, elle va vous permettre de gagner du temps pour s’adapter à chaque demande et au final de passer plus de temps sur la conception et sur le cœur de ce que vous voulez faire.

Et dernière chose, mais pour moi, c’est ce qui reste vraiment le prérequis avant de se lancer dans la conception d’un formulaire, c’est vraiment de réinterroger le besoin, de bien comprendre vos cibles.

Si vous en avez les moyens, tournez-vous vers des UX researchers ou appuyez-vous sur des études existantes. Vos formulaires n’en seront que mieux conçus. 

On a l’habitude de le dire à l’agence, mais si vous en avez les moyens, essayez de vous tourner vers des UX researchers ou appuyez-vous sur des études existantes. On peut en trouver de plus en plus assez facilement. Il faut faire attention aux sources, évidemment, mais l’idée, c’est bien de se baser sur des choses sérieuses et qui vont nous permettre de faire les meilleurs choix.

Manuel : Merci Arnaud pour cet échange autour des formulaires. C’est un sujet qu’on a pas mal creusé ensemble et sur lequel on essaie d’apporter un soin tout particulier à l’agence.

Arnaud : Merci Manu. C’était super de prendre du temps tous les deux sur ce sujet qui nous a tenu en haleine pendant un bon moment et sur lequel on continue d’évoluer au fil de nos recherches et puis des projets à porter à l’agence.

Manuel : C’est ainsi que cette Capsule Design se termine, mais c’est également le dernier épisode de cette saison ! On se retrouve donc à la rentrée et d’ici là, je vous souhaite de passer un très bon été.

Si vous ne l’avez pas fait, n’hésitez pas à vous abonner à la newsletter du podcast pour retrouver l’ensemble des ressources de nos épisodes, les astuces et conseils de nos invités. Tout est disponible sur le site salutledesigner.lunaweb.fr.

À bientôt !

Arnaud : Salut !