Messages tels que «Opération réussie»: le mot «succès» est-il vraiment nécessaire?
Nous le voyons partout: des requêtes de base de données aux paniers, le message "Opération X avec succès terminée" est omniprésent. Mais la Parole "avec succès" est-elle vraiment nécessaire?
Existe-t-il un moyen de sans succès terminer une transaction par carte de crédit?
Votre transaction de 1 346 353,82 $ US a été sans succès terminée. Votre compte a été débité mais le vendeur n'a pas reçu l'argent. Maintenant que l'argent est piégé dans un trou noir.
Comment pensez-vous que le mot "avec succès" affecte l'expérience utilisateur? Est-ce quelque chose qui devrait disparaître, ou est-ce bien d'avoir réellement la Parole dans les messages?
Répondez "Non". "Avec succès" peut être supprimé:
Joel Spolsky a très bien couvert cette question ici:
http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
La règle de base est la suivante:
"En fait, les utilisateurs ne lisent rien.
Cela peut sembler un peu dur, mais vous verrez, lorsque vous effectuez des tests d'utilisabilité, qu'il y a pas mal d'utilisateurs qui ne lisent tout simplement pas les mots que vous mettez à l'écran. Si vous affichez une boîte d'erreur quelconque, ils ne la liront tout simplement pas. Cela peut être déconcertant pour vous en tant que programmeur, car vous vous imaginez mener une boîte de dialogue avec l'utilisateur. Hé, utilisateur! Vous ne pouvez pas ouvrir ce fichier, nous ne prenons pas en charge ce format de fichier! Pourtant, l'expérience montre que plus vous mettez de mots dans cette boîte de dialogue, moins il y aura de gens qui la liront. "
C'est une extension du principe "Ne me faites pas penser" - ou dans ce cas "Ne me faites pas lire" car les utilisateurs évitent de dépenser de l'énergie mentale.
Il y a un autre problème avec le mot "réussi" que j'ai rencontré dans notre SaaS. Nous fournissons une fonction dans notre application, où vous pouvez envoyer des trucs par e-mail. Cependant, la seule chose que nous faisons est d'envoyer l'e-mail. Le message était "E-mail envoyé avec succès". Les commentaires des utilisateurs nous ont ensuite fait comprendre qu'ils avaient plus ou moins mal compris car ils pensaient que l'e-mail avait également été réussi remis! J'ai donc changé le texte en "Email envoyé". Ils ne parviennent toujours pas à livrer (démon de messagerie, etc.) et les utilisateurs ont toujours ce problème. Cependant, ils ne se plaignent plus d'être dupés par un "mauvais" feedback du système.
Et pour le cas dans son ensemble: Cette chose "réussie" me rappelle beaucoup l'exemple "Enregistrer le fichier" de Coopers. Les programmeurs (surtout involontairement) révèlent leur modèle cognitif du code/de la base de données/de la machine dans ces messages, mais vous ne pouvez pas vous attendre à ce qu'un utilisateur ait les mêmes connaissances à ce sujet. L'utilisateur attend la machine fonctionne correctement. Pour entrer dans un niveau UX élevé, je dis: Ne laissez pas la machine avoir des moments de succès, demandez aux utilisateurs de les avoir! (== se débarrasser de tous les "succès" dans les commentaires de votre système s'ils se réfèrent à la machine)
Je vais être en désaccord avec les autres et dire que parfois la Parole avec succès est significative.
Je suis d'accord que dans de nombreux cas, il est redondant et dans ces cas n'est pas nécessaire, mais il y a des cas où il est utile.
Généralement, cela s'applique dans les cas de réussite partielle ou dans les cas où vous pouvez vous attendre à une erreur.
Par exemple, si vous validez un disque dur, la validation est "terminée" une fois l'analyse du disque terminée. Il est "terminé avec succès" lorsqu'il a terminé l'analyse du disque mais n'a trouvé aucune erreur.
De même, si vous avez un processus en masse (l'envoi de 1000 e-mails) peut "se terminer avec succès" si tous les 1000 ont été envoyés, mais "terminer avec des erreurs" s'il a essayé d'envoyer tous les 1000 mais certains ont échoué.
Comment pensez-vous que le mot "avec succès" affecte l'expérience utilisateur? Est-ce quelque chose qui devrait disparaître ou est-il correct d'avoir réellement la Parole dans les messages?
Ambiguïté
"L'opération X terminée" peut être ambiguë, par exemple: les travaux Microsoft SQL Server produisent des messages comme celui-ci lorsqu'un travail échoue. Étant donné que le message n'implique pas toujours un résultat réussi dans une ou plusieurs applications, je ne peux pas entièrement faire confiance à ce message dans d'autres applications.
Incertitude
Les utilisateurs qui n'ont pas rencontré un tel scénario terminé = échoué peuvent ne pas sentir que le message est ambigu et donc assimiler `` terminé '' avec succès, mais les utilisateurs qui l'ont vécu peuvent l'associer à l'incertitude.
Scannabilité
Pour éviter la possibilité d'incertitude, j'opte pour le positif explicitement positif et intrinsèquement "scannable" " Succès - Vos modifications ont été enregistrées " (ainsi qu'un vert doux teinte de fond du message, le cas échéant). Cela permet à la majorité des utilisateurs de "ne pas me faire réfléchir"/TL; DR de numériser un mot, ou même simplement de remarquer la couleur s'ils le peuvent, puis de s'éloigner du reste du message en sachant ce qu'ils a vraiment fonctionné. "L'opération X terminée" ou "l'opération X terminée avec succès" sont toutes deux moins "scannables" pour un résultat positif, ergo, nécessitent plus de réflexion.
"Je peux imaginer que vous pouvez amener les utilisateurs à lire en fournissant de bonnes étiquettes de bouton. Si l'étiquette de bouton est toujours" OK "alors oui, personne ne lira quoi que ce soit et cliquera simplement. Si vos étiquettes de bouton fournissent l'action ou en O/N dialogues quelque chose comme "Oui, faites-le de toute façon", vous avez probablement plus de chances que les gens lisent le texte ci-dessus (l'utilisateur pense: "de toute façon? attendez ... faites quoi ... pourquoi de toute façon ... ce qui est dans tout le texte du dialogue. .. ")"
C'est vrai! Dans une situation détendue, un utilisateur ne lira jamais ces fenêtres contextuelles. Mais s'il voit quelque chose d'alarmant - alors ils concentrent leur attention sur la boîte de dialogue. En gros société de développement de logiciels personnalisés ils ont des départements QA pour tester non seulement les performances d'un programme mais aussi le comportement des utilisateurs.
Éditer
J'ai oublié de dire - je n'écrirais pas "réussi", c'est irritant.
En parlant à un utilisateur final, je ne vois aucune action infructueuse "et" terminée. Pas avec ces mots de toute façon.
Mais je tiens à souligner qu'il est "logique" dans certains cas. Lorsque vous effectuez des appels asynchrones par exemple dans la programmation, il y a une nette différence entre le succès, l'erreur et la fin. Un appel sera toujours terminé, bien que réussi ou erroné.
Je ne peux pas immédiatement penser à un exemple où cela pourrait s'appliquer en parlant aux utilisateurs finaux. Je n'utiliserais pas non plus un mot comme "complet" avec une nuance positive pour donner une rétroaction négative. `` Votre soumission est terminée sans succès '' donne des commentaires négatifs, mais beaucoup de gens ne verront jamais le `` non '' avant le `` succès '' ...
Je crois que la réponse de PhilipW reflète cela, si je l'ai bien lu. En tant qu'utilisateur moi-même, j'ai tendance à ignorer tout le texte et à rechercher tout mot disant "complet - succès - ..." et je cliquerais probablement sur OK chaque fois que le texte contient terminé à tout moment.
Pour compléter la réponse de Phillips, le seul moment où un utilisateur a besoin de lire des informations dans un système de vérification serait lorsqu'un événement atypique s'est produit.
Ainsi, par exemple, dans une action réussie, le seul indicateur dont un utilisateur a besoin est de savoir que tout s'est déroulé comme prévu. Même quelque chose d'aussi simple que le texte "Complete" ou "Thanks" avec soit une case à cocher verte, soit dans une boîte entièrement verte serait suffisant pour faire savoir à l'utilisateur que tout va bien (même si je pense que complete est peut-être trop ambigu et que l'ajout de certains l'indicateur d'une transaction serait utile).
La seule fois où un utilisateur aura besoin d'informations supplémentaires ici, c'est lorsque quelque chose d'atypique se produit, comme si sa carte de crédit est refusée ou si la transaction échoue en raison d'une vérification, d'une adresse ou d'une erreur de serveur. Dans ces cas, je voudrais en tant qu'utilisateur une description des raisons pour lesquelles il y a eu un hoquet et voir si c'était une erreur stupide de ma part qui pourrait être corrigée.
Dans l'ensemble, c'est une forme de divulgation progressive où vous devez dire à l'utilisateur ce qu'il doit savoir, uniquement lorsqu'il en a besoin. Pour cette raison, je conviens que "avec succès" dans une action réussie est assez redondant.
Mon avis sur votre phrase spécifique:
"L'opération s'est terminée avec succès" est que le mot successfully n'est pas nécessaire car le completed a déjà intrinsèquement sur lui le sens d'avoir du succès.
Si votre phrase était
"Opération réussie"
ou
"Opération réussie"
Je ne supprimerais pas le mot successfully.
Oh, vous manquez quelque chose d'essentiel ici: Conception émotionnelle
À strictement parler, la Parole peut être omise.
Il n'ajoute vraiment aucune information utile au contexte - mais il ajoute une voix. Je pense que le développeur voulait avoir l'air amical et rassurant quand il a écrit ce message. Retirez tout doute et ne sonnez pas comme un message mort d'une solution informatique froide et purement fonctionnelle.
Pendant des années, l'idéal a été de garder le message court et simple. Et en effet, avoir un test précis et sans ambiguïté c'est important, mais cela affecte la voix et le ton du message.
MailChimp est un excellent exemple de "ton et voix" réussis.
Ils ont soigneusement étudié divers scénarios d'utilisation et créé un message basé sur les sentiments de l'utilisateur dans ces situations.
Par exemple.
Source (et plus d'exemples): http://voiceandtone.com/
Donc. Conclusion ...
Le mot lui-même n'ajoute peut-être rien d'utile au message, mais il aide certainement à construire une voix et un ton.
Lorsque vous discutez de l'opportunité de l'inclure ou non, cela dépend vraiment de l'endroit dans la hiérarchie UX où se déroule la discussion. Si nous discutons de fonctionnalités pures, alors bien sûr: supprimez le mot. Si nous montons de quelques niveaux et discutons de la "jouissance", alors il pourrait avoir une fonction et pourrait être superficiel.
Source: http://www.smashingmagazine.com/2012/07/18/the-personality-layer/
J'écris ceci comme une réponse, car sinon ma question serait basée sur l'opinion.
Je pense que les développeurs écrivent de tels messages d'erreur parce qu'ils savent qu'une opération particulière peut échouer de mille façons. La plupart du temps, le développeur de code écrit des centaines de conditions qui peuvent faire échouer l'opération. C'est un moment de réussite pour les développeurs d'écrire enfin ce message "opération réussie".
Si un utilisateur exécute une tâche simple comme enregistrer une publication en tant que brouillon, il doit recevoir les messages:
- En cas d'échec: " Désolé , impossible d'enregistrer votre brouillon" (et dites pourquoi: par exemple, panne de réseau, champs obligatoires manquants)
- Si elle réussit: "Votre brouillon a été enregistré"
Funny Word, réussi; J'avais l'habitude de faire beaucoup de Big Testing. J'ai commencé chaque présentation avec les mots "tous les logiciels sérieux ont des bogues. Notre travail consiste à les trouver. Si notre test a réussi, cela signifie que nous avons trouvé des bogues." Je n'ai jamais cédé à la tentation de dire "utile" ou "productif" ou quoi que ce soit.
Les gestionnaires ont tendance à penser qu'un test réussi n'a trouvé aucune erreur. Les utilisateurs pensent qu'une opération réussie s'est déroulée sans aucune erreur.
Si je suis un guichet automatique et que je découvre un problème et que j'avale la carte du client, je réussis, non?
Vous devriez peut-être dire "terminé sans erreur" si c'est ce que vous voulez faire passer.