web-dev-qa-db-fra.com

Meilleure pratique: création d'un compte pendant le processus de panier

Quoi de mieux dans l'e-shop shopping-cart? 1) Créez automatiquement des comptes avec l'achat (le mot de passe généré automatiquement est envoyé à l'e-mail).

ou

2) Laisser l'utilisateur la possibilité optionnelle (l'utilisateur clique sur la case à cocher qui veut Compte) de créer son propre compte avec son propre mot de passe? Dans le cas des utilisateurs de mot de passe personnalisé, ne remplit que deux champs supplémentaires (mot de passe).

La capacité optionnelle signifie moins de comptes pour nous, mais nous avons de meilleures chances que les gens se souviennent qu'il y a un compte et un mot de passe.

3) Ou vous pouvez inventer quelque chose de mieux?

Nous voulons que la plupart des clients connectés dans l'e-boutique.

Modifier: la création automatique d'un compte dans mon cas signifie que l'utilisateur n'a pas rempli un seul champ supplémentaire lors du processus de commande. Le compte est créé avec la commande comme chose secondaire. Ainsi, l'utilisateur n'est pas obligé d'effectuer une action supplémentaire.

4
Jarda

N'envoyez absolument pas le mot de passe de l'utilisateur dans un e-mail en texte brut. C'est dans le top 10 des échecs de sécurité de tous les temps.

C'est l'un des rares problèmes UX qui doit prendre en compte les contraintes de l'environnement technologique actuel. J'ai travaillé avec certains systèmes qui exigeaient la création d'un compte afin même de mettre des articles dans un panier.

En supposant que vous n'êtes pas retenu, je recommanderais ce qui suit:

  1. Au début du processus de paiement, fournissez à l'utilisateur un écran qui comprend trois éléments: un formulaire de connexion/mot de passe, un bouton pour créer un compte et un bouton pour passer en tant qu'invité.

  2. Si invité est sélectionné, autorisez l'utilisateur à poursuivre le processus de paiement sans forcer la création de compte. Avertissez l'utilisateur s'il fournit une adresse e-mail pour la commande qui est déjà associée à un compte (et demandez-lui de se connecter).

  3. Dans la dernière étape, demandez à l'utilisateur de définir un mot de passe afin qu'il puisse magasiner plus facilement. S'ils le font, tout va bien et vous pouvez continuer.

En supposant qu'ils ne créent pas de compte:

  1. Stockez l'enregistrement utilisateur incomplet de manière à le distinguer des autres comptes. Un choix facile consiste à laisser un mot de passe vide. Utilisateurs avec des mots de passe vides = utilisateurs sans comptes à part entière.

  2. L'utilisateur a besoin de pouvoir vérifier sa commande - vous avez donc besoin d'un mécanisme où cela peut avoir lieu sans informations d'identification. Il est courant d'utiliser le numéro de commande et le code postal pour vérifier l'identité.

La dernière chose à prendre en compte est que l'utilisateur peut choisir de créer un compte à l'avenir. Ils peuvent essayer de se connecter en pensant qu'ils ont un compte ou ils peuvent suivre le processus pour créer le compte:

  1. Les tentatives de connexion avec un compte sans mot de passe doivent guider l'utilisateur dans le processus de réclamation de son compte. Un e-mail de vérification doit être envoyé à l'adresse avec un lien. Le suivi du lien vérifie l'identité de l'utilisateur et lui permet de définir un mot de passe.

  2. Les tentatives de création de compte à partir de zéro devraient ressembler au processus de création normal - assurez-vous simplement de ne pas déplacer le statut de l'utilisateur de partiel à complet avant de cliquer sur le lien de vérification.

Cela pourrait représenter beaucoup de travail pour vos ingénieurs s'ils ne sont pas configurés pour gérer de tels flux. Quelques notes finales:

  • L'élément de récupération de compte est plus important dans les scénarios où vous ne voulez pas que l'historique d'achat de l'utilisateur soit fragmenté entre les comptes. S'ils ont utilisé une adresse e-mail en tant qu'invité et ont ensuite créé un compte en utilisant la même adresse, l'achat effectué en tant qu'invité doit être visible.

  • Efforcez-vous de vous assurer que l'utilisateur ne se sent pas en train de jongler avec les coulisses pour que cela fonctionne. Faites-le ressembler au processus traditionnel.

  • Profitez du fait qu'il s'agit d'une question à laquelle vous pouvez répondre définitivement avec des données d'expérimentation et d'utilisation. Définissez un entonnoir à travers le processus de paiement et regardez le dépôt à chaque étape.

