Bonnes pratiques concernant les formulaires de paiement et d'adresse

Maximisez les conversions en aidant vos utilisateurs à remplir les formulaires d'adresse et de paiement aussi rapidement et facilement que possible.

Sam Dutton

Les formulaires bien conçus aident les utilisateurs et augmentent les taux de conversion. Une petite correction peut faire une grande différence !

Voici un exemple de formulaire de paiement simple qui illustre toutes les bonnes pratiques :

Voici un exemple de formulaire d'adresse simple qui illustre toutes les bonnes pratiques :

Checklist

Utiliser du code HTML pertinent

Utilisez les éléments et attributs conçus pour le job :

  • <form>, <input>, <label> et <button>
  • type, autocomplete et inputmode

Ils activent les fonctionnalités intégrées du navigateur, améliorent l'accessibilité et ajoutent du sens à votre balisage.

Utiliser les éléments HTML comme prévu

Placer votre formulaire dans un élément <form>

Vous pourriez être tenté de ne pas encapsuler vos éléments <input> dans un élément <form> et de gérer l'envoi des données uniquement avec JavaScript.

Ne procédez pas de cette façon !

Un élément HTML <form> vous donne accès à un ensemble puissant de fonctionnalités intégrées dans tous les navigateurs récents. Il peut vous aider à rendre votre site accessible aux lecteurs d'écran et à d'autres appareils d'assistance. Un <form> facilite également la création de fonctionnalités de base pour les anciens navigateurs qui n'offrent qu'une compatibilité limitée avec JavaScript, et permet d'envoyer des formulaires même en cas de problème avec votre code, ainsi que pour le petit nombre d'utilisateurs qui désactivent JavaScript.

Si vous avez plusieurs composants de page pour la saisie utilisateur, veillez à placer chacun d'eux dans son propre élément <form>. Par exemple, si vous proposez une fonctionnalité de recherche et une fonctionnalité d'inscription sur la même page, placez chacune d'elles dans son propre élément <form>.

Utiliser <label> pour ajouter des libellés aux éléments

Pour ajouter un libellé à un <input>, un <select> ou un <textarea>, utilisez un <label>.

Associez un libellé à une entrée en attribuant à l'attribut for du libellé la même valeur que l'attribut id de l'entrée.

<label for="address-line1">Address line 1</label>
<input id="address-line1" …>

Utilisez une seule étiquette pour une seule entrée : n'essayez pas d'étiqueter plusieurs entrées avec une seule étiquette. Cette solution est la plus adaptée aux navigateurs et aux lecteurs d'écran. Un appui ou un clic sur un libellé déplace le curseur vers l'entrée à laquelle il est associé, et les lecteurs d'écran annoncent le texte du libellé lorsque le libellé ou l'entrée du libellé est sélectionné.

Rendre les boutons utiles

Utilisez <button> pour les boutons. Vous pouvez également utiliser <input type="submit">, mais n'utilisez pas d'élément div ou un autre élément aléatoire agissant comme un bouton. Les éléments de bouton offrent un comportement accessible, une fonctionnalité d'envoi de formulaire intégrée et peuvent être facilement stylisés.

Attribuez à chaque bouton d'envoi de formulaire une valeur qui indique son action. Pour chaque étape du processus de paiement, utilisez un incitation à l'action descriptive qui indique la progression et rend l'étape suivante évidente. Par exemple, nommez le bouton d'envoi de votre formulaire d'adresse de livraison Passer au paiement plutôt que Continuer ou Enregistrer.

Envisagez de désactiver un bouton d'envoi une fois que l'utilisateur a appuyé ou cliqué dessus, en particulier lorsqu'il effectue un paiement ou passe une commande. De nombreux utilisateurs cliquent plusieurs fois sur les boutons, même s'ils fonctionnent correctement. Cela peut perturber le paiement et augmenter la charge du serveur.

const form = document.querySelector('form');
const submitButton = form.querySelector('button[type="submit"]');

form.addEventListener('submit', () => {
  submitButton.disabled = true;
  submitButton.textContent = 'Placing order…';
});

