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. Un petit correctif peut faire toute la différence.

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

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

Checklist

Utiliser 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

Ils permettent d'activer les fonctionnalités intégrées du navigateur, d'améliorer l'accessibilité et d'ajouter du sens à votre balisage.

Utilisez les éléments HTML comme prévu

Placez votre formulaire dans un <form>.

Vous pourriez être tenté de ne pas vous soucier d'encapsuler vos éléments <input> dans un <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 permet d'accéder à un ensemble puissant de fonctionnalités intégrées dans tous les navigateurs modernes. Il peut également 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 avec une compatibilité limitée avec JavaScript, et l'envoi de formulaires même en cas de problème avec votre code, ainsi que pour le petit nombre d'utilisateurs qui désactivent réellement JavaScript.

Si vous disposez de 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 recherche et une inscription sur la même page, placez chacune dans son propre <form>.

Utiliser <label> pour libeller des éléments

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

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

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

Utilisez un seul libellé pour une seule entrée : n'essayez pas d'étiqueter plusieurs entrées avec un seul libellé. Cette méthode fonctionne mieux pour les navigateurs et les lecteurs d'écran. Si vous appuyez ou cliquez sur un libellé, le focus est placé sur la saisie à laquelle il est associé. Les lecteurs d'écran annoncent le texte du libellé lorsque le libellé ou la saisie associée reçoit le focus.

Rendre les boutons utiles

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

Attribuez à chaque bouton de soumission de formulaire une valeur indiquant son action. Pour chaque étape du processus de paiement, utilisez un incitant à l'action descriptif qui indique la progression et rend l'étape suivante évidente. Par exemple, étiquetez le bouton d'envoi sur le formulaire de votre adresse de livraison Procéder au paiement au lieu de Continuer ou Enregistrer.

Envisagez de désactiver un bouton d'envoi une fois que l'utilisateur l'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 règlement et augmenter la charge sur le serveur.

En revanche, ne désactivez pas le bouton "Envoyer" qui attend une entrée utilisateur complète et valide. Par exemple, ne laissez pas un bouton Enregistrer l'adresse désactivé si quelque chose est manquant ou non valide. Cela n'aide pas l'utilisateur, qui peut continuer à appuyer ou à cliquer sur le bouton et supposer qu'il est défectueux. Au lieu de cela, si les utilisateurs tentent d'envoyer un formulaire avec des données non valides, expliquez-leur ce qui ne va pas et ce qu'ils doivent faire pour résoudre le problème. Cela est particulièrement important sur mobile, où la saisie de données est plus difficile et que les données de formulaire manquantes ou non valides peuvent ne pas être visibles à l'écran de l'utilisateur au moment où il tente d'envoyer un formulaire.

Exploiter tout le potentiel des attributs HTML

Faciliter la saisie de données par les utilisateurs

Utilisez l'attribut type de saisie 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&#39;écran de téléphones Android, montrant un clavier adapté à la saisie d&#39;une adresse e-mail (avec type=email) et d&#39;un numéro de téléphone (avec type=tel).
Claviers adaptés à la messagerie 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 perturbent l'expérience de saisie automatique et ne fonctionnent pas avec les anciens navigateurs. Pour les nombres tels que l'année de naissance, envisagez d'utiliser un élément input plutôt qu'un select, car la saisie manuelle des 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 est utilisé 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. Ce point est particulièrement important sur mobile et crucial pour éviter les taux élevés d'abandon de formulaire. 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, vous devez l'utiliser. Les documentations Web MDN contiennent une liste complète des valeurs et des explications sur leur utilisation correcte.

Valeurs stables

Adresse de facturation

Par défaut, définissez l'adresse de facturation sur l'adresse de livraison. Réduisez l'encombrement visuel en fournissant un lien permettant de 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 avec un lien permettant de modifier l&#39;adresse de facturation.
Ajoutez un lien permettant d'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-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

Aidez les utilisateurs à saisir les bonnes données

