Devrions-nous utiliser "s'il vous plaît" pour les messages de validation des applications de commerce électronique
Lorsque nous construisons une application de commerce électronique (très probablement une application Web), la validation des entrées est l'un des concepts fondamentaux de ce type d'applications. Lorsque la validation échoue, nous devons fournir à l'utilisateur quelque chose de plus que des signaux rouges.
Par exemple, supposons qu'un champ de saisie soit obligatoire et que l'utilisateur final essaie de soumettre le formulaire sans remplir le champ requis. Les messages d'erreur ci-dessous seraient le type de message que nous recevrions:
- Le champ du nom est obligatoire.
- Le champ du nom doit être rempli.
- Veuillez ne pas laisser le champ Nom vide.
- Veuillez remplir le nom déposé
Je ne suis toujours pas sûr de ces options. Devrions-nous vraiment être polis lorsque nous fournissons des messages de validation? Pensez-vous que l'utilisateur final nous détesterait si nous disions tant de choses "s'il vous plaît" (s'il y a plusieurs messages, nous dirions s'il vous plaît, s'il vous plaît, s'il vous plaît, encore et encore)?
Je dirais oui quand cela ne fait pas obstacle à la lisibilité. Ce qui, je pense, fonctionne bien, c'est que vous commencez le message d'erreur par une introduction conviviale (joue Nice avec plusieurs erreurs aussi).
Désolé, nous n'avons pas pu soumettre vos données. Veuillez envisager de corriger l'erreur suivante:
- Le champ du nom est obligatoire.
Je pense qu'il est très important que votre communication ne soit pas agressive. Vous voulez presque communiquer à l'utilisateur que ses sites Web sont en défaut et non l'utilisateur. Vous ne voulez sûrement pas ennuyer l'utilisateur et lui faire quitter le site avant de terminer le processus d'achat.
Je ne trouve plus le lien mais 7Signals a fait des tests AB lors de l'inscription et a remarqué qu'ils avaient des taux d'inscription plus élevés quand ils ont remercié l'utilisateur en cours de route. Je peux imaginer que le même effet s'applique ici.
Non. Gardez le texte de votre message court et significatif. Lorsque vous devez enfreindre cette règle, lisez les instructions de l'interface utilisateur Windows:
Eh bien, NON . Arrêtons avec cette approche s'il vous plaît. Nous vous voulons. Tu nous veux. permet de se remercier et de se plaire plus sérieusement.
En général, non, car une utilisation excessive du mot commence à perdre son impact. Dans les cas où vous avez besoin que l'utilisateur fasse quelque chose en dehors du flux de travail normal, ou lorsque vous lui demandez de prendre une mesure extraordinaire (comme envoyer une capture d'écran avec un rapport de bogue), utilisez alors 's'il vous plaît' pour adoucir le inconvénient.
En général, je dirais non, mais cela dépend de la personnalité que vous souhaitez vous donner. Si vous visez un produit très convivial. Par exemple, quelque chose comme Boissons innocentes . Ils personnifient souvent leurs produits et utilisent un langage beaucoup plus convivial. Par exemple, ils peuvent dire "Attention quand tu me sors du micro-ondes, je peux être un peu chaud".
Pour résumer d'un point de vue purement utilisable, je garderais toujours le message court et précis. MAIS il peut y avoir des cas où la personnalité/marque du produit est plus importante.
Ne dis rien. Tournez ces champs en rouge et secouez/flashez-les pendant une seconde.
Les messages d'erreur doivent être aussi courts et concis que possible, sauf si vous essayez d'être drôle.
Dans ce cas, essayez quelque chose comme ceci:
"Vous avez laissé le champ de nom vide, vous engourdi. Vous attendez-vous vraiment à aller quelque part sans le remplir?"
-
Cependant, ce genre de chose est vraiment une chose mineure, une chose bien pire à faire est de ne pas être spécifique avec vos messages d'erreur. S'il y a 12 champs à remplir et que vous n'indiquez pas clairement à l'utilisateur quels champs sont à l'origine du problème et pourquoi, vous pouvez prévoir que l'utilisateur souhaite tuer le programmeur/l'entreprise qui a produit le logiciel. Pire encore, lorsque les bons champs sont anéantis et qu'ils doivent tout retaper, car ils se sont trompés sur un seul champ. C'est ce qui devrait nous inquiéter, car nous voyons que cela arrive trop souvent dans trop d'applications.