En revanche, ne désactivez pas un bouton d'envoi en attendant que l'utilisateur saisisse des données complètes et valides. Par exemple, ne laissez pas un bouton Enregistrer l'adresse désactivé simplement parce qu'un élément est manquant ou non valide. Cela n'aide pas l'utilisateur, qui peut continuer à appuyer ou à cliquer sur le bouton en pensant qu'il ne fonctionne pas. Si les utilisateurs tentent d'envoyer un formulaire contenant des données non valides, expliquez-leur ce qui ne va pas et comment résoudre le problème. C'est particulièrement important sur mobile, où la saisie de données est plus difficile et où les données de formulaire manquantes ou non valides peuvent ne pas être visibles sur l'écran de l'utilisateur au moment où il tente d'envoyer un formulaire.

Exploiter tout le potentiel des attributs HTML

Faciliter la saisie des données par les utilisateurs

Utilisez l'attribut d'entrée type approprié pour fournir le bon clavier sur mobile et activer la validation intégrée de base par le navigateur.

Par exemple, utilisez type="email" pour les adresses e-mail et type="tel" pour les numéros de téléphone.

Deux captures d'écran de téléphones Android, montrant un clavier adapté à la saisie d'une adresse e-mail (avec type=email) et d'un numéro de téléphone (avec type=tel).
Claviers adaptés aux e-mails et au téléphone.

Pour les dates, essayez d'éviter d'utiliser des éléments select personnalisés. S'ils ne sont pas correctement implémentés, ils interrompent l'expérience de saisie automatique et ne fonctionnent pas sur les anciens navigateurs. Pour les nombres tels que l'année de naissance, envisagez d'utiliser un élément input plutôt qu'un élément select, car la saisie manuelle de chiffres peut être plus facile et moins sujette aux erreurs que la sélection dans une longue liste déroulante, en particulier sur mobile. Utilisez inputmode="numeric" pour vous assurer que le bon clavier s'affiche sur mobile, et ajoutez des indications de validation et de format avec du texte ou un espace réservé pour vous assurer que l'utilisateur saisit les données au format approprié.

Utiliser la saisie semi-automatique pour améliorer l'accessibilité et éviter aux utilisateurs de saisir à nouveau des données

L'utilisation de valeurs autocomplete appropriées permet aux navigateurs d'aider les utilisateurs en stockant les données de manière sécurisée et en remplissant automatiquement les valeurs input, select et textarea. C'est particulièrement important sur mobile, et crucial pour éviter des taux d'abandon de formulaire élevés. La saisie semi-automatique offre également plusieurs avantages en termes d'accessibilité.

Si une valeur de saisie semi-automatique appropriée est disponible pour un champ de formulaire, vous devez l'utiliser. MDN Web Docs fournit une liste complète des valeurs et explique comment les utiliser correctement.

Valeurs stables

Adresse de facturation

Par défaut, l'adresse de facturation est identique à l'adresse de livraison. Réduisez l'encombrement visuel en fournissant un lien pour modifier l'adresse de facturation (ou utilisez les éléments summary et details) plutôt que d'afficher l'adresse de facturation dans un formulaire.

Exemple de page de paiement affichant un lien pour modifier l'adresse de facturation.
Ajoutez un lien pour examiner la facturation.

Utilisez des valeurs de saisie semi-automatique appropriées pour l'adresse de facturation, comme vous le faites pour l'adresse de livraison, afin que l'utilisateur n'ait pas à saisir les données plusieurs fois. Ajoutez un préfixe aux attributs de saisie semi-automatique si vous avez des valeurs différentes pour des entrées portant le même nom dans différentes sections.

<input autocomplete="shipping address-line1" ...>
<!-- Other fields omitted. -->
<input autocomplete="billing address-line1" ...>

Aider les utilisateurs à saisir les bonnes données

Évitez de "réprimander" les clients parce qu'ils ont "fait quelque chose de mal". Aidez-les plutôt à remplir les formulaires plus rapidement et plus facilement en les aidant à résoudre les problèmes au fur et à mesure qu'ils surviennent. Lors du processus de paiement, les clients essaient de donner de l'argent à votre entreprise pour un produit ou un service. Votre rôle est de les aider, pas de les punir !

Vous pouvez ajouter des attributs de contrainte aux éléments de formulaire pour spécifier les valeurs acceptables, y compris min, max et pattern. L'état de validité de l'élément est défini automatiquement selon que la valeur de l'élément est valide ou non, tout comme les pseudo-classes CSS :valid et :invalid, qui peuvent être utilisées pour styliser des éléments avec des valeurs valides ou non valides.