Évitez de "gronder" les clients parce qu'ils ont "fait quelque chose de mal". Aidez plutôt les utilisateurs à remplir des formulaires plus rapidement et plus facilement en les aidant à résoudre les problèmes au fur et à mesure. Tout au long du processus de paiement, les clients essaient de donner 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 aux éléments du formulaire pour 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 ou non, tout comme les pseudo-classes CSS :valid et :invalid, qui peuvent être utilisées pour appliquer un style aux é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 à des nombres uniquement, dans la plage spécifiée par min et max. Si vous essayez de saisir un nombre en dehors de la plage, la saisie sera définie comme étant dans 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 modernes effectuent également une validation de base pour les entrées de type email ou url.

Lors de l'envoi d'un formulaire, les navigateurs placent automatiquement le curseur sur les champs comportant des valeurs obligatoires problématiques ou manquantes. Pas besoin de JavaScript !

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

Validez en ligne et fournissez des commentaires à l'utilisateur lorsqu'il saisit des données, plutôt que de lui 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, répertoriez tous les problèmes détectés et mettez clairement en évidence tous les champs du formulaire contenant des valeurs non valides. Affichez également un message intégré à côté de chaque champ problématique expliquant les corrections à apporter. Vérifiez que les journaux du serveur et les données d'analyse ne comportent pas d'erreurs courantes. Vous devrez peut-être remanier votre formulaire.

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

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

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

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

Lorsqu'un formulaire est envoyé, les navigateurs modernes affichent automatiquement une invite et mettent le focus sur les champs required avec des données manquantes. Vous pouvez utiliser la pseudo-classe :required pour mettre en surbrillance les champs obligatoires. Aucun JavaScript requis !

Ajoutez un astérisque au libellé de chaque champ obligatoire et une note au début du formulaire pour expliquer ce que signifie l'astérisque.

Simplifiez le paiement

Attention à l'écart entre le commerce mobile et le commerce sur ordinateur !

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

Vous devez réduire les frictions et rester concentré, en particulier sur les mobiles. De nombreux sites génèrent plus de trafic sur mobile, mais plus de conversions sur ordinateur, un phénomène appelé écart du commerce sur mobile. Les clients peuvent simplement préférer effectuer un achat sur ordinateur, mais les taux de conversion sur mobile plus faibles sont également le résultat d'une mauvaise expérience utilisateur. Votre objectif est de minimiser les conversions perdues sur mobile et de maximiser les conversions sur ordinateur. Des études ont montré qu'il existe de nombreuses opportunités d'améliorer l'expérience utilisateur avec les formulaires sur mobile.

Surtout, les utilisateurs sont plus susceptibles d'abandonner les formulaires qui semblent longs, complexes et sans orientation. Cela est particulièrement vrai lorsque les utilisateurs utilisent un petit écran, sont distraits ou pressés. Demandez le moins de données possible.

Définir le paiement sans connexion comme paramètre par défaut

Pour une boutique en ligne, le moyen le plus simple de réduire les frictions liées aux formulaires consiste à définir le paiement sans connexion comme paramètre par défaut. Ne forcez pas les utilisateurs à créer un compte avant d'effectuer un achat. L'impossibilité de payer sans connexion est souvent citée comme une raison majeure d'abandon du panier.

Raisons de l&#39;abandon du panier au moment du règlement.
Source : baymard.com/checkout-usability

Vous pouvez proposer de créer 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 de compte devrait 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 le rythme. Pour chaque étape du paiement, utilisez des titres de page et des valeurs de bouton descriptifs qui indiquent clairement ce qui doit être fait maintenant et quelle est l'étape de paiement suivante.

Donnez aux boutons de formulaire des noms significatifs qui indiquent ce qui se passe ensuite.

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 de plusieurs pages, enterkeyhint="done" pour l'entrée finale 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 du bouton de touche Entrée.
Boutons de saisie sur Android : "Suivant" et "OK".

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

