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 le plus rapidement et facilement possible.

Sam Dutton

Des formulaires bien conçus aident les utilisateurs et augmentent les taux de conversion. Une correction mineure peut faire toute la différence !

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

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

Checklist

Utilisez un code HTML pertinent

Utilisez les éléments et les attributs créés pour la tâche:

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

Ceux-ci activent des fonctionnalités intégrées au navigateur, améliorent l'accessibilité et ajoutent du sens à votre balisage.

Utilisez les éléments HTML comme prévu.

Placer le formulaire dans un <form>

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

Ne procédez pas de cette façon !

Un <form> HTML vous donne accès à un ensemble puissant de fonctionnalités intégrées dans tous les navigateurs modernes et peut rendre votre site accessible aux lecteurs d'écran et autres appareils d'assistance. Un <form> facilite également la création de fonctionnalités de base pour les anciens navigateurs dont la compatibilité avec JavaScript est limitée, et pour permettre l'envoi de formulaires en cas de glitch dans votre code, ainsi que pour le petit nombre d'utilisateurs qui désactivent JavaScript.

Si vous utilisez plusieurs composants de page pour les entrées utilisateur, veillez à placer chacun dans son propre élément <form>. Par exemple, si la recherche et l'inscription figurent sur la même page, ajoutez chacune son propre <form>.

Ajouter un libellé aux éléments à l'aide de <label>

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

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

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

Utilisez une étiquette unique pour une seule entrée: n'essayez pas d'étiqueter plusieurs entrées avec une seule étiquette. Cela fonctionne mieux pour les navigateurs et pour les lecteurs d'écran. Lorsque l'utilisateur appuie ou clique sur un libellé, le curseur se place sur l'entrée à laquelle il est associé. Les lecteurs d'écran énoncent 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 pas de div ni d'autre élément aléatoire agissant comme un bouton. Les éléments de bouton offrent un comportement accessible, une fonctionnalité intégrée d'envoi de formulaires et peuvent être stylisés facilement.

Attribuez à chaque bouton d'envoi de formulaire une valeur indiquant sa fonction. Pour chaque étape du processus de paiement, utilisez une incitation à l'action descriptive qui montre la progression et indique clairement l'étape suivante. Par exemple, étiquetez le bouton d'envoi sur le formulaire d'adresse de livraison Procéder au paiement plutôt que Continuer ou Enregistrer.

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

En revanche, ne désactivez pas un bouton "Envoyer" qui attend une entrée utilisateur complète et valide. Par exemple, ne laissez pas un bouton Enregistrer l'adresse désactivé, car quelque chose est manquant ou non valide. Cela n'aide pas l'utilisateur : il peut continuer à appuyer ou à cliquer sur le bouton et supposer qu'il est cassé. Si les utilisateurs tentent d'envoyer un formulaire contenant des données non valides, expliquez-leur le problème et les mesures à prendre pour le résoudre. C'est particulièrement important sur mobile, où la saisie de données est plus difficile et où des données de formulaire manquantes ou non valides peuvent ne pas être visibles sur l'écran de l'utilisateur lorsqu'il tente d'envoyer un formulaire.

Tirez le meilleur parti des attributs HTML

Faciliter la saisie des données pour les utilisateurs

Utilisez l'attribut type d'entrée approprié pour fournir le clavier droit 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&#39;écran de téléphones Android, montrant un clavier permettant de saisir une adresse e-mail (en utilisant type=email) et un numéro de téléphone (avec type=tel).
Claviers adaptés aux e-mails et au téléphone.

Pour les dates, évitez d'utiliser des éléments select personnalisés. Elles perturbent l'expérience de saisie automatique si elles ne sont pas correctement implémentées 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 que select, car la saisie manuelle de chiffres peut être plus facile et moins sujette aux erreurs que de sélectionner une longue liste déroulante, en particulier sur mobile. Utilisez inputmode="numeric" pour vous assurer que le clavier approprié est utilisé sur mobile, et ajoutez des indications de validation et de mise en forme avec du texte ou un espace réservé afin de vous assurer que l'utilisateur saisit les données au format approprié.

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

L'utilisation des 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. Ce point est particulièrement important sur mobile et essentiel pour éviter des taux d'abandon élevés. La saisie semi-automatique offre également de nombreux avantages en termes d'accessibilité.