Par exemple, le code HTML suivant spécifie une entrée pour une année de naissance comprise entre 1900 et 2020. L'utilisation de type="number" limite les valeurs d'entrée aux nombres uniquement, dans la plage spécifiée par min et max. Si vous essayez de saisir un nombre en dehors de la plage, l'entrée sera définie sur un état non valide.

L'exemple suivant utilise pattern="[\d ]{10,30}" pour s'assurer qu'un numéro de carte de paiement est valide, tout en autorisant les espaces :

Les navigateurs récents effectuent également une validation de base pour les entrées de type email ou url.

Lors de l'envoi du formulaire, les navigateurs se concentrent automatiquement sur les champs dont les valeurs requises sont problématiques ou manquantes. Aucun code JavaScript n'est requis.

Formulaire de connexion dans Chrome sur ordinateur, affichant l'invite du navigateur et la mise en évidence d'une valeur d'adresse e-mail non valide.
Validation de base intégrée par le navigateur.

Validez les données de manière intégrée et fournissez des commentaires à l'utilisateur au fur et à mesure qu'il saisit des données, plutôt que de fournir une liste d'erreurs lorsqu'il clique sur le bouton d'envoi. Si vous devez valider des données sur votre serveur après l'envoi du formulaire, listez tous les problèmes détectés et mettez clairement en évidence tous les champs de formulaire contenant des valeurs non valides. Affichez également un message à côté de chaque champ problématique pour expliquer ce qui doit être corrigé. Vérifiez les journaux de serveur et les données analytiques pour détecter les erreurs courantes. Vous devrez peut-être repenser votre formulaire.

Vous devez également utiliser JavaScript pour effectuer une validation plus robuste lorsque les utilisateurs saisissent des données et lors de l'envoi du formulaire. Utilisez l'API Constraint Validation (largement compatible) pour ajouter une validation personnalisée à l'aide de l'interface utilisateur intégrée du navigateur afin de définir la sélection et d'afficher des invites.

Pour en savoir plus, consultez Validation des formulaires côté client.

Aider les utilisateurs à ne pas oublier de données obligatoires

Utilisez l'attribut required sur les entrées pour les valeurs obligatoires.

Lorsqu'un formulaire est envoyé, les navigateurs récents affichent automatiquement une invite et mettent en surbrillance les champs required pour lesquels des données sont manquantes. Vous pouvez utiliser la pseudo-classe :required pour mettre en surbrillance les champs obligatoires. Aucun code JavaScript n'est requis.

Ajoutez un astérisque au libellé de chaque champ obligatoire, ainsi qu'une note au début du formulaire pour expliquer la signification de l'astérisque.

Simplifier le règlement

Comblez l'écart entre le commerce mobile et le commerce sur ordinateur

Imaginez que vos utilisateurs disposent d'un budget de fatigue. Si vous l'épuisez, vos utilisateurs partiront.

Vous devez réduire les frictions et maintenir l'attention, en particulier sur mobile. De nombreux sites enregistrent plus de trafic sur mobile, mais plus de conversions sur ordinateur. C'est ce qu'on appelle l'écart du commerce mobile. Les clients préfèrent peut-être simplement finaliser un achat sur ordinateur, mais les taux de conversion plus faibles sur mobile sont également dus à une mauvaise expérience utilisateur. Votre objectif est de minimiser les conversions perdues sur mobile et de maximiser les conversions sur ordinateur. Selon les études, il est possible d'améliorer considérablement l'expérience des formulaires sur mobile.

Surtout, les utilisateurs sont plus susceptibles d'abandonner les formulaires qui semblent longs, complexes et sans direction claire. C'est particulièrement vrai lorsque les utilisateurs sont sur de petits écrans, sont distraits ou sont pressés. Demandez le moins de données possible.

Définir le paiement sans connexion par défaut

Pour une boutique en ligne, le moyen le plus simple de réduire les frictions liées aux formulaires est de définir le paiement sans connexion par défaut. N'obligez pas les utilisateurs à créer un compte avant d'effectuer un achat. L'absence de paiement sans connexion est l'une des principales raisons de l'abandon de panier.