Permettez aux utilisateurs de revenir en arrière et d'avancer facilement dans le processus de paiement afin qu'ils puissent facilement ajuster leur commande, même lorsqu'ils sont à l'étape finale du paiement. Afficher tous les détails de la commande, et non un résumé limité. Offrez aux utilisateurs la possibilité d'ajuster facilement les quantités des articles sur la page de paiement. Lors du règlement, 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 encombrants et les distractions, comme les promotions de produits. De nombreux marchands performants vont même jusqu'à supprimer la navigation et la recherche du processus de paiement.

Deux captures d&#39;écran sur mobile montrant la progression du processus de paiement sur johnlewis.com La recherche, la navigation et les autres distractions sont supprimées.
Suppression des fonctionnalités de recherche, de navigation et autres éléments perturbateurs pour le paiement

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

Capture d&#39;écran de la page de paiement sur mobile montrant une promotion pour des AUTOCOLLANTS GRATUITS qui gêne la lecture.
N'empêchez pas les clients de finaliser 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 (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, montrant du texte brut, avec des liens permettant de modifier l&#39;adresse de livraison, le mode de paiement et l&#39;adresse de facturation, qui ne s&#39;affichent pas.
Masquer les données dont 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 comprendre quelles données sont requises. Ne demandez pas les données dont vous n'avez pas besoin ! Le moyen le plus simple de réduire la complexité d'un formulaire est de supprimer les champs inutiles. Cela est également bénéfique pour la confidentialité des clients et peut réduire les coûts et les responsabilités liés aux données de backend.

Utiliser une seule saisie de nom

Autorisez vos utilisateurs à saisir leur nom à l'aide d'une seule saisie, 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'une seule zone de saisie de nom simplifie les formulaires, permet de 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 un champ distinct pour un préfixe ou un titre (comme "Mme", "Dr" ou "Lord"). Les utilisateurs peuvent saisir ce nom 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, ajouter un champ pour le préfixe ou le titre du nom interrompra 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 séparer certaines 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 saisis par l'utilisateur 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 vous dire que votre nom est "non 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 font pas partie de l'alphabet latin. Autorisez plutôt la mise en correspondance des lettres Unicode et assurez-vous que votre backend est compatible avec Unicode de manière sécurisée à la fois en entrée et en sortie. Unicode dans les expressions régulières est bien compatible avec 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 des lettres Unicode par rapport à la correspondance des lettres latines uniquement.

Accepter différents formats d'adresse

Lorsque vous concevez un formulaire d'adresse, gardez à l'esprit la variété déroutante des formats d'adresse, même dans un même pays. Veillez à ne pas faire de suppositions sur les adresses "normales". (Jetez un œ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 trop grands.

Par exemple, n'insistez pas sur 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 perturber le remplissage automatique du navigateur.

Faites particulièrement attention aux champs d'adresse required. Par exemple, les adresses des grandes villes du Royaume-Uni ne comportent 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-line-1" id="address-line1" ...>
<input autocomplete="address-line-2" id="address-line2" ...>

Ajoutez des libellés pour 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 de remixer et d'éditer la démo intégrée ci-dessous.

Envisagez d'utiliser un seul champ de texte pour l'adresse

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

L'approche textarea convient à tous les formats d'adresse et est idéale pour le copier-coller. Toutefois, gardez à l'esprit qu'elle n'est pas forcément adaptée à vos exigences de données, et que les utilisateurs peuvent ne pas bénéficier de la saisie automatique s'ils n'utilisaient auparavant que des formulaires avec address-line1 et address-line2.

Pour un champ de texte multiligne, 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 les noms des parties d'une adresse varient, tout comme les formats d'adresse, même dans la même langue.

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

Il peut être irritant 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 attendez.

La personnalisation des formulaires d'adresse pour plusieurs langues peut être nécessaire pour votre site, mais l'utilisation de techniques pour 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 principales priorités pour faire face à différents formats d'adresse : * Évitez d'être trop précis sur les éléments de l'adresse, par exemple en insistant sur un nom de rue ou un numéro de maison. * Dans la mesure du possible, évitez de créer des champs required. Par exemple, dans de nombreux pays, les adresses ne comportent pas de code postal, et les adresses rurales peuvent ne pas comporter de nom de rue ou de route. * Utilisez des noms inclusifs : "Pays/région" au lieu de "Pays", "Code postal" au lieu de "Code".

