Adresses dans les étapes de paiement
J'ai donc été confronté à un certain défi, à savoir la gestion des adresses lors des étapes de paiement, en plus de la possibilité d'ajouter une adresse et d'en modifier une. La question se décline en deux volets:
Un client doit-il pouvoir supprimer une adresse lors du processus de paiement? et pourquoi? (Avec références s'il vous plaît.)
L'édition et l'ajout d'adresses doivent-elles apparaître sous la forme d'un formulaire modal/dialogue ou d'un formulaire qui apparaît dans la page?
En ce qui concerne la possibilité de supprimer une adresse lors du paiement: je l'autoriserais. Ce point de vue provient à la fois de l'expérience personnelle et (jusqu'à présent) d'une enquête de trois contre un 1 des modules de gestion d'adresses existants en faveur de la suppression. Je ne peux pas dire pourquoi ils décident de l'autoriser, mais pour moi, une bonne raison est que pour beaucoup de gens, la seule fois où ils le feront penser à la gestion des adresses, c'est quand elles traversent le processus de paiement.
À un moment ou à un autre, j'ai ajouté différentes adresses à mon compte Amazon: parfois ce sont des transactions plus ou moins ponctuelles (je reçois quelque chose en cadeau et je veux le livrer directement au destinataire) ou en tant qu'adresse alternative pour mes affaires (adresse professionnelle, adresse de mes parents, etc.).
Maintenant, je peux être inhabituel, mais je pense rarement " allons gérer mon carnet d'adresses Amazon " ... donc la seule fois que je le remarquerai ces adresses ajoutées, et je pense que " je n'ai vraiment plus besoin de l'adresse XXX " lorsque je passe par l'étape de sélection d'adresse lorsque j'en place une autre ordre. Ne pas être en mesure de supprimer une adresse dont vous n'avez plus besoin à ce stade serait gênant.
Quelque chose comme un déménagement serait une exception: vous seriez en mode " de mise à jour complète de mon adresse avec toute organisation avec laquelle j'ai été en contact " et vous chercheriez probablement activement sites de commerce électronique pour vous mettre à jour les détails. Cependant, pour la plupart des gens, le déménagement est probablement un événement relativement rare, donc la suppression "en voiture" (c'est-à-dire pendant le processus de paiement) est, je dirais, une caractéristique nécessaire.
Un argument contre permettant la suppression d'une adresse est la maxime selon laquelle le processus de paiement (et, par extension, le processus de sélection d'adresse) devrait être aussi simple et épuré que possible. Bien que ce soit généralement un bon conseil, je ne pense pas que ce soit une bonne raison de ne pas autoriser la suppression d'une adresse:
Suivre cette maxime est le plus important pour les nouveaux clients : moins il y a de distractions et de complications (selon la théorie), plus vous avez de chances de convertir un prospect en vente. Cependant, par définition, la question de la suppression d'une adresse ne s'appliquera qu'aux clients existants qui ont déjà été "convertis" . Cela ne signifie pas qu'il est "OK" de compliquer inutilement l'écran d'un client qui revient, mais vous n'avez pas besoin d'être aussi diligent pour supprimer toutes les fonctions strictement inutiles comme vous le feriez avec un nouvel utilisateur.
La "complication supplémentaire" d'une option de suppression est minime. Il existe différentes façons d'organiser un sélecteur de carnet d'adresses (comme on peut le voir en suivant les références ci-dessous), mais comme la plupart ont déjà un Edit bouton; ajouter un Delete le bouton ne devrait pas faire beaucoup de différence.
Bien qu'il ne soit probablement pas strictement nécessaire de supprimer pendant le paiement (la plupart des sites proposent une fonction explicite " Gérer le carnet d'adresses ") ), Je dirais que l'avantage pour l'utilisateur (pouvoir supprimer une adresse quand il se trouve devant lui) l'emporte sur la légère complication supplémentaire et lui évite d'avoir à revenir sur votre site après avoir terminé le processus de paiement.
1 La recherche sur le Web a (jusqu'à présent) produit les listes suivantes de la façon dont différents "modules d'adresse" (conçus pour être connectés à des sites de commerce électronique) s'attaquent à la possibilité de supprimer des adresses pendant le processus de paiement:
Modules qui permettent la suppression
Cette page sur le module de carnet d'adresses d'AmeriCommerce offre la possibilité de supprimer des adresses existantes (voir notamment la capture d'écran sous Ce que le client voit ).
Cette page sur le carnet d'adresses de ShopWired offre également la possibilité de modifier et de supprimer des adresses existantes (voir première capture d'écran).
Cette page sur l'offre de carnet d'adresses d'ID Card Group permet également à la fois la modification et la suppression des adresses existantes (voir capture d'écran sous Ajout et modification dans le carnet d'adresses ).
Modules qui n'autorisent pas la suppression
- Cette page de Drupal à propos de leur module de carnet d'adresses semble (à partir des captures d'écran) pour permettre la création de nouvelles adresses , modification des adresses existantes, mais n'apparaît pas pour offrir une option pour supprimer les adresses existantes. Cette page semble être un module similaire pour une version ultérieure version de Drupal, mais ne semble pas non plus offrir la suppression.
Basé sur mon expérience personnelle et ma logique;
1) Le premier utilisateur ne devrait pas avoir la possibilité de gérer les adresses lors du paiement car il s'agit de sa première adresse entrée. Si l'utilisateur retourne un utilisateur et a utilisé plus d'adresses, il est probable que cela ne le dérange pas d'ajouter et de modifier des adresses pendant le checkkut, car il est déjà fidèle et cette action n'est pas si perturbatrice ou importante pour changer sa loyauté et son opinion.
2) Il est plus logique de le faire en ligne. Vous pouvez le faire efficacement avec Ajax ou d'autres effets. Je n'ai pas trouvé de référence claire à ce sujet, mais encore une fois, la logique est la suivante: votre objectif est de laisser l'utilisateur sur une interface similaire et de ne pas trop le modifier avec une fenêtre contextuelle (qui doit avoir un arrière-plan contrasté pour être visible), en particulier sur la partie sensible du site Web comme la caisse.
Difficile de juger sans contexte. Pendant le processus de paiement, j'autoriserais certainement les utilisateurs à vérifier (et ajuster) leurs informations personnelles, pour m'assurer que tout est à jour. Cependant, une option autonome pour effacer les données peut amener les utilisateurs à ressaisir des informations supprimées accidentellement.
Les modaux sont très perturbateurs et doivent être évités autant que possible. Ils cachent des informations qui ne sont détectables qu'en ouvrant le modal. Dans ce cas, le modal est susceptible de les sortir de leur flux de travail: il suffit de saisir leur adresse.
- Je présenterais les données en texte brut, avec une option pour modifier cela.
- Envisagez de diviser le processus de paiement complet en étapes distinctes pour réduire la quantité de données présentées à l'utilisateur.
Pour résoudre ce problème, examinons un cas d'utilisation:
Je commandais de la nourriture en utilisant le site Web Swiggy et je le fais depuis quelques années. Pendant ce temps, j'ai déplacé deux villes. Maintenant, sur ma page de paiement, j'ai plusieurs adresses que je n'utilise pas. Il est extrêmement frustrant de ne pas pouvoir supprimer mes adresses précédemment enregistrées car je ne les utilise plus.
Alors laissez-moi répondre à votre question par une autre question: Y a-t-il une raison pour laquelle vos utilisateurs ne devraient pas pouvoir supprimer une adresse?
Pour répondre à votre deuxième question, il est extrêmement situationnel d'utiliser ou non un modal. Un modal est généralement utilisé pour supprimer un utilisateur d'un processus et lui présenter un sous-processus. Par exemple, si votre champ d'adresse peut prendre des entrées d'une carte, ouvrir Google maps pour ajouter un marqueur à leur emplacement serait un bon candidat pour un modal. Dans votre scénario, puisque l'ajout d'adresse est le "processus principal", je ne recommanderais pas d'utiliser un modal.
L'utilisateur devrait être en mesure d'ajouter des adresses supplémentaires, bien qu'il soit plus probable qu'il s'agisse d'un cas d'utilisation lorsqu'un client/utilisateur de retour et en tant qu'utilisateur de retour, vous devriez pouvoir sélectionner/supprimer le titulaire de la carte d'adresse/livraison parmi les nombreuses adresses que vous dites. peut-être des articles surdoués dans le passé ... Je suis sûr que ebay et usc sont des endroits où j'ai plusieurs adresses et choisissez la bonne pour l'article. Je n'ai cependant supprimé aucune adresse dans aucun de ces comptes ... Je ne vois aucun inconvénient à donner à l'utilisateur la possibilité de modifier ou de supprimer et d'ajouter une adresse différente s'il change d'avis pendant la vérification, dites si les adresses ont été situé dans un accordéon fermé au-dessus du prochain état étendu (détails de la carte). Ils pourraient revenir pour s'adresser et faire amende honorable.
J'essaierais d'éviter d'utiliser des modaux ou de charger de nouvelles fenêtres et de rester en ligne comme une bonne pratique, mais si vous devez maintenant superposer son écran plein écran dans la plupart des cas.
Avoir la fonctionnalité de suppression d'adresse dans le processus de paiement est très bien, tant qu'elle est accessible ailleurs. Tenez compte de la fréquence des paiements par l'utilisateur et déterminez si cela ajoutera ou supprimera des frictions à chaque fois que l'utilisateur répète un achat.
Si un utilisateur est un acheteur fréquent sur le site et qu'il sait qu'une gestion complète des adresses est possible pendant le processus de paiement, il est plus susceptible de s'engager d'abord avec les activités liées aux achats, même s'il se trouve à un endroit différent. Anticiper l'anxiété devrait être la priorité absolue, car c'est la cause la plus importante de friction et de perte de revenus.
Les utilisateurs sont inquiets s'ils pensent qu'ils pourraient perdre leur panier d'achat en naviguant ailleurs pour mettre à jour une adresse. Ce conflit est amplifié sur mobile.
Les utilisateurs sont inquiets s'ils pensent qu'il y a une chance qu'ils aient envoyé la commande à la mauvaise adresse, la supprimer élimine la possibilité d'erreur. Par exemple, ils avaient acheté en voyageant pour le travail et savent qu'ils ont entré l'adresse de l'hôtel, cependant, il n'y a aucune incitation à conserver cette adresse. À mesure que le nombre d'adresses augmente, la possibilité d'erreur est plus importante.
Tout en évitant l'anxiété influencerait également la décision d'utiliser un formulaire par rapport à modal, la principale préoccupation, dans ce cas, est de réduire la charge cognitive pour l'utilisateur. La charge cognitive imposée à un utilisateur lors du paiement est considérablement réduite si le contexte reste le même pendant tout le processus, donc je déconseille le modal. Cette décision aide non seulement à atteindre l'objectif (achat), mais elle libérera également l'utilisateur du mode d'attention sélective et les rendra plus susceptibles de s'engager avec d'autres aspects du site, comme des promotions spéciales ou des actions post-achat.
Je ne sais pas ce que vous entendez par références. Ma compréhension de ce sujet vient de l'étude du comportement des utilisateurs et des processus de prise de décision, je chercherais des recherches produites sur ces sujets.