Raisons de l'abandon du panier lors du paiement.
Source : baymard.com/checkout-usability

Vous pouvez proposer la création d'un compte après le paiement. À ce stade, vous disposez déjà de la plupart des données dont vous avez besoin pour configurer un compte. La création du compte devrait donc être simple et rapide pour l'utilisateur.

Afficher la progression du paiement

Vous pouvez rendre votre processus de paiement moins complexe en affichant la progression et en indiquant clairement ce qu'il faut faire ensuite. La vidéo suivante montre comment le marchand britannique johnlewis.com y parvient.

Afficher la progression du règlement

Vous devez maintenir l'élan ! Pour chaque étape du paiement, utilisez des titres de page et des valeurs de bouton descriptives qui indiquent clairement ce qu'il faut faire maintenant et quelle est l'étape suivante du paiement.

Donnez aux boutons de formulaire des noms explicites qui indiquent l'étape suivante.

Utilisez l'attribut enterkeyhint sur les entrées de formulaire pour définir le libellé de la touche Entrée du clavier mobile. Par exemple, utilisez enterkeyhint="previous" et enterkeyhint="next" dans un formulaire multipage, enterkeyhint="done" pour la saisie finale dans le formulaire et enterkeyhint="search" pour une saisie de recherche.

Deux captures d'écran d'un formulaire d'adresse sur Android montrant comment l'attribut d'entrée enterkeyhint modifie l'icône du bouton de la touche Entrée.
Boutons de la touche Entrée sur Android : "Suivant" et "OK".

L'attribut enterkeyhint est compatible avec Android et iOS. Pour en savoir plus, consultez la présentation d'enterkeyhint.

Permettez aux utilisateurs de naviguer facilement entre les différentes étapes du processus de paiement pour qu'ils puissent modifier leur commande, même à la dernière étape. Affichez tous les détails de la commande, et pas seulement un résumé limité. Permettez aux utilisateurs d'ajuster facilement les quantités d'articles sur la page de paiement. Lors du paiement, votre priorité est d'éviter d'interrompre la progression vers la conversion.

Effacer les défauts

Limitez les points de sortie potentiels en supprimant les éléments visuels superflus et les distractions, comme les promotions de produits. De nombreux marchands qui réussissent suppriment même la navigation et la recherche de la page de paiement.

Deux captures d'écran sur mobile montrant la progression du paiement sur johnlewis.com. La recherche, la navigation et les autres distractions sont supprimées.
La recherche, la navigation et les autres distractions sont supprimées pour le paiement.

Restez concentré sur le parcours. Ce n'est pas le moment de tenter les utilisateurs de faire autre chose !

Page de paiement sur mobile affichant une promotion distrayante pour des AUTOCOLLANTS SANS FRAIS.
Ne distrayez pas les clients lorsqu'ils finalisent leur achat.

Pour les utilisateurs connus, vous pouvez simplifier encore plus le processus de paiement en masquant les données qu'ils n'ont pas besoin de voir. Par exemple, affichez l'adresse de livraison en texte brut (pas dans un formulaire) et permettez aux utilisateurs de la modifier en suivant un lien.

Section &quot;Vérifier la commande&quot; d'une page de paiement, affichant du texte brut, avec des liens pour modifier l'adresse de livraison, le mode de paiement et l'adresse de facturation, qui ne sont pas affichés.
Masquez les données que les clients n'ont pas besoin de voir.

Faciliter la saisie du nom et de l'adresse

Ne demandez que les données dont vous avez besoin

Avant de commencer à coder vos formulaires de nom et d'adresse, assurez-vous de bien comprendre les données requises. Ne demandez pas de données dont vous n'avez pas besoin. Le moyen le plus simple de réduire la complexité d'un formulaire consiste à supprimer les champs inutiles. Cela permet également de protéger la confidentialité des clients, et de réduire les coûts et la responsabilité liés aux données backend.

Utiliser un seul champ de saisie pour le nom

Permettez à vos utilisateurs de saisir leur nom dans un seul champ, sauf si vous avez une bonne raison de stocker séparément les prénoms, les noms de famille, les titres honorifiques ou d'autres parties du nom. L'utilisation d'un seul champ de saisie pour le nom simplifie les formulaires, permet le copier-coller et facilite la saisie automatique.

