Les messages d’erreur sont à bannir
Error Messages Are Evil
Librement traduit et adapté d’une tribune de Don Norman / http://ow.ly/xVht3
L es messages d’erreur sont à bannir : ils punissent les utilisateurs de ne pas avoir le même comportement que les machines. Laissons les gens se comporter comme des gens ! Quand un problème apparait, nous devrions l’appeler “erreur machine”, et non “erreur humaine” : L’application/Le site/Le logiciel a tout simplement été mal designé, et nous oblige à se conformer à ses exigences -très- particulières. Il serait donc temps de concevoir et de réaliser des interfaces qui se conforment à nos exigences, nous utilisateur.
Arrêtons d’être en conflit : Collaborons !
Je déteste les messages d’erreur.
Ils sont insultants, condescendants, et surtout, totalement inutiles. De petites choses malsaines et diaboliques. Elles nous forcent à effectuer des tâches inutiles, et détruisent le plus souvent tout le travail que nous venons tout juste d’effectuer.
“Mais”, demande le développeur, “Comment éviter les messages d’erreur, surtout dans le cas où, justement, l’utilisateur fait une erreur ?”
“ L’utilisateur” ? Déjà, arrétez de m’appeler comme ça : Je suis une personne, une personne bien vivante, avec des émotions. Donc supprimez le mot “utilisateur”. Hello, nous sommes des gens. Les gens font des erreurs ? Mais à qui est-ce la faute ? C’est aujourd’hui le plus souvent celle de l’ordinateur, de l’application, ou, en réalité, celle des personnes qui l’ont conçue ou développée.
Les professionnels de la technologie savent exactement comment créer des systèmes précis et détaillés. Et effectivement, c’est surement très bien d’un point de vue des machines, mais est ce vraiment adapté aux humains ? Les gens sont globalement mauvais en ce qui concerne la précision et les détails. Ils sont mauvais pour se concentrer sur des trucs ennuyeux pendant de longues minutes. Nous forcer à utiliser ces systèmes, à agir et penser comme des machines ne peut qu‘aboutir à nous faire faire des erreurs. Vous l’appelez “erreur humaine” : Je l’appelle pour ma part “erreur machine”, ou, si vous préférez, mauvais design.
Mais pourquoi ne pas créer des systèmes pour les gens ?
Eliminez les messages d’erreur. Remplacez les par des messages collaboratifs. Prenons comme exemple le message d’erreur en haut de l’article. Je souhaitais changer un nom de fichier. De plus, je voulais que ce fichier apparaissent tout en haut de la liste selon un classement par ordre alphabétique, d’où ma décision de mettre un point au début du nom. J’ai soigneusement écrit un long nom de fichier, “.Template for working documents”, commençant par un point, en croyant que cela forcerait le système a classer les fichiers selon un ordre que j’ai choisi, et non un ordre choisi par lui.
“Mauvaise réponse” me dit Apple, “Commencer le nom d’un fichier par un point est notre petit secret pour structurer les fichiers système. Vous ne pouvez donc pas l’utiliser : Merci de recommencer depuis le début.” Et il en profite pour jeter tout mon travail.
Ce n’est pas très constructif, Apple. Et moi qui pensais que vous étiez l’entreprise qui comprenait le mieux les gens. Comment suis-je censé connaitre tous vos petits secrets ? Et quand bien même je me soit loupé, à cause de vos obscurs standards, pourquoi annuler ma progression ? Pourquoi ne pas juste me laisser la réparer ?
Voici à quoi pourrait ressembler un message de type collaboratif :
Désolé, mais vous avez commencé le nom de votre fichier par un point, or ce type de nomenclature est réservé aux fichiers système. Vous devriez commencer avec un caractère alphanumérique ou un symbole autre que le point : Merci de modifier le nom du fichier et cliquez sur “Sauvegarder”.
(Et tout le texte que j’ai soigneusement écrit resterait visible, me permettant de modifier cet affreux point interdit, tout en effectuant d’autres modifications, directement dans le champs du message !)
Et encore, ce n’est toujours pas la meilleure façon de faire les choses. Un vrai système collaboratif me donnerait quelques recommandations avant de renseigner le nom du fichier. S’il y a une façon particulière dont vous voulez nommer le fichier, que le système me le dise avant, et pas après. Combien de fois devrons nous encore subir l’affront, après avoir écrit un long nom de fichier, de se le voir refuser à cause des caprices de l’ordinateur (Plus précisément, des caprices du développeur) ?
D’autres situations où l’on retrouve ce type de “philosophie” ?
Facile.
Que pensez vous de la fois où l’on vous demande de choisir un nouveau mot de passe, et après une longue réflexion où vous en définissez un soigneusement, on vous dit que vous n’avez pas assez de caractères, de minuscule ou majuscule, de chiffres, et bien sur, quand vous tentez de le valider, on vous indique qu’un des caractères choisi n’est pas permis.
Que pensez vous aussi de la fois où l’ordinateur vous indique la bonne façon d’écrire un numéro de téléphone ou une date seulement après l’avoir renseigné, pour se rendre compte que le format attendu correspond à la logique du développeur (ou plus vraisemblablement au minimum de travail à fournir) et non pas celui universel des utilisateurs.
Que pensez vous de … Bref, vous voyez l’idée.
Alors, comment faire évoluer ces pratiques ?
Nous pestons contre les machines qui nous réprimandent, plutôt que d’essayer de collaborer. Il faut impérativement se concentrer sur une philosophie de design centré sur les humains. Arrêtons ce terme, “ Erreur humaine”. Ce terme veut en réalité dire dans la plupart des cas “Mauvais design”, ou mauvaise expérience, qui résulte irrémédiablement sur une erreur humaine. Obligez les gens à faire des actions peu logiques pour eux, et ils vont faire des erreurs. (Comme par exemple, ne pas leur dire comment faire quelque chose avant qu’ils l’aient fait, afin de les gronder ensuite).
Les messages d’erreur sont à bannir : ils punissent les utilisateurs de ne pas avoir le même comportement que les machines. Laissons les gens se comporter comme des gens ! Quand un problème apparait, nous devrions l’appeler “erreur machine”, et non “erreur humaine” : L’application/Le site/Le logiciel a tout simplement été mal conçu, en nous obligeant à se conformer à ses exigences -très- particulières. Il serait donc temps de designer et réaliser des interfaces qui se conforment à nos exigences, nous utilisateur.
Arrêtons d’être en conflit : Collaborons !
*****
English version :
Error messages punish people for not behaving like machines. It is time we let people behave like people. When a problem arises, we should call it machine error, not human error: the machine was designed wrong, demanding that we conform to its peculiar requirements. It is time to design and build machines that conform to our requirements. Stop confronting us: Collaborate with us.
I hate error messages. They are insulting, condescending, and worst of all, completely unnecessary. Evil, nasty little things. They cause us to do unneeded work, and often destroy the work we have already done.
“But,” programmers will ask, “how can we eliminate error messages, especially when the user has actually made an error?”
The “user”? Stop calling me that: I’m a person, a living breathing person, with feelings. Get rid of the word “user.” Hey, we are people. So people make errors? Whose fault is that? Usually its the computer’s, the system’s, or, in actuality the people who designed or programmed it.
Our technology is designed by technologists who know what is good for that technology, namely highly precise, accurate, detailed information. Well, that may be good for machines, but what about what is good for people? People are bad at precision and accuracy. At monitoring dull stuff for long periods. Force us to do those things, to act like machines, and of course we will fail. You call it human error: I call it machine error, or if you prefer, bad design.
Why not make the system for people? Eliminate error messages. Replace them with collaborative messages. Consider Apple’s error message at the start of this essay. I had a filename that I wished to change. Moreover, I decided I wanted it to appear at the top of the alphabetical listing of files, so I decided to make the first character a period (which Apple calls a “dot”). I carefully typed a long new file name, “. Template for working documents” starting it with a period, believing that this would force the machine to order the file names the way I wanted them to be, not the way it wanted to do it.
“Bad, bad,” says Apple, don’t you know better? Starting a file with a dot is our secret way of marking system files. You can’t do that: start all over again.” And then it rudely discarded all my work.
That’s not very helpful, Apple. And here I thought you were the company that understood people. How am I supposed to know your secrets? And even if I did do it wrong by your obscure standards, why did you discard my work? Why not let me fix it?
What would a collaborative message look like? Like this:
Sorry, but you started the file name with “dot” and files that start with a dot are restricted for system use. You may start with any alphanumeric character or symbol except for dot: please edit the file name and hit “save.”
(And the stuff I so carefully typed would be there, allowing me to get rid of the offending “dot” and make any other modification I wished, Right there in the message!)
That’s still not the best way to do things. A truly collaborative system would tell me the requirements before I did the work. If there are special ways you want stuff entered, tell me before I enter it, not afterwards. How many times must we endure the indignity of typing in a long string only to be told afterwards that it doesn’t fit the machine’s whims (more accurately, doesn’t fit the whims of the programmer)?
Where else can this philosophy be applied? How about in the entering of new passwords, where after much thought you enter a carefully generated one, only to be told that it doesn’t have enough characters, or lacks upper and lower case both, digits, or non-numerical characters, and of course when you supply these, then you will be told that that particular character is not allowed. Or how about the entry of phone numbers or dates where you are only told the proper format after you have entered it the way the entire world understands except for this computer program, whose programmers wanted it in a way that was the least amount of work for them?
Or how about …. Well, you get the idea.
How do we manage this change? Cast shame on systems that scold rather than collaborate. Insist on a people-centered design philosophy. Get rid of the term “human error.” That term almost always really means “bad design,” or such awful procedures that human error is almost guaranteed. Force people to do inhuman things and they will make errors. (Like not telling them how to do something the way you want until after they do it the way you don’t want, so you can scold them.)
Error messages punish people for not behaving like machines. It is time we let people behave like people. When a problem arises, we should call it machine error, not human error: the machine was designed wrong, demanding that we conform to its peculiar requirements. It is time to design and build machines that conform to our requirements. Stop confronting us: Collaborate with us.
*****
Don Norman wears many hats, including Director of the newly formed program, Design at UC San Diego, cofounder of the Nielsen Norman group, professor (Harvard, UC San Diego, Northwestern, KAIST, Tongji), business exec (former VP at Apple, executive at HP, and now cofounder of a startup), on company boards and company advisor, and author of best-selling books on design: Emotional Design, Living with Complexity, and Design of Everyday Things. Learn more at jnd.org.
