Confirmation d'adresse de rue
J'essaie de concevoir la meilleure façon pour un client existant de confirmer son adresse postale et ce sont les deux conceptions que j'ai imaginées.
Méthode A
J'aime ça parce qu'il est facile à lire et ils peuvent passer à travers. Si c'est leur adresse, ils ne voient pas le formulaire. S'ils sélectionnent "non", le formulaire apparaît et ils le remplissent. Je suppose que je pourrais préremplir les entrées et qu'elles n'auraient pas à remplir toute la boîte, mais cela pourrait être déroutant.
Méthode B
Cela semble être le moyen le plus courant, mais pourquoi? Il semble plus difficile de traiter les informations et l'utilisateur doit aller plus loin pour continuer. Je suppose qu'il pourrait être plus facile de changer de rue car il est prérempli, mais c'est le seul avantage que j'en vois.
Mais qu'est-ce qui leur faciliterait la vie? J'ai déjà feuilleté la conception de formulaires Web de Luke Wroblewski sans succès sur une réponse solide.
Méthode C (évoquée dans les commentaires ci-dessous par Crissov)
Très similaire à A (comme il l'a dit). Cette méthode résout le problème de la séparation de la question et de l'adresse (problème signalé ci-dessous par dan1111) mais la personne doit lire l'adresse dans un format légèrement moins familier pour les formulaires. Il a également le même problème avec la méthode A où il peut être difficile de "concaténer l'adresse dans un format qui a du sens pour l'utilisateur" (Matt). J'aime à quel point c'est concis.
En fin de compte, c'est un compromis: la méthode A a l'avantage d'être concise, mais la méthode B a l'avantage d'être cohérente.
(Je suis le gars UX chez SmartyStreets où nous traitons beaucoup d'adresses.)
J'aime mieux la méthode B, et voici pourquoi:
L'adresse est affichée dans un format familier que l'utilisateur peut rapidement numériser pour l'exactitude.
L'utilisateur n'a pas à faire le choix supplémentaire et délibéré de modifier ou non l'adresse. Au lieu d'un choix actif, il devient un choix passif.
Toutefois, l'invite avant le formulaire sur la méthode B est un peu déroutant. Dire "Modifier l'adresse pour ..." donne l'impression que vous demandez à l'utilisateur de modifier l'adresse. Reformulez-le pour qu'il s'agisse de "Confirmer l'adresse de ..." ou simplement d'un titre, "L'adresse de John Johnson".
Je n'aime pas la méthode A car vous devez concaténer l'adresse dans un format qui a du sens pour l'utilisateur en fonction de son pays, ce qui peut être compliqué. Même si vous traitez uniquement avec des adresses américaines, la combinaison de l'adresse en une seule ligne n'est pas toujours facile en raison des différents formats décrits dans la publication USPS 28 (et cela ne s'applique que si vous standardisez les adresses). Et puis, vous devez toujours proposer à l'utilisateur un autre choix: mettre à jour l'adresse ou non. Il est probable que vous ne souhaitiez pas interrompre le flux de l'utilisateur et le forcer à faire un autre choix avant de continuer.
Je pense que si vous reformulez simplement l'invite de la méthode B, ce sera suffisant.
Le fait que l'option B oblige l'utilisateur à revoir l'adresse est ne fonctionnalité, pas un bug.
Obtenir une mauvaise adresse est généralement très coûteux pour l'utilisateur et le propriétaire du site Web - quelque chose va être expédié au mauvais endroit, le courrier ne sera pas reçu ou au moins une carte de crédit sera refusée. Il est donc important que l'utilisateur vérifie que l'adresse est correcte. L'option B procède de plusieurs manières:
- L'adresse est mise en évidence à l'écran. Le formulaire attire l'attention de l'utilisateur sur les éléments.
- Les éléments individuels sont clairement étiquetés et dans une structure immédiatement reconnaissable.
- L'utilisateur doit faire défiler vers le bas, voir le tout.
En revanche, dans l'option A, l'adresse n'est pas suffisamment mise en évidence. Il serait possible de le rater complètement, ou du moins de ne pas remarquer d'erreur. Il est également nécessaire de lire la phrase pour comprendre ce qui est demandé.
Personnellement, je trouve également le format de l'option B plus facile à comprendre. Tout est dans un emplacement et un format prévisibles, tandis que dans l'option A, je dois analyser tout ce qui est entassé sur une seule ligne.
Il s'agit d'un test A/B en attente du "test". Vous avez un cas d'utilisation, un prototype et parlez maintenant à certains utilisateurs, même si c'est serTesting.com . Je recommande à l'utilisateur de parler à haute voix pendant qu'il parcourt les trois ou quatre vues.
Concurrent Think Aloud (CTA) est utilisé pour comprendre les pensées des participants lorsqu'ils interagissent avec un produit en les faisant réfléchir à haute voix pendant qu'ils travaillent. Le but est d'encourager les participants à garder un courant de conscience en cours de travail.
Vous n'avez besoin que d'environ 5 utilisateurs pour vous montrer le chemin . Cela peut être éliminé assez rapidement. Maintenant, allez mettre le "U" dans "UX".
Bonne chance, Ken
Vous devrez peut-être gérer plusieurs adresses à un moment ultérieur; Adresse de livraison et de facturation.
Solution [[# # ~] a [~ # ~] s'adapte bien à deux adresses ou plus en affichant toutes à la fois, chacune avec un bouton "Modifier" (au lieu des boutons radio pour oui et non) . "Modifier" chargerait l'adresse dans le formulaire.
Solution [[# #]] b [~ # ~] n'est pas très évolutif - cela peut fonctionner pour deux adresses, mais les deux formulaires seraient déjà trop bruyants.
Donc, s'il n'est pas vraiment sûr qu'il restera une seule adresse, c'est une bonne raison de choisir A .