En particulier, sauf si vous avez une bonne raison de ne pas le faire, ne vous embêtez pas à ajouter une entrée distincte pour un préfixe ou un titre (comme Mme, Dr ou Lord). Les utilisateurs peuvent saisir cette information avec leur nom s'ils le souhaitent. De plus, la saisie semi-automatique honorific-prefix ne fonctionne actuellement pas dans la plupart des navigateurs. Par conséquent, l'ajout d'un champ pour le préfixe ou le titre du nom interrompt l'expérience de saisie automatique du formulaire d'adresse pour la plupart des utilisateurs.

Activer la saisie automatique du nom

Utilisez name pour un nom complet :

<input autocomplete="name" ...>

Si vous avez une bonne raison de séparer les parties du nom, veillez à utiliser les valeurs de saisie semi-automatique appropriées :

  • honorific-prefix
  • given-name
  • nickname
  • additional-name-initial
  • additional-name
  • family-name
  • honorific-suffix

Autoriser les noms internationaux

Vous pouvez valider les entrées de nom ou limiter les caractères autorisés pour les données de nom. Toutefois, vous devez être aussi peu restrictif que possible avec les alphabets. Il est impoli de dire à quelqu'un que son nom n'est pas valide.

Pour la validation, évitez d'utiliser des expressions régulières qui ne correspondent qu'aux caractères latins. "Latin uniquement" exclut les utilisateurs dont le nom ou l'adresse incluent des caractères qui ne figurent pas dans l'alphabet latin. Autorisez plutôt la correspondance des lettres Unicode et assurez-vous que votre backend accepte Unicode de manière sécurisée, à la fois en entrée et en sortie. Unicode dans les expressions régulières est bien pris en charge par les navigateurs récents.

À éviter
<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>
À faire
<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>
Correspondance des lettres Unicode par rapport à la correspondance des lettres latines uniquement.

Autoriser différents formats d'adresse

Lorsque vous concevez un formulaire d'adresse, gardez à l'esprit la variété déconcertante des formats d'adresse, même au sein d'un même pays. Veillez à ne pas faire d'hypothèses sur les adresses "normales". (Consultez UK Address Oddities! si vous n'êtes pas convaincu.)

Rendre les formulaires d'adresse flexibles

Ne forcez pas les utilisateurs à essayer de faire tenir leur adresse dans des champs de formulaire qui ne sont pas adaptés.

Par exemple, n'exigez pas un numéro de maison et un nom de rue dans des champs distincts, car de nombreuses adresses n'utilisent pas ce format, et des données incomplètes peuvent empêcher la saisie automatique du navigateur.

Soyez particulièrement prudent avec les champs d'adresse required. Par exemple, les adresses des grandes villes du Royaume-Uni n'incluent pas de comté, mais de nombreux sites obligent toujours les utilisateurs à en saisir un.

L'utilisation de deux lignes d'adresse flexibles peut convenir à différents formats d'adresse.

<input autocomplete="address-line1" id="address-line1" ...>
<input autocomplete="address-line2" id="address-line2" ...>

Ajoutez des libellés à mettre en correspondance :

<label for="address-line1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line1" id="address-line1" ...>

<label for="address-line2">
Address line 2 (optional)
</label>
<input autocomplete="address-line2" id="address-line2" ...>

Envisagez d'utiliser une seule zone de texte pour l'adresse

L'option la plus flexible pour les adresses consiste à fournir un seul textarea.

L'approche textarea s'adapte à tous les formats d'adresse et est idéale pour le copier-coller. Toutefois, n'oubliez pas qu'elle peut ne pas répondre à vos exigences en matière de données et que les utilisateurs peuvent ne pas bénéficier de la saisie automatique s'ils n'ont utilisé auparavant que des formulaires avec address-line1 et address-line2.

Pour une zone de texte, utilisez street-address comme valeur de saisie semi-automatique.

Voici un exemple de formulaire qui illustre l'utilisation d'un seul textarea pour l'adresse :

Internationaliser et localiser vos formulaires d'adresse

Il est particulièrement important que les formulaires d'adresse tiennent compte de l'internationalisation et de la localisation, en fonction de l'emplacement de vos utilisateurs.

