Bien que la plupart des gens ne considèrent pas le site web d’Apple comme un des sites les plus importants, Novembre a vu Apple dans la liste des dix meilleurs sites Web américains. 62 millions d’internautes ont visité le site d’Apple au cours du mois avec une moyenne de 1 heure et 18 minutes passées par l’utilisateur. En comparaison, Google a enregistré 155 millions de visiteurs uniques en Novembre.
La boutique en ligne d’Apple a certainement joué un rôle dans ce succès, les données des ventes de détail montre que les ventes de Mac ont augmenté de 21% en glissement sur douze mois au cours des mois d’Octobre et Novembre. Il est donc intéressant de noter que le site d’Apple a vu son canal de vente primaire sur le web (son formulaire de commande) se faire remanier au cours de cette période.
Étudions de plus prêts ce cas pratique pour le e-commerce.
Traduction de l’article de LukeW, “The Apple’s store checkout form redesign“
La dernière version du formulaire de paiement d’Apple s’étendait sur plusieurs pages et utilisait un indicateur de progression de haut niveau pour mettre en évidence où les gens en étaient dans le processus de paiement. Les erreurs de saisies été affichées au niveau de la page et n’indiquaient pas exactement les champs responsable des erreurs, ni la manière dont il fallait compléter les informations pour faire disparaitre ces messages d’erreurs.
L’écran final de confirmation n’était pas clair du fait d’un mélange confus de boutons au lieu du seul appel à l’action principale, continuer le paiement.
Alors que c’est certainement une bonne idée de laisser les gens savoir à quel point ils en sont dans un processus, il faut se méfier des indicateurs de progression qui représentent à tort le nombre de pages Web ou le nombre d’étapes requises pour remplir un formulaire. Une pratique trop souvent répandue lorsque l’on doit concevoir un formulaire qui s’étale sur plusieurs pages consiste à inclure un indicateur de progression qui ne va pas refléter fidèlement le nombre de pages ou d’étapes que votre formulaire exige dans tous les cas.
Considérons les étapes typique d’une barre de progression pour le paiement sur un site de e-commerce qui indiquerait trois éléments :
Expédition
Facturation
Paiement
Quand vient le temps de choisir une adresse de livraison, il vous faut choisir votre adresse de destination dans une liste déroulante préremplie. Si elle ne s’y trouve pas, vous allez devoir vous rendre sur une autre page pour créer votre nouvelle adresse. D’une étape nous sommes passés à deux.
Lors de la facturation, votre client pourrait choisir d’utiliser un système de paiement qui nécessite une identification ou pourquoi pas, de créer un compte. Ce qui nécessitait une étape pourrait bien en demander au moins quatre.
Nous pourrions donc nous retrouver à devoir accomplir six étapes au lieu des deux que nous avions promises. Je ne dis pas que donner un apercu de la progression n’est pas une bonne chose, mais au final nous ne disons pas forcément la vérité. La solution pourrait être de supprimer cet indicateur de progression, tout simplement.
Le champ d’entrée qui est responsable d’une erreur ne doit pas seulement remonter l’erreur au niveau de la page, mais aussi avoir un marquage bien visible. Pour aider votre client à bien remplir votre formulaire, le message d’erreur de niveau haut et le champ incriminé doivent comporter des instructions claires qui encouragent vos clients à essayer une autre une réponse ou qu’ils puissent demander de l’aide s’ils ne peuvent pas. L’inclusion d’instructions à côté du champ de saisie responsable de l’erreur fournit à vos clients une aide précieuse: d’où l’erreur peut être fixée.
Des actions telles que Envoyer, Enregistrer ou Continuer visent à permettre la finalisation de la saisie du formulaire, ce qui est le but premier de n’importe qui aurait commencé à remplir un formulaire. Parce qu’ils permettent l’action la plus importante sur le formulaire (le finir), ils peuvent être dénommées “actions primaire”. Les actions secondaires, d’autre part, ont tendance à être moins utilisés et permettent souvent à vos client d’effacer des données. Parce que les actions secondaires peuvent avoir des conséquences négatives, en particulier lorsqu’elles sont utilisées sans le vouloir, j’ai souvent fait valoir qu’ils devraient être absents de ce type de formulaire.
Cela dit, il y a des situations où les actions secondaires ont du sens (comme Enregistrer pour plus tard, Aperçu, exportation, etc.) Bien qu’il puisse être tentant d’utiliser les boutons Précédent et Suivant lorsqu’ils sont dans une action secondaire, il est préférable de conserver vos clients avec la volonté d’aller de l’avant dans le processus d’achat. Un appel sur une action principale en lieu et place de ces boutons est susceptible d’être plus productifs.
Après tout, nous voulons que nos clients finissent de remplir ce formulaire, n’est ce pas ? Lorsque vous réduisez l’importance visuelle des actions secondaires, ils minimisent le risque d’erreurs potentielles et permettent de diriger le clients vers un résultat “positif”.
Apple à redesigné sa page de formulaire d’achat en utilisant un système d’accordéon qui permet de conduire le client au travers de l’ensemble des champs à remplir. Cela a pour effet bénéfique de supprimer l’envoie vers de nouvelles pages à chaque action ainsi que le besoin de recourir à une barre de progression qui étaient dans le précédent design du site. Lorsqu’un client fini de remplir une partie, la partie suivante se déplie en dessous, pour faire apparaitre les nouveaux champs à remplir. Je vous invite à voir le résultat sur le site d’Apple.
Alors que le précédent design du site utilisait des onglets pour présenter les questions, le nouveau design du site les onglet seulement pour les différentes sections et utilise des champs de saisie pré-rempli pour tout le reste. Dans les cas où l’on souhaite minimiser l’affichage (comme avec un formulaire en accordéon), combiner les libelles et les champs de saisie dans le même champ de l’interface utilisateur peut être un moyen tentant de gagner de l’espace. Toutefois, il existe un certain nombre de considérations à prendre en compte.
Une interaction fiable pour les étiquettes dans les champs de saisie, requiert que l’étiquette disparaisse rapidement quand vos clients placent leurs curseurs dans le champ de saisie de sorte qu’ils puissent fournir leur réponse. Sinon, l’étiquette pourrait rester dans le champ et ainsi faire partie de la réponse de quelqu’un.
Parce que les étiquettes qui sont présentes dans les champs de saisie disparaissent, vos clients ne verront plus la question sur laquelle porte leur réponse. Donc, si vous avez soudainement oublier la question… l ‘étiquette est introuvable. La solution pour les formulaires de moyenne ou petite taille est de bannir ce système. De plus, lorsque vous avez terminé de remplir le formulaire, toutes les étiquettes sont partis! Cela rend le contrôle des réponses par l’utilisateur un peu plus difficile et pourrait l’empêcher de rectifiez une réponse erronées.
La solution d’Apple peut être en mesure d’atténuer ce problème, car le formulaire utilise une structure bien connu par les internautes. L’adresses postale, la page d’expédition ou de facturation, par exemple, possède une structure bien connue qui peut être mis à profit pour aider les gens à comprendre comment répondre aux questions. D’autres exemples comprennent le nom et prénom, la date et l’heure, ou les parties d’un numéro de téléphone. Ces groupes d’entrée peuvent être utilisés dans les formulaires pour fournir des indices supplémentaires sur les questions qui ont été répondu (une fois les étiquettes ont disparu). Les en-têtes des parties visible peut aussi aider.
Enfin, les étiquettes dans les champs de saisie doivent être présentées d’une manière qui rend évident à première vue qu’ils sont des étiquettes et non pas des réponses. Le formulaire d’Apple grise le texte de l’étiquette afin de les distinguer des réponses.
Sur le nouveau formulaire d’Apple, les gens sont invités à donner leur code postal d’abord, puis une série de choix pour leur ville et l’État leurs est proposés. Cette série de choix leurs est proposé sous une forme de liste déroulantes avec tous les états américains, lorsque l’on est situé au États Unis.
Le point positif, cette conception élimine certaines des interactions maladroites qui entraînerait de mauvaise réponses aux questions.
Le point négatif, lorsqu’ils sont confrontés à un ensemble d’entrées qui correspondent à la structure d’une adresse postale (comme mentionné ci-dessus), et donc que les visiteurs connaissent, ils ont tendances à s’attendre à saisir les informations dans un certain ordre car les composants et la disposition d’une adresse sont familiers à peu près tout le monde aux États-Unis. Le site d’Apple rompt cette structure en demandant Code postal en premier.
Quelque soit la question que vous poserez à vos clients au travers d’un formulaire Web les obligera à l’analyser, formuler une réponse, puis d’entrée leur réponse sous la forme que vous avez fournies sur le formulaire. Être vigilant sur chaque question que vous posez vous permettra de supprimer des questions qui ne sont pas absolument nécessaires, ou qui pourra être demandé à un meilleur moment, ou peut être même calculée automatiquement. Et moins de question vous poserez, meilleures seront les chances que vos clients remplissent vos formulaires rapidement et facilement.
Prenons l’exemple de la carte de crédit qui à une structure cohérente et connue. Les cartes American Express commencent avec 34 ou 37, les Mastercard commencent par 51-55, les cartes Visa commencent par 4, et ainsi de suite. Cette information peut être utilisée pour déduire le type de carte de crédit que quelqu’un utilise simplement en regardant son numéro de carte de crédit.
Dans leur nouveau formulaire de commande , Apple fait exactement cela. Lorsque quelqu’un entre dans un numéro de carte de crédit, le type de carte approprié est mis en évidence au-dessus. Ceci élimine le besoin de demander aux gens leur type de carte de crédit. Une question en moins à analyser, réfléchir et répondre.
Dans un formulaire, certaines données sont parfois dépendantes d’autres précédemment saisies, toujours sur la même page.
Le nouveau formulaire d’Apple regroupe ces champs dépendants les uns des autres dans des onglets, comme paiement, Financement… Cela permet au gens de naviguer entre les sections et ainsi voir clairement les différentes sections et celle qu’ils ont sélectionné.
Bien que la plus part des internautes soient aujourd’hui à l’aise avec l’utilisation des onglets, la manière qu’ils ont de remplir un formulaire de haut en bas pourrait invalider cette approche, ne voyant ainsi pas les onglets.
Cela pourrait aussi créer de la confusion en ne sachant pas, par exemple, si la validation concerne un onglet ou tous.
Cependant, lors de test pour la validation d’autres formulaire, aucun de nos participants n’a fait d’erreur. Ils ont tous été capable de réaliser l’action rapidement et simplement. Il semblerait donc qu’Apple ait mis le doigt sur un point intéressant pour nos interfaces client.
Comme nous l’avons vu, l’ancien formulaire d’Apple comportait un grand nombre d’appels à l’action visuelle de différentes formes et couleurs. La nouvelle conception réduit considérablement le poids visuel des actions secondaires et met tout l’accent sur une action principale: Continuer. Cela permet de définir un chemin clair vers la conclusion du formulaire.
Le nouveau formulaire d’Apple introduit de nouveaux messages d’erreur et dans leur contexte. Ainsi, les erreurs sont maintenant affichées à côté des champs d’entrée qui ont causé l’erreur avec des instructions claires sur la façon dont ils peuvent être résolus.
Toutefois, l’élimination d’un message d’erreur de haut niveau signifie qu’il est possible d’entrer dans un état où des erreurs sont présentes sur une page, mais seulement indiqué par une couleur de fond jaune clair. J’ai eu ce problème lors du changement de monter ma carte de crédit. Le numéro de carte de crédit et le code de sécurité étaient dans un état d’erreur, mais rien sur le formulaire me l’indiquait, au-delà de la couleur jaune clair. Cela est particulièrement troublant si l’on considère que le navigateur Web d’Apple, Safari et les autres navigateurs utilisent une teinte similaire de couleur jaune pour indiquer les champs de saisie qu’ils remplissage automatiquement pour vous.
En fait, avec le précédent formulaire d’Apple , un fond jaune clair indiquait un champ de saisie auto-complété. Dans le nouveau formulaire, cela indique une erreur. Pourquoi Apple n’a pas utilisé le rouge (la couleur standard des erreurs) dans son formulaire? Cela semble être réservés à la livraison gratuite! A croire qu’Apple veux absolument que la livraison gratuite soit vu tout de suite, car synonyme d’erreur dans l’esprit des clients 😉