Quelques liens pertinents:

4
Tom Griffin

Vous ne devez créer un compte que lorsque cela est strictement nécessaire et uniquement si l'utilisateur souhaite créer un compte.

Dans la mesure du possible, vous devez autoriser les utilisateurs à effectuer une transaction en tant qu '"invité" par lequel ils entrent toutes leurs coordonnées, mais celles-ci ne sont stockées qu'avec la commande en cours et ne sont pas utilisées pour créer un compte. Vous pouvez suggérer à l'utilisateur de créer un compte (car il pourra suivre la commande, etc.) mais c'est tout.

Si votre système ne peut pas le faire, vous ne devez créer le compte qu'immédiatement avant le processus de paiement et permettre ainsi à l'utilisateur d'annuler la transaction s'il ne souhaite pas créer le compte. S'ils créent un compte pour finaliser l'achat, vous ne devez pas générer automatiquement un mot de passe car vous devrez l'envoyer à l'utilisateur en clair, ce qui est une mauvaise pratique.

La création de comptes trop tôt - par exemple pour pouvoir simplement parcourir le site - est un arrêt majeur pour les utilisateurs.

Si vous souhaitez que les clients créent des comptes, vous devez leur proposer d'autres incitations; offres spéciales, listes de diffusion, accès anticipé aux ventes, etc.

7
ChrisF

Je comprends que vous avez besoin de la plupart des clients connectés. Cependant, comme l'a dit @ChrisF, ce n'est pas une bonne pratique de forcer l'enregistrement. Comme indiqué dans le récent article NNG , si vous avez besoin de l'utilisateur pour vous inscrire, mettez en évidence les avantages de l'inscription du point de vue des utilisateurs et non du point de vue de l'entreprise lors de la demande les utilisateurs à s'inscrire.

NNG avait également effectué une recherche sur le commerce électronique et ils ont découvert que les enregistrements forcés entraînaient une perte de ventes. Pour citer l'article:

Dans notre recherche sur le commerce électronique, nous avons vu des utilisateurs qui s'étaient déjà plaints de l'enregistrement forcé s'inscrire avec plaisir sur des sites où l'enregistrement était limité à la possibilité de créer un mot de passe lors du processus d'achat.

Forcer l'enregistrement entraîne une perte de ventes. Certains utilisateurs quitteront le site, d'autres auront du mal à s'inscrire. Il est courant que les sites qui ajoutent la caisse d'invités réalisent immédiatement une augmentation des ventes. C'est un moyen simple d'améliorer la convivialité et d'encourager les achats.

Modifier: je ne suggérerais pas non plus la création automatique de compte. J'ai vu certains sites faire cela et d'après ce que j'ai observé, les utilisateurs ne s'en souviennent même pas lors de leur prochaine visite. Lorsque les utilisateurs aiment votre produit, ils s'y engagent en s'inscrivant. Tout engagement forcé (manuel ou automatique) ne va pas aider le produit.

3
Adit Gupta

C'est génial de créer un compte avec l'achat. Mais au lieu d'envoyer un mot de passe généré automatiquement, l'envoi d'un lien demandant à l'utilisateur de créer un nouveau mot de passe serait approprié. Vous pouvez également fournir un lien pour supprimer le compte s'ils ne veulent pas en avoir un. S'il s'agit d'un mot de passe généré automatiquement, certains peuvent l'utiliser pour la toute première fois pour se connecter et l'oublier plus tard. S'ils veulent à nouveau se connecter plus tard, ils devraient retourner chercher le mot de passe qui se trouve dans leur courrier. Au lieu de cela, s'il existe un lien demandant à l'utilisateur de choisir un mot de passe, il utilisera un mot de passe dont il pourra facilement garder la trace.

0
Bharath Selvaraj