Si une valeur de saisie semi-automatique appropriée est disponible pour un champ de formulaire, utilisez-la. Le site MDN web docs propose une liste complète de valeurs ainsi que des explications sur la façon de les utiliser correctement.

Valeurs stables

Adresse de facturation

Par défaut, l'adresse de facturation doit être 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) au lieu d'afficher l'adresse de facturation dans un formulaire.

Exemple de page de paiement affichant un lien pour modifier l&#39;adresse de facturation
Ajoutez un lien pour vérifier la facturation.

Utilisez les 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 besoin de saisir des données plusieurs fois. Ajoutez un préfixe aux attributs de saisie semi-automatique si vous disposez de différentes valeurs pour les entrées portant le même nom dans différentes sections.

<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

Aidez les utilisateurs à saisir les bonnes données

Essayez d'éviter de « détourner » les clients parce qu'ils « ont fait quelque chose de mal ». Aidez plutôt les utilisateurs à remplir les formulaires plus rapidement et plus facilement en les aidant à résoudre les problèmes au fur et à mesure qu'ils surviennent. Tout au long du processus de paiement, les clients essaient de verser de l'argent à votre entreprise pour un produit ou un service. Votre travail consiste à les aider, et non à les punir.

Vous pouvez ajouter des attributs de contrainte pour former des éléments afin de spécifier des valeurs acceptables, y compris min, max et pattern. L'état de validité de l'élément est défini automatiquement selon que sa valeur est valide, de même que les pseudo-classes CSS :valid et :invalid, qui peuvent être utilisées pour appliquer un style à des éléments avec des valeurs valides ou non.

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

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

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

Lors de l'envoi d'un formulaire, les navigateurs sélectionnent automatiquement les champs qui comportent des valeurs obligatoires qui posent problème ou qui sont manquantes. JavaScript n'est pas nécessaire.

Capture d&#39;écran d&#39;un formulaire de connexion dans Chrome sur un ordinateur, montrant une invite du navigateur et le focus sur une valeur d&#39;adresse e-mail non valide.
Validation intégrée de base par le navigateur

Valider de façon intégrée et fournir des commentaires à l'utilisateur lorsqu'il saisit des données, au lieu de fournir une liste d'erreurs lorsqu'il clique sur le bouton "Envoyer". Si vous devez valider les données sur votre serveur après l'envoi du formulaire, répertoriez tous les problèmes détectés et mettez en évidence tous les champs de formulaire contenant des valeurs non valides. Affichez également un message intégré à côté de chaque champ problématique expliquant les corrections à apporter. Recherchez les erreurs courantes dans les journaux de serveur et les données analytiques. Vous devrez peut-être remanier votre formulaire.

Vous devez également utiliser JavaScript pour effectuer une validation plus solide lorsque les utilisateurs saisissent des données et envoient un formulaire. Utilisez l'API Constraint Validation (qui est largement compatible) pour ajouter une validation personnalisée à l'aide de l'interface utilisateur intégrée du navigateur afin de définir le focus et d'afficher des invites.

Pour en savoir plus, consultez Utiliser JavaScript pour une validation en temps réel plus complexe.

Aider les utilisateurs à éviter de manquer des données obligatoires

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

Lorsqu'un formulaire est envoyé, les navigateurs modernes envoient automatiquement des invites et définissent le focus sur les champs required avec des données manquantes. Vous pouvez utiliser la pseudo-classe :required pour mettre en évidence les champs obligatoires. JavaScript n'est pas nécessaire.

Ajoutez un astérisque au libellé de chaque champ obligatoire, puis ajoutez une note au début du formulaire pour expliquer sa signification.

Simplifiez le processus de paiement

Tenez compte de la lacune du commerce sur mobile !

Imaginez que vos utilisateurs aient un budget de fatigue. Utilisez-le, vos utilisateurs partiront.

