👎 ArrĂȘtez avec les erreurs humaines !

Un article sur le design, mais aussi sur l’attitude toxique qui consiste Ă  dĂ©fendre le produit, le systĂšme / le programme au dĂ©triment de l’utilisateur qui serait trop « stupide » ou « distrait » pour savoir l’utiliser.

👎 ArrĂȘtez avec les erreurs humaines !

Un article sur le design dans la nouvelle séries sur les fondamentaux du Design "Design Essentials Series" que l'on va développer sur 5 ou 6 articles en fonction de l'inspiration.

Mais aussi et surtout traitant de l’attitude toxique qui consiste Ă  dĂ©fendre le produit, le systĂšme / le programme au dĂ©triment de l’utilisateur qui serait trop « stupide » ou « distrait » pour savoir l’utiliser.

Gif représentant une animation d'un utilisateur ne sachant pas se servir d'un verre d'eau
VoilĂ  comment certains ingĂ©nieurs, dĂ©veloppeurs et mĂȘme designers voient les utilisateurs. Il faut arrĂȘter.

DONC NON

Donc NON, ce n’est pas l’utilisateur qui est dĂ©bile, ce n’est pas son niveau d’étude, sa maniĂšre de penser ou quoi que ce soit d’autre qui fait que le fruit de la crĂ©ation d’un ingĂ©nieur, designer ou dĂ©veloppeur est « mal utilisĂ© » ou produit des erreurs.

C’est bien le systĂšme, le processus oĂč l’outil qui est mal conçu.

C’est souvent le cas lorsqu’un accident survient, une commission d'enquĂȘte va vĂ©rifier si le problĂšme vient de la machine, puis si le problĂšme vient d’une « erreur humaine » et s'il s’avĂšre que c’est une mauvaise manipulation humaine alors on s’arrĂȘte lĂ  !

C’est bon, c’est la faute de l’humain, donc aucune remise en question de la machine qu’il opĂ©rait alors, du systĂšme ou du logiciel.

Prenons un exemple

Prenons l’exemple tout bĂȘte du site de votre banque prĂ©fĂ©rĂ©, imaginez que vous faites l’erreur de faire un 💾 virement sans le vouloir Ă  la mauvaise personne. C’est votre faute !

Vous ĂȘtes sĂ»r ?

Si on creuse un peu, on se rend compte :

  • Que la liste dĂ©roulante qui permettait de choisir le destinataire du virement n’est pas triĂ© par ordre alphabĂ©tique
  • Que le nom du destinataire est affichĂ© en gris sur blanc trĂšs peu lisible
  • Pour terminer, aucune confirmation de virement n’a Ă©tĂ© demandĂ©e !
Alors est-ce toujours de votre faute ?

Non, c’est le rĂ©sultat d’un mauvais design.

Ce genre d’exemple est tout autant applicable Ă  des objets physique. Un mauvais placement de bouton, un mapping incomprĂ©hensible, des indices sonore incohĂ©rents comme un « bip » de danger similaire Ă  un « bip » de confirmation.

Le mapping c’est, notamment, l'emplacement des contrĂŽles correspondant Ă  ce qu’ils contrĂŽlent physiquement sur un objet. Cela permet de crĂ©er une reprĂ©sentation mentale du systĂšme contrĂŽlĂ©. Exemple : les boutons de votre plaque de cuisson on un bon mapping s'ils sont placĂ©s dans la mĂȘme configuration que les plaques qu’ils contrĂŽlent.

Comment j'en suis venu Ă  cette conclusion ?

Malheureusement Ă©tant dĂ©veloppeur et designer, j’ai trop souvent assimilĂ© le besoin de m’adapter Ă  la machine plutĂŽt que l’inverse.

Mais ça, c’était avant d'acquĂ©rir un Mac en 2014. Ma vision a dĂšs lors complĂštement changĂ©e, lĂ  oĂč j’étais habituĂ© Ă  faire 50 dĂ©tours, passer par 10 paramĂštres systĂšmes, 2 re-dĂ©marrage, perdre 1 Ă  2 secondes par manipulation inutiles sous Windows pour rĂ©aliser une tĂąche, sous Mac cela a disparu.