Sachez que la dénomination des parties d'adresse varie, tout comme les formats d'adresse, même au sein d'une même langue.

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

Il peut être irritant ou déroutant de voir un formulaire qui ne correspond pas à votre adresse ou qui n'utilise pas les mots que vous attendez.

Il peut être nécessaire de personnaliser les formulaires d'adresse pour plusieurs paramètres régionaux sur votre site, mais l'utilisation de techniques visant à maximiser la flexibilité des formulaires (comme décrit ci-dessus) peut suffire. Si vous ne localisez pas vos formulaires d'adresse, assurez-vous de comprendre les priorités clés pour gérer différents formats d'adresse :

  • Évitez d'être trop précis sur les parties de l'adresse, par exemple en insistant sur le nom de la rue ou le numéro de la maison.
  • Dans la mesure du possible, évitez de définir des champs sur required. Par exemple, les adresses de nombreux pays n'ont pas de code postal, et les adresses rurales peuvent ne pas avoir de nom de rue ou de route.
  • Utilisez des noms inclusifs : "Pays/Région" au lieu de "Pays", "Code postal" au lieu de "ZIP".

Restez flexible ! L'exemple de formulaire d'adresse simple ci-dessus peut être adapté pour fonctionner "assez bien" dans de nombreux paramètres régionaux.

Évitez d'utiliser la recherche d'adresse par code postal

Certains sites Web utilisent un service pour rechercher des adresses en fonction du code postal. Cela peut être judicieux dans certains cas d'utilisation, mais vous devez être conscient des inconvénients potentiels.

La suggestion d'adresse par code postal ne fonctionne pas pour tous les pays. Dans certaines régions, les codes postaux peuvent inclure un grand nombre d'adresses potentielles.

Les codes postaux peuvent inclure de nombreuses adresses.

Il est difficile pour les utilisateurs de choisir parmi une longue liste d'adresses, en particulier sur mobile s'ils sont pressés ou stressés. Il peut être plus facile et moins sujet aux erreurs de permettre aux utilisateurs de profiter de la saisie automatique et de saisir leur adresse complète en un seul clic ou appui.

Un seul champ de saisie du nom permet de saisir l'adresse d'un simple geste (un clic).

Simplifier les formulaires de paiement

Les formulaires de paiement sont l'élément le plus important du processus de paiement. Une mauvaise conception du formulaire de paiement est une cause fréquente d'abandon du panier. Le diable se cache dans les détails : de petits problèmes peuvent inciter les utilisateurs à abandonner un achat, en particulier sur mobile. Votre tâche consiste à concevoir des formulaires pour que les utilisateurs puissent saisir des données le plus facilement possible.

Aidez les utilisateurs à éviter de saisir à nouveau leurs données de paiement

Veillez à ajouter les valeurs autocomplete appropriées dans les formulaires de carte de paiement, y compris le numéro de carte de paiement, le nom sur la carte, la date d'expiration et le code de sécurité :

  • cc-number
  • cc-name
  • cc-exp, ou cc-exp-month et cc-exp-year pour des champs distincts
  • cc-csc

Les navigateurs peuvent ainsi aider les utilisateurs en stockant de manière sécurisée les informations de leur carte de paiement et en saisissant correctement les données des formulaires. Sans la saisie semi-automatique, les utilisateurs sont plus susceptibles de conserver une trace physique des informations de leur carte de paiement ou de stocker ces données de manière non sécurisée sur leur appareil.

Évitez d'utiliser des éléments personnalisés pour les dates des cartes de paiement

S'ils ne sont pas correctement conçus, les éléments personnalisés peuvent interrompre le flux de paiement en interrompant la saisie automatique et ne fonctionneront pas sur les anciens navigateurs. Si toutes les autres informations de la carte de paiement sont disponibles via la saisie semi-automatique, mais qu'un utilisateur est obligé de trouver sa carte de paiement physique pour rechercher une date d'expiration, car la saisie automatique n'a pas fonctionné pour un élément personnalisé, vous risquez de perdre une vente. Envisagez plutôt d'utiliser des éléments HTML standards et de les styliser en conséquence.

Formulaire de paiement affichant des éléments personnalisés pour la date d'expiration de la carte qui interrompent la saisie automatique.
La saisie semi-automatique a rempli tous les champs, sauf la date d'expiration.

