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

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.

Utiliser 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 élément HTML <form> 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> permet également de créer plus facilement des fonctionnalités de base pour les anciens navigateurs dont la compatibilité avec JavaScript est limitée, et d'activer l'envoi de formulaires même en cas de problème avec votre code, et 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, nommez le bouton d'envoi de votre formulaire d'adresse de livraison Procédez au paiement plutôt que 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 un bouton de validation en attendant une entrée utilisateur complète et valide. Par exemple, ne laissez pas un bouton Enregistrer l'adresse désactivé simplement parce qu'il manque ou n'est pas 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 pleinement les 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. Cela est particulièrement important sur mobile et essentiel pour éviter des taux d'abandon élevés. La saisie semi-automatique présente é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. 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 mot de préfixe aux attributs de saisie semi-automatique si vous avez des valeurs différentes 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

É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. Au cours du processus de paiement, les clients tentent de donner de l'argent à votre entreprise pour un produit ou un service. Votre tâche est de les aider, et non de les punir.

Vous pouvez ajouter des attributs de contrainte pour former des éléments afin de spécifier les valeurs acceptables, y compris min, max et pattern. L'état de validité de l'élément est défini automatiquement en fonction de la validité de sa valeur, 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.

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 du formulaire, les navigateurs mettent automatiquement en surbrillance les champs dont les valeurs obligatoires sont 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 les données sur votre serveur après l'envoi du formulaire, listez tous les problèmes détectés et mettez en évidence tous les champs de formulaire contenant des valeurs non valides. Vous devez également afficher un message en ligne à côté de chaque champ problématique expliquant ce qui doit être corrigé. Vérifiez les journaux du serveur et les données d'analyse 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 (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 pour les entrées de valeurs obligatoires.

Lorsqu'un formulaire est envoyé, les navigateurs modernes affichent automatiquement une invite et mettent en surbrillance les champs required dont les données sont manquantes. Vous pouvez utiliser la pseudo-classe :required pour mettre en évidence 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.

Simplifier le processus de paiement

Attention à l'écart entre le commerce sur 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 maintenir la concentration, en particulier sur mobile. 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 dus à 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 sont 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 l'inscription à 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 devrait donc être rapide et facile pour l'utilisateur.

Afficher la progression du règlement

Vous pouvez rendre le processus de paiement moins complexe en affichant 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.

Affichez 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 multipage, enterkeyhint="done" pour la saisie finale du formulaire et enterkeyhint="search" pour une saisie 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 pas seulement un résumé limité. Permettez aux utilisateurs d'ajuster facilement les quantités d'articles depuis la page de paiement. Votre priorité au moment du règlement 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 de la recherche, de la navigation et d'autres distractions 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 SANS FRAIS qui gêne la lecture.
Ne distrayez pas les clients de leur achat.

Pour les utilisateurs connus, vous pouvez simplifier encore plus le parcours de paiement en masquant les données dont ils n'ont pas besoin. 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 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 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 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 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.

Autoriser 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". (Consultez UK Address Oddities! si vous n'êtes pas convaincu.)

Rendre les formulaires d'adresse flexibles

N'obligez pas les utilisateurs à essayer de faire entrer leur adresse dans des champs de formulaire qui ne sont pas adaptés.

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 la localisation 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 proposer 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'adresses par code postal

Certains sites Web utilisent un service pour rechercher des adresses en fonction du 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 choisir parmi une longue liste d'adresses, en particulier sur mobile s'ils sont pressés ou stressés. Il peut être plus simple et moins sujet à des erreurs de laisser les utilisateurs profiter de la saisie semi-automatique et de saisir leur adresse complète en un seul geste ou clic.

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.

Aidez les utilisateurs à ne pas 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 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 semi-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.

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, à l'exception de 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 sans frais 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;Finaliser 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 vues mobiles plus petites afin de vous assurer que le bouton Effectuer 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 la durée du paiement :

  • Analyses des pages: pages vues, taux de rebond et de sortie pour chaque page contenant un formulaire.
  • Analyses des interactions: les entonnoirs d'objectifs et les événements indiquent à quel moment les utilisateurs abandonnent votre parcours 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 le chargement de vos pages de paiement est lent et, le cas échéant, en déterminer la cause.

Les analyses des pages, les analyses des interactions et la mesure des performances réelles des utilisateurs sont particulièrement utiles lorsqu'elles sont combinées aux journaux du 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 "Un changement de mise en page du formulaire améliore-t-il 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.