Restez flexible ! L'exemple de formulaire d'adresse simple ci-dessus peut être adapté pour fonctionner "assez bien" dans de nombreuses langues.

Éviter la recherche d'adresse par 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.

La suggestion d'adresse par code postal ne fonctionne 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 d'utiliser la saisie automatique et de saisir leur adresse complète en un seul geste ou en appuyant dessus.

Une saisie de nom unique permet de saisir une adresse en un seul geste (un seul clic).

Simplifier les formulaires de paiement

Les modes de paiement sont l'élément le plus important du processus de paiement. Une mauvaise conception du formulaire de paiement est une cause courante d'abandon du panier. Le diable est 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 aussi facilement que possible.

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

Assurez-vous d'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 figurant sur 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 de leur carte de paiement et en saisissant correctement les données du formulaire. Sans saisie semi-automatique, les utilisateurs sont plus susceptibles de conserver une trace physique des informations de leur carte de paiement ou de stocker des données de carte de paiement de manière non sécurisée sur leur appareil.

Éviter d'utiliser des éléments personnalisés pour les dates de carte de paiement

S'ils ne sont pas correctement conçus, les éléments personnalisés peuvent interrompre le parcours de paiement en bloquant la saisie automatique et ne fonctionneront pas dans les anciens navigateurs. Si tous les autres détails relatifs à 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 ne fonctionne pas 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.

Capture d&#39;écran du formulaire de paiement montrant des éléments personnalisés pour la date d&#39;expiration de la carte qui interrompent le remplissage automatique.
La saisie semi-automatique a rempli tous les champs, sauf la date d'expiration !

Utiliser une seule saisie pour la carte de paiement et les numéros de téléphone

Pour les numéros de carte de paiement et de téléphone, utilisez une seule zone de saisie : ne divisez pas le numéro en plusieurs parties. Cela permet aux utilisateurs de saisir plus facilement des données, de simplifier la validation et de permettre aux navigateurs de saisir automatiquement des données. Pensez à faire de même pour d'autres données numériques, comme les codes PIN et bancaires.

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 champs pour un numéro de carte de crédit.

Validez attentivement

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 saisie 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 le focus sur la saisie. Aucun JavaScript requis !

Toutefois, 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 chiffres (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. Cela est plus convivial pour l'utilisateur (vous n'aurez pas à lui dire qu'il a fait une erreur), moins susceptible d'interrompre le parcours de conversion et il est facile de supprimer les espaces dans les nombres avant le traitement.

Effectuer des tests 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 gratuitement des projets Open Source sur différents appareils et navigateurs.

Captures d&#39;écran d&#39;un formulaire 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 sur l&#39;iPhone 7
Même page sur iPhone 7 et iPhone 11.
Réduisez la marge intérieure pour les fenêtres d'affichage mobiles de petite taille 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 comprendre correctement l'expérience des utilisateurs avec vos formulaires de paiement et d'adresse.

Pour cela, vous avez besoin d'analyses et de la surveillance des utilisateurs réels : données sur l'expérience des utilisateurs réels, comme le temps de chargement des pages de paiement ou le temps de traitement du paiement :

  • Analyse des pages: 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 à quel moment les utilisateurs abandonnent le 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, en déterminer la cause.

L'analyse des pages, l'analyse des interactions et la mesure des performances réelles des utilisateurs deviennent 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 par exemple de savoir si les codes de réduction augmentent les revenus ou si un changement de mise en page du formulaire améliore les conversions.

Vous disposez ainsi d'une base solide pour hiérarchiser les efforts, apporter des modifications et récompenser la réussite.

Poursuivez votre apprentissage

Photo de @rupixen sur Unsplash.