Utiliser une seule entrée pour les cartes de paiement et les numéros de téléphone

Pour les numéros de carte de paiement et de téléphone, utilisez un seul champ de saisie : ne divisez pas le numéro en plusieurs parties. Cela permet aux utilisateurs de saisir des données plus facilement, simplifie la validation et permet aux navigateurs de saisir automatiquement les champs. Envisagez de faire de même pour d'autres données numériques, telles que les codes PIN et les codes bancaires.

Formulaire de paiement affichant un champ de carte de crédit divisé en quatre éléments de saisie.
N'utilisez pas plusieurs champs de saisie pour un numéro de carte de crédit.

Valider soigneusement

Vous devez valider la saisie des données en temps réel et avant l'envoi du formulaire. Pour ce faire, vous pouvez ajouter un attribut pattern à une entrée de carte de paiement. Si l'utilisateur tente d'envoyer le formulaire de paiement avec une valeur non valide, le navigateur affiche un message d'avertissement et met l'accent sur la saisie. Aucun code JavaScript n'est requis.

Toutefois, votre expression régulière pattern doit être suffisamment flexible pour gérer les différentes longueurs de numéros de cartes de paiement : de 14 chiffres (ou éventuellement moins) à 20 (ou plus). Pour en savoir plus sur la structuration des numéros de carte de paiement, consultez LDAPwiki.

Autorisez les utilisateurs à inclure des espaces lorsqu'ils saisissent un nouveau numéro de carte de paiement, car c'est ainsi que les numéros sont affichés sur les cartes physiques. Cette approche est plus conviviale pour l'utilisateur (vous n'aurez pas à lui dire qu'il a fait une erreur), moins susceptible d'interrompre le flux de conversion et il est facile de supprimer les espaces dans les nombres avant le traitement.

Tester sur différents appareils, plates-formes, navigateurs et versions

Il est particulièrement important de tester les formulaires d'adresse et de paiement sur les plates-formes les plus courantes pour vos utilisateurs, car la fonctionnalité et l'apparence des éléments de formulaire peuvent varier, et les différences de taille de la fenêtre d'affichage peuvent entraîner un positionnement problématique. BrowserStack permet de tester sans frais des projets Open Source sur différents appareils et navigateurs.

Un formulaire de paiement sur iPhone 7 et 11. Le bouton &quot;Finaliser le paiement&quot; s'affiche sur l'iPhone 11, mais pas sur l'iPhone 7
La même page sur iPhone 7 et iPhone 11.
Réduisez la marge intérieure pour les fenêtres d'affichage mobiles plus petites afin de vous assurer que le bouton Finaliser le paiement n'est pas masqué.

Implémenter l'analyse et le RUM

Tester l'usabilité et les performances localement peut être utile, mais vous avez besoin de données réelles pour bien comprendre comment les utilisateurs interagissent avec vos formulaires de paiement et d'adresse.

Pour cela, vous avez besoin d'analyses et d'une surveillance des utilisateurs réels (RUM, Real User Monitoring), c'est-à-dire de données sur l'expérience des utilisateurs réels, comme le temps de chargement des pages de paiement ou le temps nécessaire pour finaliser un paiement :

  • Analyse des pages : pages vues, taux de rebond et sorties pour chaque page contenant un formulaire.
  • Analyse des interactions : les entonnoirs d'objectifs et les événements indiquent à quel moment les utilisateurs abandonnent votre processus de paiement et quelles actions ils effectuent lorsqu'ils interagissent avec vos formulaires.
  • Performances du site Web : les métriques axées sur l'utilisateur peuvent vous indiquer si vos pages de paiement sont lentes à charger et, le cas échéant, quelle en est la cause.

L'analyse des pages, l'analyse des interactions et la mesure des performances des utilisateurs réels deviennent particulièrement utiles lorsqu'elles sont combinées aux journaux de serveur, aux données de conversion et aux tests A/B. Vous pouvez ainsi répondre à des questions telles que "Les codes de réduction augmentent-ils les revenus ?" ou "Une modification de la mise en page d'un formulaire améliore-t-elle les conversions ?".

Cela vous donne une base solide pour prioriser les efforts, apporter des modifications et récompenser la réussite.

Continuer à apprendre

Photo de @rupixen sur Unsplash.