Vous devez réduire les frictions et rester concentré, en particulier sur mobile. De nombreux sites enregistrent plus de trafic sur mobile, mais plus de conversions sur ordinateur. Ce phénomène est connu sous le nom d'écart pour le commerce sur mobile. Même si les clients préfèrent tout simplement effectuer un achat sur ordinateur, les taux de conversion sur mobile plus faibles sont également dus à une mauvaise expérience utilisateur. Votre rôle consiste à minimiser les conversions perdues sur mobile et à maximiser les conversions sur ordinateur. Des études ont montré qu'il est possible d'améliorer l'expérience utilisateur avec les formulaires mobiles.

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

Définir le paiement sans connexion comme option par défaut

Pour une boutique en ligne, le moyen le plus simple de simplifier le processus consiste à définir le paiement sans connexion comme option par défaut. N'obligez pas les utilisateurs à créer un compte avant d'effectuer un achat. Ne pas autoriser le paiement sans connexion est l'un des motifs principaux d'abandon du panier.

Motifs d&#39;abandon du panier au moment du paiement.
Sur baymard.com/checkout-usability

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

Afficher la progression du règlement

Vous pouvez rendre votre processus de paiement moins complexe en montrant la progression et en indiquant clairement ce qui doit être fait ensuite. La vidéo ci-dessous montre comment le marchand britannique johnlewis.com y parvient.

Afficher la progression du règlement

Vous devez maintenir votre dynamique ! Pour chaque étape du processus de paiement, utilisez des en-têtes de page et des valeurs de bouton descriptives qui indiquent clairement ce qui doit être fait maintenant et quelle est l'étape suivante du règlement.

Attribuez des noms explicites aux boutons du formulaire pour indiquer la suite.

Utilisez l'attribut enterkeyhint sur les entrées du 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 de plusieurs pages, enterkeyhint="done" pour la dernière entrée du formulaire et enterkeyhint="search" pour une entrée de recherche.

Deux captures d&#39;écran d&#39;un formulaire d&#39;adresse sur Android montrant comment l&#39;attribut d&#39;entrée enterkeyhint modifie l&#39;icône de la touche Entrée.
Saisissez les boutons clés sur Android: "next" (suivant) et "done" (terminé).

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

Permettez aux utilisateurs d'aller et venir dans le processus de paiement afin d'ajuster facilement leur commande, même lorsqu'ils se trouvent à la dernière étape du paiement. Affichez tous les détails de la commande, pas seulement un résumé limité. Permettez aux utilisateurs d'ajuster facilement les quantités des articles depuis la page de paiement. Votre priorité lors du règlement est d'éviter d'interrompre la progression vers la conversion.

Effacez les défauts

Limitez les points de sortie potentiels en supprimant l'encombrement visuel et les distractions telles que les promotions. De nombreux marchands performants suppriment même les fonctionnalités de navigation et de recherche du processus de paiement.

Deux captures d&#39;écran sur mobile montrant la progression via le règlement sur johnlewis.com. La recherche, la navigation et les autres éléments indésirables sont supprimés.
Les fonctionnalités de recherche, de navigation et autres éléments indésirables ont été supprimés lors du règlement.

Concentrez-vous sur votre parcours. Ce n'est pas le moment de inciter les utilisateurs à faire autre chose !

Capture d&#39;écran d&#39;une page de paiement sur mobile montrant une promotion gênante pour les autocollants SANS FRAIS.
N'empêchez pas les clients de finaliser leur achat.

Pour les utilisateurs connus, vous pouvez encore simplifier 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 (et non dans un formulaire) et autorisez les utilisateurs à la modifier via un lien.

Capture d&#39;écran de la section &quot;Vérifier la commande&quot; de la page de paiement, avec texte brut et liens permettant de modifier l&#39;adresse de livraison, le mode de paiement et l&#39;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 quelles données sont requises. Ne demandez pas des données dont vous n’avez pas besoin ! Le moyen le plus simple de réduire la complexité des formulaires consiste à supprimer les champs inutiles. Cela est également bénéfique pour la confidentialité des clients et peut réduire les coûts et la responsabilité liés aux données backend.

Utiliser un seul nom

Autorisez les utilisateurs à saisir leur nom en une seule entrée, sauf si vous avez une bonne raison de stocker séparément les prénoms, les noms de famille, les distinctions ou d'autres éléments de nom. L'utilisation d'un seul nom simplifie les formulaires, permet le copier-coller et simplifie la saisie automatique.