Je me suis rendu compte qu’un systĂšme pouvait ĂȘtre pensĂ© pour l’utilisateur, et pas l’inverse (Ă  l’utilisateur de modeler sa pensĂ©e pour le systĂšme). C'est souvent le reproche qui est fait Ă  l'informatique "c'est trop compliquĂ©"
Une mauvaise conception, haters gonna hates

J'ai montré cela à des étudiants, certains était d'accord sur le fait que Windows avait un mauvais design qui augmentait les chances de faire des erreurs, mais aussi le temps que l'on met à effectuer une tùche.

D'autres en revanche m'ont exprimĂ© Ă  quel point, ils Ă©taient habituĂ© Ă  cette incohĂ©rence et qu'ils y Ă©taient mĂȘme attachĂ©.

Alors pourquoi ?

C'est un sujet vaste, selon moi il y a attachement quand il y a apprentissage, s'il y a apprentissage c'est que c'est mémorable, et donc que c'est pas instinctif et intuitif, par conséquent mal conçu. Mais il peut y avoir un attachement pour quelque chose de bien conçu, justement parce que c'est bien conçu. Vous avez 4H.

Revenons en au concret : autant c'est sympa de bidouiller, trifouiller, apprendre, faire des dĂ©tours pour contourner une mauvaise conception quand on a le temps.  Autant lorsque l'on doit effectivement utiliser un outil (ici un OS mal conçu) pour travailler et gagner sa vie, lĂ  ça devient beaucoup moins drĂŽle de ressentir de la friction. Perdre du temps, faire des dĂ©tours ou apprendre 3 ou 4 fois la mĂȘme manipulation en fonction du style d'interface (en Metro UI, en Fluent design, en version Windows 98, etc.)

En design on cherche le "Flow", l'inverse de la friction, je ferais un article sur ce concept plus tard, tellement c'est intéressant et vaste.

Si vous voulez allez plus loin sur les problĂšmes de design de Windows, c'est par ici.

Alors non, vous n’ĂȘtes pas "mauvais en informatique" c'est l'informatique qui est mauvais avec les humains.

Le mĂȘme phĂ©nomĂšne de prise de conscience est survenu lorsque j’ai changĂ© de voiture. Je suis passĂ© d’une marque française Ă  une marque Allemande, et WOW. En fait, la voiture peut ĂȘtre truffĂ©e de petites choses qui facilitent la vie ! Des commandes agrĂ©ables Ă  utiliser, une position de conduite confortable, des rĂ©glages intuitifs et tout simplement pas besoin de temps pour prendre en main le vĂ©hicule et avoir du plaisir Ă  le conduire.

Il y a donc bien plusieurs niveaux de design, plusieurs façons d’apprĂ©hender un objet et surtout de meilleures conceptions que d’autres.

C’était ma rĂ©flexion sur le moment, maintenant j’en suis clairement convaincu aprĂšs avoir lu plusieurs livres qui traitent du sujet.

Ce qui a fini de me convaincre, c'est le super livre "The Design Of Everyday Things" par Donald A. Norman que TOUT designer, développeur et ingénieur qui prend son travail au sérieux devrait avoir lu. SincÚrement.

📒 Pour l'acheter sur Amazon c'est ici

Dans le livre Don. A. Norman parle notamment du Swiss Cheese Model of incident, que l'on peut traduire par "Le modÚle du gruyÚre", et c'est totalement ce phénomÚne d'aveuglement des multiples causes d'un problÚme. Lorsque l'on a trouvé 1 cause, on oublie de chercher les autres facteurs qui sont pourtant présents et qui ont bien eu une influence, on oublie la prise de recul et le contexte en somme.

Tout ça est fascinant, et on compte bien continuer à écrire des articles sur les sujets Design dans l'avenir chez Async.

P.S : Merci Ă  Fanny et Nadia pour les corrections :)

Commentaires

Connectez vous ou devenez un membre de Async pour rejoindre la conversation.
Entrez un mail ici pour recevoir un lien de connexion, super simple âšĄïž