En particulier, à moins que vous ayez de bonnes raisons de ne pas le faire, n'ajoutez pas d'entrée distincte pour un préfixe ou un titre (comme "Mme", "Dr" ou "Lord"). Les utilisateurs peuvent le saisir 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 nuira à l'expérience de saisie automatique du formulaire d'adresse pour la plupart des utilisateurs.

Activer la saisie automatique des noms

Utilisez name pour un nom complet:

<input autocomplete="name" ...>

Si vous avez vraiment une bonne raison de diviser 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 noms que vous avez saisis ou limiter le nombre de caractères autorisés dans les données de nom. Cependant, vous devez utiliser les alphabets de manière aussi peu restrictive que possible. Il est désagréable d'entendre dire que votre nom est "non valide" !

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

À é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 entre les lettres Unicode et les lettres latines uniquement.

Ils permettent d'utiliser différents formats d'adresse.

Lorsque vous créez un formulaire d'adresse, tenez compte de l'énorme variété de formats d'adresse, même dans un seul pays. Veillez à ne pas faire de suppositions sur les adresses "normales". (Jetez un coup d'œil à UK Address Oddities! si vous n'êtes pas convaincu.

Rendre les formulaires d'adresse flexibles

N'obligez pas les utilisateurs à compresser leur adresse dans des champs de formulaire qui ne conviennent pas.

Par exemple, n'exigez pas d'inclure un numéro de rue et un nom de rue dans des entrées distinctes, car de nombreuses adresses n'utilisent pas ce format et des données incomplètes peuvent perturber 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'ont pas de comté, mais de nombreux sites obligent les utilisateurs à en saisir un.

L'utilisation de deux lignes d'adresse flexibles peut s'avérer suffisante pour une variété de formats d'adresse.

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

Ajouter des libellés à faire correspondre:

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

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

Vous pouvez essayer en remixant et en modifiant la démo intégrée ci-dessous.

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 à n'importe quel format d'adresse et est idéale pour le couper-coller, mais gardez à l'esprit qu'elle ne répond peut-être pas à vos exigences en termes de données. De plus, les utilisateurs risquent de passer à côté de la saisie automatique s'ils n'utilisaient 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 illustrant l'utilisation d'un seul textarea pour l'adresse:

Internationalisez et localisez vos formulaires d'adresse

Il est particulièrement important d'envisager l'internationalisation et la localisation des formulaires d'adresse en fonction de la localisation de vos utilisateurs.

Sachez que les noms des parties d'adresse varient selon les formats d'adresse, même dans une même langue.

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

Il peut être agaçant ou déroutant de se voir présenter un formulaire qui ne correspond pas à votre adresse ou qui n'utilise pas les mots que vous attendiez.

Il peut être nécessaire de personnaliser les formulaires d'adresse pour plusieurs paramètres régionaux sur votre site. Toutefois, l'utilisation de techniques permettant d'optimiser la flexibilité des formulaires (comme décrit ci-dessus) peut être appropriée. Si vous ne localisez pas vos formulaires d'adresse, assurez-vous de bien comprendre les principales priorités à respecter lorsque vous utilisez différents formats d'adresse : * Évitez d'être trop précis dans les éléments d'adresse, par exemple en insistant sur le nom de la rue ou le numéro de rue. * Dans la mesure du possible, évitez de définir des champs de type required. Par exemple, dans de nombreux pays, les adresses n'ont pas de code postal, et les adresses rurales n'ont pas forcément de nom de rue ou de route. * Utilisez des noms inclusifs: "Pays/Région" et non "Pays", "Code postal" et non "Code postal".

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

Évitez de rechercher une adresse associée à un code postal.

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

Les suggestions d'adresses par code postal ne fonctionnent pas dans 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 faire leur choix dans une longue liste d'adresses, en particulier sur les mobiles s'ils sont pressés ou stressés. Il est 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 une seule pression.

La saisie d'un seul nom permet de saisir une adresse en un clic.

Simplifier les modes de paiement

Les formulaires de paiement constituent la partie la plus importante du processus de règlement. Une mauvaise conception du formulaire de paiement est une cause courante d'abandon de panier. Le diable se cache dans les détails: de petits bugs peuvent inciter les utilisateurs à abandonner un achat, en particulier sur mobile. Votre travail consiste à concevoir des formulaires pour permettre aux utilisateurs de saisir des données aussi facilement que possible.

Éviter aux utilisateurs 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 la carte de paiement, le nom de la carte, ainsi que le mois et l'année d'expiration:

  • cc-number
  • cc-name
  • cc-exp-month
  • cc-exp-year

Les navigateurs peuvent ainsi aider les utilisateurs en stockant de manière sécurisée les informations relatives aux cartes de paiement et en saisissant correctement les données de formulaire. Sans la saisie semi-automatique, les utilisateurs peuvent être plus susceptibles de conserver un enregistrement physique des informations de la carte de paiement ou de stocker les données de la carte de paiement de manière non sécurisée sur leur appareil.

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

S'ils ne sont pas conçus correctement, les éléments personnalisés peuvent interrompre le flux de paiement en interrompant la saisie automatique et ne fonctionnent pas sur les anciens navigateurs. Si toutes les autres informations de la carte de paiement sont disponibles dans 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. Utilisez plutôt des éléments HTML standards et appliquez-leur un style approprié.

Capture d&#39;écran d&#39;un formulaire de paiement montrant des éléments personnalisés pour la date d&#39;expiration d&#39;une 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 la carte de paiement et les numéros de téléphone

Pour les numéros de carte de paiement et les numéros de téléphone, utilisez une seule entrée: ne les divisez pas en plusieurs parties. Les utilisateurs peuvent ainsi saisir des données plus facilement, la validation est simplifiée et les navigateurs peuvent utiliser la saisie automatique. Envisagez de faire de même pour d'autres données numériques, comme le code PIN et le code banque.

Capture d&#39;écran d&#39;un formulaire de paiement montrant un champ de carte de crédit divisé en quatre éléments de saisie.
N'utilisez pas plusieurs entrées pour un numéro de carte de crédit.

Valider avec soin

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 active la saisie. JavaScript n'est pas nécessaire.

Cependant, votre expression régulière pattern doit être suffisamment flexible pour gérer la plage de longueurs des numéros de carte de paiement: de 14 chiffres (ou 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 s'affichent sur les cartes physiques. Cette méthode est plus conviviale pour l'utilisateur (vous n'aurez pas à lui dire qu'il a fait quelque chose de mal), moins susceptible d'interrompre le flux de conversion et il est facile de supprimer les espaces dans les nombres avant le traitement.

Effectuez des tests sur plusieurs appareils, plates-formes, navigateurs et versions

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

Captures d&#39;écran d&#39;un mode de paiement, payment-form.glitch.me, sur iPhone 7 et 11. Le bouton &quot;Terminer le paiement&quot; s&#39;affiche sur l&#39;iPhone 11, mais pas 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 Terminer le paiement n'est pas masqué.

Implémenter l'analyse et le RUM

Tester la facilité d'utilisation et les performances en local peut être utile, mais vous avez besoin de données réelles pour bien comprendre comment les utilisateurs utilisent vos formulaires de paiement et d'adresse.

Pour cela, vous avez besoin d'analyses et de la surveillance des utilisateurs réels, c'est-à-dire des données concernant l'expérience des utilisateurs réels, telles que le temps de chargement des pages de paiement ou le délai de paiement:

  • Analyse de page: pages vues, taux de rebond et sorties pour chaque page comportant un formulaire.
  • Analyse des interactions: les entonnoirs de conversion vers l'objectif et les événements indiquent où les utilisateurs abandonnent votre processus de paiement et les actions qu'ils effectuent lorsqu'ils interagissent avec vos formulaires.
  • Performances du site Web: les métriques axées sur l'utilisateur peuvent vous indiquer si le chargement de vos pages de paiement est lent et, le cas échéant, quelle en est la cause.

L'analyse des pages, l'analyse des interactions et la mesure des performances réelles des utilisateurs sont particulièrement utiles lorsqu'elles sont associées aux journaux de serveur, aux données de conversion et aux tests A/B. Elles vous permettent de savoir si les codes de réduction augmentent les revenus ou si une modification de la mise en page du formulaire améliore les conversions.

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

Poursuivre votre apprentissage

Photo de @rupixen sur Unsplash.