[new:30/04/2011]Parler de code c’est bien, parler de patterns comme MVVM c’est encore mieux, mais parler de Design c’est aujourd’hui tout aussi essentiel. C’est pourquoi j’aborde le sujet régulièrement… Aujourd’hui je vous propose de faire le point sur la création des interfaces, l’importance de cette tâche, les motivations de ce mouvement inéluctable.
La fin d’un mythe, le début d’une aventure
La première chose à comprendre et à admettre c’est que notre beau métier qu’est l’informatique a eu tendance ces dernières décennies à laisser croire à certains qu’ils étaient un peu les “maitres du monde”. C’est un peu vrai… Sans nous, sans notre code, le Monde ne serait pas aujourd’hui tel qu’on le connait : pas d’Airbus ni d’avion de chasse in-pilotable sans ordinateur, pas d’Internet ni de Web 1 ou 2, pas d'IPhone, ni d’Ipad, pas d’information en temps réel, pas de Webcams aux quatre coin du monde, rien, pas même de distributeur de billets, pas de CD, ni de DVD, pas de GPS. Rien. Enfin si, le monde tel qu’il était à la fin des années 50.
Bref dans ce monde de l’information, l’informaticien était un petit roi. Enfin, les électroniciens vous diront que ce sont eux les vrais maitres du monde, sans circuits intégrés, notre métier n’existerait même pas (enfin si, mais cogiter toute la journée sur la beauté algorithmique de programmes virtuels sur une machine de Turing purement idéale n’aurait pas pu changer le Monde).
La vraie cassure conceptuelle, le vrai nouveau paradigme “à avaler” c’est que depuis quelques années l’informaticien est devenu un OS des temps modernes (sans double jeu de mot, ou presque).
Mais il y a encore plus grave : la chute du petit roi ne s’arrête pas là, les vrais maitres du monde aujourd’hui en matière de technologie ce sont les Designers !
L'IPhone offre-t-il une meilleure écoute que la concurrence ? non. Offre-t-il une meilleure couverture géographique ? non. Offre-t-il des fonctions téléphoniques plus évoluées que la concurrence ? non. Les problèmes d'antenne des modèles récents, tout comme le fait qu'on reconnait un utilisateur iPhone au fait que c'est celui qui se trimbale avec son chargeur et cherche une prise électrique dès qu'il arrive chez vous, démontrent même que, comparé à la concurrence, les Smartphones Apple, en tant que téléphone, sont nettement de qualité moindre. Pourtant les points évoqués sont vitaux pour un téléphone ! Non, il ne fait rien de tout cela mieux que les autres (et c’est même plutôt l’inverse !). Même côté musique, mon vieux téléphone Sony fait mieux : lecture de tous les mp3, carte SD interchangeable, pas d’obligation de passer par un market place, pas de DRM... Mais l’iPhone a un Design (et la posture markéting qui va avec). Et ce n’est qu’un exemple parmi des milliers. On pourrait parler des voitures qui se vendent mieux que les autres, et de mille objets, de la cafetière aux couverts de table, qui eux aussi sont tombés sous la domination du Design. Ce qui a fait le succès d’un Ikea sur ces concurrents "low cost" ? … Le Design.
De Charybde en Sylla, notre pauvre informaticien ne cesse donc de dégringoler de son trône !
Alors certains changements se font dans la douleur au lieu de se faire dans la joie. Il y a de la résistance, du passéisme, on devient réactionnaire, méfiant, traitant tout changement de “mode” pour en minimiser l’impact et l’importance, vénérant des dieux déchus, des langages oubliés. En un mot on se ringardise.
Heureusement il existe une issue plus heureuse ! N’oublions pas cette pensée sublime de Cocteau “Puisque ces mystères me dépassent, feignons d’en être l’organisateur”. Le même disait aussi “L’avenir n’appartient à personne. Il n’y a pas de précurseurs, il n’existe que des retardataires.” ce qui, quand on en prend la mesure est à la fois d'une profondeur inouïe et un éclairage optimiste sur notre potentiel créatif : il nous suffit de vivre avec notre temps pour ne pas être ringard et pour passer pour des visionnaires... Mais nous sommes tellement englués dans le passé que même ceux qui croient vivre "au temps présent" se trompent : le présent n'existe pas, puisque dès qu'on l'évoque il s'agit déjà du passé.
Le poète est souvent un sage qu’on gagne à écouter…
Le rapport avec le sujet ? C’est que les Designers peuvent faire ce qu’ils veulent, ils ne sont rien sans la partie fonctionnelle ! Les informaticiens peuvent reprendre le dessus s’ils ouvrent les yeux, s’ils sortent de leur grotte et tombent la carapace. Un IPhone dont le contenu ne serait que fakes et démos et qui ne passerait aucun coup de fil “pour de vrai”, où les jeux ne seraient que des plans fixes comme des affiches alléchantes mais sans le film qui va avec et où les applications ne seraient que des dessins d’interface sous Photoshop, vous croyez que ça se vendrait ?
Non. Bien entendu. Personne n’achète un “concept”. Un utilisateur achète un produit fini qui marche.
Et pourtant dans un monde de Designers sans informaticien, l’IPhone ressemblerait à cette description et serait totalement inutile…
Deux vérités s’affrontent alors : sans fonctionnel, l’esthétisme et l’ergonomie ne sont que des mots, des concepts et des petits dessins sans utilité mais sans Design un logiciel n’est qu’une suite de fonctions et d’algorithmes austères qui n’intéressent personne. Quand deux activités sont aussi interdépendantes il est crucial de mettre en place les structures de productions ad hoc, c’est à dire celle mariant des spécialistes des deux mondes.
Le fonctionnel a encore son mot à dire, encore faut-il ne pas se laisser déposséder de ce pouvoir, quitte à savoir le partager avec ces nouveaux partenaires que sont les Designers...
Et si les informaticiens d’aujourd’hui ne sont pas les créateurs de cette grande tendance du Design, ils peuvent largement en être les organisateurs ! La maitrise du fonctionnel, la connaissance du besoin de l’utilisateur, aucun infographiste ne l’a. Aussi talentueux soit-il.
Quant au vrai métier de Designer, les quelques rares écoles qui existent préparent bien plus leurs étudiants au monde de l’industrie, à la conception de voiture ou de fourchettes que de logiciels.
De fait, un vrai “Designer en informatique” il ne doit y en avoir qu’une poignée dans le monde.
Pas assez, et trop chers pour que les entreprises, nos clients (ou patrons), ne puissent s’offrir leurs services. Dans 30 ans, peut-être...
Aujourd’hui le Design est surtout affaire d’infographistes qui se préoccupent d’ergonomie et d’informatique. L’esprit du graphiste, artiste, est souvent loin de celui de l’informaticien, logicien, ce qui rend de tels profils “mixtes” bien rares sur le marché. C’est d’ailleurs le même problème que le profil “d’intégrateur” sous Blend. Ne reste donc plus que des infographistes parfois talentueux mais ne connaissant rien à l’informatique et des informaticiens, parfois talentueux aussi, mais n’y connaissant rien à l’esthétique ni même aux simples règles de base de la mise en page... Ce sont ces deux groupes qui doivent s’allier, se rapprocher.
Certes il semble aussi difficile de faire apprendre l’art noble du Design à un informaticien que d’expliquer les merveilles de C# à un infographiste. Je vous l’accorde. Mais il n’est pas interdit d’avoir de l’imagination, et, avec les bons outils et les bons collaborateurs l’informaticien du 3ème millénaire peut fort bien devenir, enfin, le maitre du monde qu’il pensait être, ou tout du moins s’associer intelligemment avec les Designers pour accéder ensemble au trône…
Mais il reste à comprendre l’essentiel, le fait que le Design n’est pas un accessoire, pas plus qu’une mode, c’est un acte essentiel de la conception d’un produit, qu’il s’agisse d’une voiture, d’un fourchette ou d’un logiciel. Les Designers ne sont pas des putschistes venant nous voler la vedette, ce sont des alliés inespérés pour nous aider à conquérir de nouveaux utilisateurs et des marchés encore plus vastes !
Pour nous tout commence donc avec les interfaces graphiques…
Les interfaces utilisateur :
Pourquoi sont-elles si importantes ?
Parce que c’est la seule partie d’un programme que l’utilisateur peut voir et toucher !
N’oubliez jamais cela. Engluez dans votre code et ses mécanismes, vous ne voyez que lui, alors qu’il est invisible pour l’utilisateur ! N’importe qui peut ouvrir le capot de sa voiture et regarder le moteur, l’injecteur, le vase d’expansion, même si la personne en question n’y connait rien en mécanique elle peut au moins s’émerveiller devant la sophistication, la maitrise technique. Cela est impossible à faire avec un logiciel. Aucun utilisateur ne saurait utiliser un décompilateur et comprendre ce qu’il verrait et quand bien même le ferait-il, je vous assure que cela ne provoquerait chez lui aucun émerveillement, juste une franche répulsion devant tout un charabia sibyllin...
Ainsi, les interfaces sont essentielles parce que nous avons tous vu des applications qui possèdent des fonctionnalités incroyables mais qui ne connaitront jamais le succès à cause de leur mauvaise interface…
L’informaticien a toujours du mal à intégrer que l’utilisateur va peut-être être obligé de passer 8 heures par jour à se fatiguer sur une interface qu’il n’aime pas…
Les utilisateurs ne sont que des humains comme les autres et ils jugent souvent une application en quelques minutes (souvent moins!), juste sur une “première impression”. Ce premier contact aura un impact direct et immédiat sur la diffusion de l’application (sa vente, sa fréquentation si c’est un site Web…). Pire, tout cela se fonde presque uniquement sur l’interface utilisateur !
Nous sommes plongés, de gré ou de force, dans un monde d’images manipulées, un monde d’apparence où il devient presque impossible de différencier une image réelle d’une image fabriquée. En revanche, et à plus forte raison, habitués que nous sommes à des images “léchées”, aux filles aux jambes improbables et retouchées des magazines, il nous très facile de voir au premier coup d’œil un logiciel moche au look ringard !
Je connais la chanson pour l’avoir entendu milles fois : “les logiciels hyper lookés sont souvent vides fonctionnellement, moi j’ai fait un soft qui a la super fonction Z que personne n’intègre !”. C’est peut-être vrai, mais n’empêche, votre zinzin ne se vendra pas ! Le design d’une application n’est pas une option, c’est une évidence, une partie non négociable de sa fabrication. Le reste n’est qu’excuse pour tenter de rester vainement le maitre d’un monde mort qui n’existe plus…
L’utilisateur potentiel doit aussi percevoir une certaine familiarité, doit se sentir compris, et cela, l’interface peut le communiquer en quelques secondes mieux que 200 pages d’une documentation qu’il ne lira pas et qui tentera de lui faire comprendre la beauté de la fonction Z que personne d’autre n’implémente.
Il faut aussi prendre conscience que la plupart des utilisateurs compareront votre application à d’autres.
Souvent l’informaticien, très (trop ?) content de son idée oublie de regarder ce qui se fait ailleurs et comment cela est fait avant de commencer à coder. Croyez-vous que Nokia lance la fabrication d’un nouveau téléphone sans avoir démonté tous ceux de ses concurrents avant ? Qui eux-mêmes en ont fait autant. Interdit ou non, le reverse engineering est une pratique essentielle qui est souvent effectuée sous les noms plus feutrés de “Recherche & Développement” ou “Veille Technologique”. Mettez en place une telle stratégie ! Surtout que regarder et disséquer l’interface d’un produit concurrent ne viole justement aucune loi et que pour une fois, le code, on s’en fiche !
On entend parfois que l’informaticien ne serait pas dans une logique industrielle car l’industrie est un phénomène de masse alors que l’informatique est un travail intellectuel, presque une passion de geeks, de no-live, un “trip” ultra-perso. Mais c’est une vision dépassée de notre profession. Passer de cet isolement à un regard ouvert sur ce qui se fait ailleurs est un bon début pour améliorer l’interface de ses applications et devenir un informaticien qui vit avec son temps.
La démarche pour devenir de l’informaticien “du passé” un informaticien “du futur” est un voyage initiatique, une remise en question de ce que l’on sait et pense, une reformulation de ses propres croyances et vues sur le monde : une forme d’auto-psychanalyse indispensable.
Qu’est ce qui fait une bonne interface ?
S’il y avait une recette pour fabriquer des IPhones, tout le monde en vendrait sous toutes les marques. Hélas les “bonnes” interfaces sont comme les musiques qui rencontreront le succès, s’il y avait une “recette” cela se saurait depuis longtemps !
Mais en revanche si on ne sait pas dire exactement ce qu’il faut faire pour créer une interface à succès, on peut cerner les principales qualités qui font une bonne interface :
- Une bonne interface semble facile, l’application apparait intuitive sans lire de manuel;
- Une bonne interface est vendeuse, au premier contact;
- Mais elle se révèle aussi productive au fil du temps pour les utilisateurs avancés;
- Une bonne interface permet à l’utilisateur d’accomplir les tâches de la façon qu’il souhaite les accomplir et non en étant forcé de suivre une logique rigide imposée par le concepteur;
- Une bonne interface est cohérente. La cohérence doit s’étendre à toute l’application mais aussi à tout l’environnement de l’utilisateur et au cadre socio-culturel d’utilisation du logiciel.
Ce qui nous amène à poser quelques concepts de design, les bases indispensables.
Connaitre ses utilisateurs
Cela peut sembler idiot, mais le plus souvent l’informaticien, même talentueux et ayant une bonne idée de logiciel, n’a jamais vu ni rencontré les utilisateurs potentiels ! Je ne parle pas des informaticiens créant des logiciels dits “standard” comme des comptabilités, qui eux travaillent totalement isolés, presque à la chaine, dans un total isolement par rapport à l’utilisateur final.
Bien connaitre l’utilisateur final d’une application permet de définir les buts du Design de l’interface et peut modifier les lignes et la stratégie du développement lui-même.
Une application peut se destiner à des utilisateurs ayant des niveaux techniques et une habileté totalement différentes. Il faut en tenir compte et cela ne peut se faire qu’en connaissant parfaitement la cible concernée.
Une application peut être conçue pour des utilisateurs ayant un mode de pensée totalement différent du vôtre. Ne pas savoir comment l’utilisateur “fonctionne”, comment il pense, ses réflexes, ce qu’il aime, ce qu’il déteste, c’est passer à côté de l’essentiel et forcément prendre le risque de ne pas le séduire ni le satisfaire !
Les buts de l’utilisateur
Un utilisateur n’est jamais devant une application pour le “fun”. Ou alors c’est un informaticien et c’est une autre histoire… Un utilisateur se sert d’un logiciel pour accomplir une ou plusieurs tâches précises. Si c’est un jeu, ce n’est pas non plus pour le “fun” qu’il s’en sert, mais bien égoïstement pour se procurer du plaisir. Il n’y a pas d’acte gratuit chez l’humain.
Connaitre parfaitement ces tâches que l’utilisateur cherchera à accomplir permet de proposer des méthodes de travail en accord avec ses buts, sa façon de procéder, de penser. Le fameux sentiment de familiarité, de proximité que j’évoquais plus haut peut naitre de cette connaissance et de l’adéquation du Design avec cette dernière.
Un utilisateur n’aime pas se sentir “idiot”. Une bonne interface sait le guider s’il ne sait pas comment faire. Elle évite aussi les messages brimant du genre “Action interdite!” ou “Saisie non valide!”, les alertes rouge criard qui font peur. Ce sont pourtant des choses qu’on voit tous les jours !
L’utilisateur est parfois forcé d’utiliser un logiciel, auquel cas plus ce dernier saura le séduire, mieux cela sera, il vous sera reconnaissant d’avoir rendu son travail moins pénible et il plébiscitera votre produit. Mais souvent l’utilisateur choisit un logiciel lui-même c’est parce qu’il pense que cela va l’aider à faire quelque chose qu’il ferait mal ou moins bien sans l’aide d’un ordinateur et d’une application étudiée. Il ne faut pas le décevoir…
Les deux types d’utilisateurs
Il y a l’autonome et le survivant.
L’autonome prend sur lui les fautes et ne les rejette pas sur le système (téléphone, PC, logiciel…). Il sait apprécier les petits avantages et a tendance à minimiser les gros défauts. Il se débrouille. C’est le genre d’utilisateur qui, si vous lui montrer les faiblesses du système qu’il utilise vous dira “oui mais regarde, quand j’appuie là ça fait clignoter le clavier !”. Les informaticiens sont comme ça. C’est aussi le profil des “power users”.
Le survivant voit le monde autrement : lui il sait qu’il y a des problèmes dans le système mais ne sait pas comment les régler ni les contourner. Il aimerait d’ailleurs posséder un système plus simple, moins bogué, plus proche de ses besoins, mais il fait avec ce qui existe (ou avec ce qu’on lui a mis entre les mains). Quant au petit gadget qui fait clignoter le clavier, “même mon ours en pluche quand j’avais 4 ans savait faire mieux!”.
La grande majorité des utilisateurs appartiennent à cette seconde catégorie !
L’habileté
Les utilisateurs sont des débutants pendant une période qui est généralement très courte. Passé un certain cap, ils se contenteront des solutions qu’ils ont trouvées pour accomplir les tâches usuelles et n’iront pas chercher plus loin.
Seule une petite fraction minoritaire deviendra vraiment “expert”. Le genre d’utilisateur qui peut vous faire voir des raccourcis ou des astuces d’utilisation que vous-mêmes en tant que concepteur du logiciel n’avez jamais imaginés !
En fait, la majorité des utilisateurs seront dans la moyenne, c’est la courbe de Gauss qui s’impose avec son corolaire : une majorité dans le centre de la cloche, une minorité aux extrémités.
Quelques cas font exceptions à cette règle : les applications publiques, de type annuaire téléphonique ou distributeur de billets, et les applications que les utilisateurs n’aiment pas. Dans ces cas particulier la majorité des utilisateurs, toute tendance confondue, ne fera aucun effort pour comprendre le système et rejettera systématiquement la faute sur ce dernier.
Les schémas directeurs
Un utilisateur va approcher une application avec un certain nombre d’a priori, de réflexes, de schémas directeurs qui dépendent de ses connaissances passées relatives au domaine du problème traité par le logiciel.
Se fondant sur ces schémas, l’utilisateur va s’attendre, inconsciemment la plupart du temps, à ce que l’application suive un certain “modèle”, un certain “schéma de fonctionnement”.
Pensez à un comptable, lorsqu’on est passé des livres et journaux physiques à l’informatique il y a eu des grincements de dents… Un informaticien débutant est parfaitement capable de créer une comptabilité qui réclame des connaissances mathématiques du niveau 6ème (additions, soustractions, divisions et multiplications). Mais en revanche il n’est pas comptable et ne connait pas les habitudes des gens de cette profession. Les premiers logiciels de ce type ont reçu un accueil très mitigé. Et ce fut le cas de presque tous les logiciels de gestion à l’époque de l’explosion de la micro informatique en entreprise.
Pensez aussi à un médecin. Habitué à une relation personnelle avec son patient et à qui “le progrès” impose un “tiers” s’installant entre lui et le patient : l’ordinateur et le logiciel “médical”. Ayant fait partie des pionniers de cette branche particulière des logiciels verticaux dans les années 80 je peux vous garantir que les prévisions et les a priori de tous les informaticiens ont été balayés très vite lorsque leurs logiciels ont été confrontés aux utilisateurs !
Comment une consultation se déroule-t-elle, dans quel ordre un médecin traite-t-il le dossier du patient, combien de temps acceptera-t-il de passer à frapper sur le clavier alors que le patient se tient là, assis en face de lui ou allongé sur la table d’auscultation ? Comment va-t-il faire en visite ?
Les dossiers des patients en papier se transportaient facilement dans la mallette, on y écrivait deux lignes au chevet du patient et quand on remettait le dossier dans l’armoire en rentrant il était, par force, “à jour” automatiquement, sans manipulation, sans batterie à recharger, sans procédure de transfert... Si le patient téléphonait la secrétaire sortait son dossier de l’armoire pour lui répondre ou le transférait au médecin, aucun besoin de “synchronisation”, de “réseau”, de protocole sécurisé, de “portable”, d’onduleur… Quant aux “backups”, la photocopieuse utilisée par la secrétaire était parfaite, pas besoin de disques externes, de “scheduler” pour “programmer” les sauvegardes, de NAS, etc…
L’informatique médicale est au final une gêne plus qu’une amélioration !
Et cela reste vrai aujourd’hui, et donc fonctionnellement les logiciels modernes se sont adaptés en offrant nettement moins de possibilités “intelligentes” que ceux des pionniers. Il s’agit aujourd’hui pour la majorité de “gros bloc-notes” flanqués d’une version électronique du Vidal (le dictionnaire des médicaments) et surtout accompagné d’un module gérant la carte Vital (seul vrai argument ayant poussé les médecins à s’informatiser). D’une application résolument “scientifique” des débuts (allant même jusqu’à intégrer des systèmes experts) cherchant à apporter un soutien “intelligent”, voire une aide au diagnostic, nous en sommes arrivés à des fourres-tout électroniques gérant la relation comptable avec la Sécu. Le médecin n’était pas le “scientifique” qu’on imaginait, il n’avait pas le temps qu’on croyait pour s’occuper d’un logiciel en même temps que d’un patient, et pour lui se faire payer était plus important que de la beauté scientifique du geste et pondre des statistiques sur les cas de grippes qu’il avait vu dans l’année. Enorme désillusion.
D’où provient l’échec des pionniers ?
D’une mauvaise approche de l’utilisateur !
Les premiers logiciels médicaux ont été développés avec l’aide de médecins généralistes “geeks” ou quelques spécialistes passionnés, les informaticiens croyaient voir à travers eux tous les médecins alors qu’ils ne voyaient que des exceptions, et non la règle.
L’erreur a souvent été fatale pour beaucoup de sociétés ! Il existe aujourd’hui encore des éditeurs spécialisés dans le logiciel pour médecin. Beaucoup moins que dans les années 80, à la naissance de ce marché et les produits se ressemblent beaucoup, quelques bons et une masse de trucs inutilisables. Certaines font des produits intelligents et complets, mais je reste convaincu qu’ils ne vendent qu’à une fraction de “médecins geeks”, et quant au gros de leurs ventes, supprimez l’obligation de télétransmettre les feuilles de soin imposée par la Sécu et ces sociétés perdront certainement demain une grande partie de leurs ventes...
Cette parabole nous invite à réfléchir sérieusement sur le fait que connaitre les schémas directeurs utilisés consciemment et inconsciemment par l’utilisateur n’est pas un luxe, c’est une obligation. Ne pas se tromper de modèle et choisir un panel d’utilisateurs potentiels représentatif du milieu de la cloche de la courbe de Gauss est tout aussi vital…
Friction cognitive
Ce terme provient du second livre de Alan Cooper, le père de Visual Basic, “The inmates are running the asylum : why High-Tech products drive us crazy and how to restore the Sanity”. Un livre assez ancien maintenant (“les fous dirigent l’asile : pourquoi les produits High-Tech nous rendent fous et comment restaurer la santé mentale” – traduction très imparfaite mais cela vous donne une idée...).
Dans ce livre que tout Designer et tout informaticien devrait avoir lu (je n’en connais hélas pas de traduction en français), Alan Cooper aborde le délicat sujet de l’interaction homme / machine. Dès le début du livre il enfonce le clou de son thème central qu’il appelle la “cognitive friction”, qu’on peut traduire par “friction cognitive” mais ce qui ne vous avancera pas beaucoup !
Il définit cette expression de la sorte “…the resistance encountered by human intellect when it engages with a complex system of rules that change as the problem permutes.” Ce qu’on peut traduire par “la friction cognitive est la résistance rencontrée par l’intellect humain quand il est confronté à un système complexe de règles qui changent en même temps que le problème évolue”.
Il veut insister ici sur la stupidité qui préside à la conception de certains appareils High-Tech, comme les magnétoscopes, les micro-ondes où les logiciels.
Le principe est simple : si vous prenez un violon, aussi difficile qu’il soit d’apprendre à en jouer, vous n’arriverez jamais à un “méta état” dans lequel les “entrées” que vous donnerez au violon (votre jeu) le feront sonner comme un cor de chasse, une cloche ou un saxophone. La façon de se servir d’un violon est claire, ardue, mais claire.
Alors que si vous prenez un magnétoscope (surtout ceux des années contemporaines à l’écriture du livre de Copper) les utilisateurs en viennent à conclure que les petits boutons en plastique doivent couter une fortune, puisqu’il n’y a que quelques malheureux boutons pour faire des dizaines de choses… Du coup chaque bouton prend une signification différente selon “'l’état'” dans lequel se trouve l’appareil. C’est pourquoi chez beaucoup de gens (votre grand-mère, la mienne, chez le vieil oncle Robert…) le magnétoscope affiche glorieusement un “12:00” clignotant : comprendre comment régler cette fichue horloge est finalement bien trop compliqué que le petit avantage d’avoir l’heure à cet endroit procure. Vous avez beau la régler à chaque fois que vous passez, lors de votre prochaine visite l’heure clignotera encore et encore sur “12:00” en raison de la coupure de courant intervenue entre temps...
Bien entendu le livre de Cooper date un peu, et tous les magnétoscopes récents règlent leur horloge automatiquement désormais. Et pourquoi ? parce que jamais elle n’était réglée correctement par les utilisateurs… Et pourquoi ? parce ces quelques boutons changeant de sens selon le contexte sont un enfer ! Et ne me dites pas que même vous, vous ne vous êtes jamais pris la tête avec les trois boutons à la noix de votre écran plat pour le régler correctement, je n’y croirais pas !
Il faut noter au passage que cela reste que cout des boutons n’est finalement pas une fable que l’utilisateur s’est inventé mais bien une réalité méconnue, toujours vrai, même 20 ans après. En électronique ce qu’on appelle le décolletage coute en effet très cher comparativement à un circuit intégré chinois bourré de fonctions. Du coup l’appareil sait faire plein de choses, mais pour que son prix reste abordable la face avant ne possède qu’un minimum de trous et de gravures (et donc de boutons).
Cela est transposable aux logiciels : concevoir un schéma UML de classes sophistiqué ne coute finalement pas si cher, c’est quand on réalise en pratique le logiciel qu’on s’aperçoit que de nombreux choix amènent à toute une série d’écrans et de fonctions coutant autrement plus cher à mettre en œuvre ! C’est l’expérience qui fait qu’on conçoit des schémas plus faciles à implémenter...
Prenez certains micro-ondes, si vous n’avez pas le manuel sous les yeux, à quoi correspond le mode “fc-2” par rapport à “fc-3” ? ou “sc-1” et “sc-2”. J’ai pourtant un micro-onde LG dernière génération (enfin, la dernière génération d’il y a 4 ans) qui fait four, chaleur tournante, grill et tout le reste, et dont le prix était vraiment élevé, et pourtant en face avant, un mini afficheur à led ne donne que ce genre d’information ! Depuis des années que je l’ai, je suis obligé d’avoir le manuel (qui commence à partir en morceaux) à côté, car sinon, fini la cuisson automatique en mode sc-4 qui utilise la grille du bas mais pas celle du haut et la chaleur tournante et les micro-ondes à 360 W, ce qu’il ne faut surtout pas confondre avec le mode sc-3 qui lui utilise la grille du haut… Alan Cooper était un visionnaire génial, bien avant que mon micro-onde n’existe il en parlait déjà dans son livre et savait quels problèmes il allait me poser ! Et rien n’a changé, tout a empiré…
La “cognitive friction” est une souffrance, elle créée le rejet. Les logiciels qui sont conçus comme tous ces appareils High-Tech sont des atrocités pour l’utilisateur ! Si certains de ces utilisateurs devenaient Empereur, il est certain que l’élu en question commencerait par envoyer au peloton d’exécution tous les informaticiens ayant conçu les logiciels de ce type qu’il aurait du utiliser durant sa vie ! (personnellement je proposerai quelques noms :-) ).
Programmer un magnétoscope est une opération qui fut très longtemps (et le reste parfois encore) une expérience pleine de frustration et de “cognitive friction”. Jouer du violon, jamais, c’est juste une question de travail, ce qui est un autre problème.
Peu importe les objets, et peu importe si certains exemples de Cooper ont pris de l’âge en peu de temps, ce qu’il exprime est essentiel, et comprendre comment créer des logiciels qui n’entraineront pas de “cognitive friction” est vraiment un besoin urgent, actuel et totalement moderne !
Cela nous ramène bien entendu aux interfaces utilisateurs. Et pourquoi ? Parce que dès le début je vous ai expliqué que c’est la seule chose “palpable” que l’utilisateur verra de votre travail ! Son seul contact avec votre code, son seul moyen de communiquer avec le logiciel.
Pensez-y, car les logiciels n’ont rien à voir avec les magnétoscopes : ils sont des centaines de fois plus complexes encore, proposent des dizaines, des centaines d’états internes et externes différents, réagissent différemment selon ces contextes. Les logiciels, plus ils se veulent “souples” plus ils créent de la friction cognitive. Tout le monde connait au moins un logiciel “standard” dont le paramétrage est tellement sophistiqué qu’il faut vendre une formation ou envoyer un professionnel pour adapter le logiciel aux besoins de l’utilisateur. Un bel exemple de ce qu’il ne faut pas faire…
La friction cognitive entraine aussi son lot de problèmes. Par exemple TOUS les utilisateurs (même les plus geeks) n’utiliseront généralement qu’un sous-ensemble des possibilités du logiciel. Si on prend par exemple les produits Adobe (PhotoShop, Illustrator...), à chaque fois que je m’en sers je ferai rôtir en enfer les informaticiens pervers qui ont créé ces monstres. Essayer de redresser une photo avec Photoshop… Et essayer avec PaintShop Pro. Vous comprendrez ce que je veux dire (le second le fait immédiatement et facilement pour un prix 10 ou 20 fois inférieur, le premier impose une manip digne d’un hacker pro).
Bien entendu cela ne veut pas dire qu’il faut supprimer des fonctionnalités aux logiciels ! Non, mais en revanche cela oblige à mieux concevoir leurs interfaces !
Parmi les conséquence de la friction cognitive il y a quelques chose de terrible : l’utilisateur se sent idiot. Et quand une chose créée ce genre de sentiment, en toute logique vous la fuyez, l’utilisateur aussi... Personne n’aime passer pour un idiot. On choisira donc de préférences des logiciels plus simples, n’offrant pas certaines possibilités ou une certaine “souplesse” mais dont l’utilisation semblera simple et évidente. Devinez pourquoi tout un tas de gens achètent des Apple au lieu d’un PC ? … Imaginez un utilisateur de base devant XP qui, pour fermer l’ordinateur réclame de cliquer sur le bouton … “démarrer” !!! Le virage à 180° pris par Microsoft depuis le début de l’ère .NET était essentiel. Tardif, mais essentiel. Et c’est pourquoi aujourd’hui Microsoft met les bouchées doubles pour offrir à la fois des OS et des outils de développement qui ne créent pas de friction cognitive.
Autre conséquence de la friction cognitive : le cout exorbitant de la maintenance et du support. Vous allez me dire certains en vivent… Je connais des sociétés ou des indépendants qui vivent juste sur les formations et le paramétrage de certains logiciels “standard”… Quelle que soit la sympathie que j’ai pour certains d’entre eux, il s’agit d’une hérésie.
Enfin, l’acmé de la friction cognitive est atteint par les informaticiens eux-mêmes. Lorsque leur logiciel est incompréhensible, lorsqu’il créée de la friction cognitive chez l’utilisateur c’est que c’est ce dernier qui est un idiot, un inculte, un paresseux qui n’a pas lu la documentation, un crétin des alpes. D’ailleurs ce sont les mêmes informaticiens qui tenteront de vous démontrer que leur paramétrage infernal est une nécessité absolue parce que, disent-ils le torse bombé par l’orgueil, leur logiciel est “souple” (ou “évolutif”, ou “personnalisable”) !
N’ayez pas cette arrogance de pisseur de ligne qui ne mérite que le chômage de longue durée : si l’utilisateur n’y comprend rien c’est que votre interface est bonne à jeter à la poubelle, c’est tout.
Les ‘interfaces utilisateur” du monde réel
Le monde réel nous oblige à de constantes interactions avec des objets de toute nature, avec notre environnement, qu’il soit totalement naturel ou bien artificiel, ou entre les deux. Cela inclut les humains qui s’inscrivent dans “le décors”.
Certaines choses sont simples, d’autres sont complexes. Certains objets sont durs à utiliser, d’autres se manipulent sans même y penser. Choses et objets au sens le plus large.
Et cela s’applique aussi aux êtres humains !
Il en résulte que les concepteurs d’interfaces utilisateur réussies sont souvent de bons communicants jamais des ermites bafouillant en public. Je parle bien de Designers créant des UI. Pas des infographistes qui, bien que parfois talentueux sont rarement de bon communicants, tout comme les informaticiens d’ailleurs (ce sont des métiers de solitaires rivés devant leurs écrans ou leur feuille de dessin).
Et par un renversement logique qui n’est pas un simple plaisir rhétorique de retourner une assertion mais qui est une réalité psychologique, si vous améliorez votre communication, vous deviendrez certainement meilleurs pour créer des interface utilisateurs !
“L’apprentissabilité”
Quel horrible mot ! Mais je n’en ai pas trouvé de meilleur pour faire comprendre le concept…
L’une des questions qu’il faut se poser sur une application c’est de savoir si l’utilisateur peut rapidement la découvrir et apprendre à s’en servir.
On peut se dire que cela revient un peu à la fameuse “première impression” dont j’ai déjà parlé. En quelque sorte oui, d’apparence. Dans les faits il s’agit bien de deux choses différentes.
La première impression, comme son nom l’indique, n’est qu’une… impression. Nous nous sommes tous “fait avoir” un jour par un produit (peu importe sa nature) qui “semblait” bien conçu, simple, mais qui, à l’usage, s’est révélé décevant.
Il a beaucoup de logiciels développés dans cet esprit. Ils sont généralement produits par des sociétés dirigées par des commerciaux… Tout est mis dans la pub, l’apparence, le clinquant, mais pas de budget pour ce “qu’il y dedans”. C’est navrant mais cela existe.
Je ne vous parle donc pas ici de ce genre de choses qui, à mon sens, frisent l’arnaque.
Je vous parle plutôt d’un logiciel faisant bonne impression dès le départ, mais qui à l’utilisation se révèle aussi facile à prendre en main, accompagnant l’utilisateur dans son apprentissage, ne le faisant jamais passé pour un idiot, et même, si possible, lui donnant l’impression d’être plus intelligent qu’il ne l’est en réalité !
Car là est la clé du succès : si votre logiciel donne l’impression à l’utilisateur qu’il s’en sort facilement, alors qu’il avait peut-être une certaine appréhension, alors il vous aimera, vous bénira ! Lui qui avait peur de se sentir un peu bête, se rend compte qu’il comprend tout… Si vous arrivez à créer ce sentiment chez l’utilisateur alors votre logiciel se vendra tout seul par le bouche à oreille !
Comment mesurer “l’apprentissabilité” ?
Il existe de nombreuses études portant sur le sujet, souvent très universitaires et peu diffusées. Il existe aussi des cabinets d’experts en ergonomie capable de mesurer avec précision les mouvements des yeux des utilisateurs découvrant votre logiciel ou votre site Web. Le prix de leurs prestations est généralement assez dissuasif, seules de très grosses sociétés pouvant s’offrir de tels services.
Mais il n’est pas interdit de faire dans la simplicité : réussir à trouver deux ou trois utilisateurs types du logiciel, les mettre devant l’écran et leur demander d’exécuter une tâche précise et habituelle pour eux (pour un comptable saisir une note frais par exemple). Prenez une montre et mesurez combien de temps cela nécessite. Testez deux ou trois options différentes de l’interface. Comparez les résultats.
Si vous n’êtes pas en mesure de réunir deux ou trois utilisateurs potentiels de votre logiciel, alors laissez tomber la création d’applications. Franchement. Car si vous ne pouvez pas réunir quelques utilisateurs potentiels comment avez-vous fait pour connaitre le profil précis et les habitudes de ces mêmes utilisateurs alors qu’il s’agit d’un préliminaire incontournable ?
Vous le voyez, l’échec s’inscrit souvent dès le départ : une conception coupée des utilisateurs ne pose pas seulement que des problèmes d’interface, mais de cahier des charges, de fonctionnel aussi… Un logiciel conçu dans l’éloignement le plus total des utilisateurs ne pourra jamais être un bon logiciel. C’est ainsi.
Mais admettons que ce point essentiel est compris et que vous avez eu à cœur d’être proche des utilisateurs dès l’analyse, dès le cahier des charges, et que maintenant que vous en êtes à la conception de l’interface il vous est donc facile de revoir les mêmes gens et de leur demander de faire quelques tests. Supposons que vous puissiez faire ces mesures, ces comparaisons pour aider à prendre de meilleures décisions.
Il n’en reste pas moins vrai qu’au moment de la prise en main l’utilisateur ne sera qu’un débutant, découvrant tout. Il réclamera donc un support permanent, ce que le logiciel doit être capable de fournir de lui-même. Vous ne serez pas à côté de tous les utilisateurs pour leur donner des conseils…
D’où l’importance d’intégrer des dialogues supplémentaires, des explications, des info bulles, des choix du type “débutant / expert” modifiant l’apparence et offrant plus ou moins d’options, sans oublier les “experts” ou “wizards” permettant de réaliser une tâche donnée en étant guidé. N’oubliez pas qu’un bon “wizard” ne doit pas être une boite noire, ce qu’on voit trop souvent ! Un bon wizard est conçu pour guider l’utilisateur vers son but, mais en même temps il doit être capable de faire comprendre comment atteindre ce but en se passant de lui !
Un logiciel dont “l’apprentissabilité” est excellente répondra au minimum à 80% des besoins de l’utilisateur de façon évidente.
Arrivé à ce point de véritable “souplesse” (et non pas la fausse souplesse-excuse des usines à gaz), vous aurez développé un vrai logiciel moderne. L’intégration de la conception d’une interface utilisateur pensée, avec l’aide d’un vrai Designer, ne vous apparaitra plus alors comme une “mode”, un “gadget”. C’est que vous aurez compris ce que doit être un logiciel bien conçu en 2011…
L’utilisabilité
Avec “apprentissabilité” je ne suis plus à un néologisme abominable près, hein… !
Et bien détrompez-vous !
l’utilisabilité est un mot qui existe en français, on peut aussi parlé d’usabilité. C’est même une norme, ISO 9241-11, qui la définit comme “le degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d’utilisation spécifié”.
Les concepteurs de cette norme ont tout compris ... mais vous ?
Il convient ainsi de réfléchir à la question suivante :
A quel point l’interface utilisateur est-elle intuitive et productive pour un utilisateur “moyen” ?
Cela peut aussi se mesurer. Cette fois-ci en prenant pour cobaye un utilisateur avancé et en lui demandant, toujours la même chose, d’effectuer une tâche habituelle. Bien entendu on prendra plutôt deux utilisateurs, voire quatre ou cinq, pour que les mesures aient un sens.
Une interface utilisateur ayant une haute “utilisabilité” permet aux utilisateurs d’effectuer toutes les tâches courantes de façon directe et sans détour. Cela implique dans certains cas que le workflow puisse être personnalisé selon le niveau de l’utilisateur.
Il faut faire attention à ne pas confondre “utilisabilité” et “apprentissabilité”. La confusion est fréquente car l’un va souvent avec l’autre, mais il s’agit bien de deux domaines distincts. Deux objectifs différents qui ont leurs impératifs propres et leurs mesures.
Les tests d’utilisabilité réclament un panel de testeurs le plus large possible pour pouvoir tirer des conclusions. Les évolutions, les variantes, tout cela doit être mesuré spécifiquement et séparément. C’est vraiment une partie difficile dans la conception d’un logiciel car cela peut couter très cher à organiser.
Je vais ainsi vous livrer un secret : Pourquoi les plus grands éditeurs du monde sortent-ils des versions “bêta” gratuites ?…
Car à défaut d’un test encadré scientifiquement, les “bêta” permettent de s’offrir gratuitement un large panel d’utilisateurs testeurs ! Un autre secret : Les plus malins diffusent durant quelques jours une bêta offrant certains choix d’interface, et pendant les jours suivant une version offrant un choix différent. La version restant la même de l’extérieur. Tout le monde croyant télécharger la même bêta bien entendu. En fonction des retours du premier et du second groupe vous saurez quel choix d’interface est le meilleur, quelle est la valeur par défaut la plus facilement acceptée pour tel ou tel paramètre... Malin non ?
La clarté
Enfin un mot qui existe ! Et pourtant celui-là, ironie du sort, je n’ai jamais réussi à comprendre pourquoi il manque un “e” entre le “r” et le “t”. Mais bon, j’ai toujours détesté l’orthographe, je ne suis donc pas un bon exemple.
En réalité beaucoup d’interfaces utilisateur submergent ce dernier sans raison particulière. Information non pertinente ayant autant de visibilité que celles qui sont importantes, iconographie faite de bric et de broc copié au petit bonheur la chance et sans cohérence depuis Google, trop plein de données (une grille avec 2000 enregistrements derrière ne sert à rien, personne ne lit 2000 lignes à l’écran), etc...
Optez pour un Design fluide et clair !
l’esprit de METRO de Microsoft, notamment étudié pour Windows Phone 7 et prenant une partie de son origine dans Zune est un excellent exemple de clarté.
Je vous conseille de vous en inspirer le plus possible.
Lors du MiX10, Microsoft a distribué aux chanceux participants un petit livre de 47 pages définissant l’esprit de METRO. Je trouve dommage que sa diffusion ait été trop limitée, c’est un document que tout développeur devrait avoir consulté.
L’un des possesseurs de ce livre l’avait photographié à l’hôtel le soir même et l’avait publié sur Internet.
Vous pourrez retrouver les images sur Flickr dans un album mis en ligne par Long Zheng. On retrouve aussi une mise en diaporama du livre.
La clarté peut s’obtenir ainsi en donnant la priorité à l’information, en adoptant des normes visuelles comme Metro (ou en s’inspirant de leur esprit).
Concrètement cela implique aussi de ne pas oublier de grouper l’information de façon cohérente, non pas pour vous, mais pour l’utilisateur final et dans le cadre des scénarios qu’il va suivre.
Les groupes doivent être logiques, mais aussi fonctionnels. On doit aussi penser le Design en fonction de “lignes verticales”, c’est à dire de lignes de processus descendantes où l’on part d’un début pour arriver à une fin, de façon... claire. (bravo pour ceux qui ont suivi !).
Enfin, si vous ne devez retenir qu’une seule chose sur la clarté, c’est que la clarté est bien plus importante que l’ajout de hints, de bulles d’information ou d’aide car elle les rend inutiles.
Proposer des options adaptées
La liberté d’action est essentielle, autant pour vous et moi dans notre vie quotidienne que pour l’utilisateur face à un logiciel.
Mais la liberté d’action n’est rien comparée à la liberté de pouvoir modifier le comportement d’un logiciel.
Selon l’expertise de l’utilisateur, l’accès à certaines options est plus ou moins essentiel. Par exemple un débutant ne devra pas à avoir faire des choix dont il ne comprend pas toute la porté. Pourtant combien de logiciels posent des questions de ce genre lors de l’installation ou de la première utilisation ?...
Il est donc crucial de faire les bons choix de présentation, de comportement, “out of the box” pour que tout utilisateur, débutant ou non, puisse s’y retrouver immédiatement.
Si vous n’êtes pas capable de faire les bons choix, ne vous reposez pas sur l’utilisateur en lui offrant un système de paramétrage... Si vous ne pouvez pas faire ces choix vous-mêmes l’utilisateur débutant ne le pourra pas plus !
En revanche, les utilisateurs experts n’auront aucun problème à faire certains choix. Un logiciel doit ainsi proposer différents niveaux de paramétrage adaptés à chaque type d’utilisateur. Ce qui implique d’avoir faire les bons choix pour les valeurs “par défaut”...
Bien entendu, tout cela s’entend dans le cadre global dont je parle ici, c’est à dire l’ergonomie d’un logiciel et tout ce que cela sous-entend. L’intelligibilité pourrait aussi être une entrée de chapitre dans cet article. Les choix, les options et autres paramètres doivent toujours être conçus avec l’intelligibilité en tête. Et hélas ce n’est que rarement le cas !
Certains dialogues sont des exemples de bêtise... d’autres sont explicites et permettent de prendre une décision même si les conséquences du choix sont assez complexes.
Prenez ce dialogue issu d’une version assez ancienne de Excel :
L’utilisateur sait exactement ce qui est possible de faire, et il peut comprendre les implications de ses décisions. Les boutons se limitent à l’acceptation (ok) ou à l’annulation de l’opération. C’est clair. L’interface, d’un point vue graphique, est moche, avec un look XP, mais s’il faut faire un choix, celui de la clarté et de l’intelligibilité est plus essentiel que l’esthétique.
Prenez maintenant le dialogue suivant que j’ai pris au hasard en cherchant un peu sous Google (franchement au hasard sans savoir de quoi il s’agit) :
Le logiciel dont il est issu s’adresse peut-être à une cible d’utilisateur ultra avancés, je ne porterai donc aucun jugement de valeur “hors contexte”. Juste une image et un constat : c’est le genre de dialogue qu’il faut éviter de produire, quelles que soient les “bonnes raisons” qu’on se donne pour le faire... C’est chargé, pas clair, peu intelligible, complexe, certainement inabordable pour un débutant.
Cela me rappelle un logiciel que j’aime bien mais qui me casse les pieds : Blender. Rien à voir avec Expression Blend qui est un produit très bien conçu. Blender est un énorme logiciel de conception 3D open source. Fantastique de puissance d’un niveau comparable à Maya ou 3DS mais gratuit. En revanche la prise en main de Blender est une souffrance, pleine de friction cognitive (Maya c’est encore pire). Sous prétexte d’inventivité l’interface est contre-intuitive, bourrée de trucs incompréhensibles. Appliquer une simple texture avec son bump réclame de voir et revoir les vidéos pour débutant dès qu’on ne s’est pas servi du soft 3 mois. Les dialogues sont souvent du genre de celui en exemple ci-dessus. Evitez systématiquement ce mode de conception, cela créé réellement de la souffrance, de la “vraie”, ce n’est pas juste un point de vue philosophique !
Dernière chose, n’oubliez jamais que les utilisateurs ne lisent rien !
Pour bien comprendre, voici une anecdote récente.
Une amie s’est acheté un portable et un appareil photo numérique. Premier achat de ce genre à 50 ans. Forcément tout n’est pas évident. Mais il est de la responsabilité des logiciels et des OS ne prendre en charge les utilisateurs débutants. Nous allons voir que cela n’est pas forcément le cas.
Son problème : elle “perdait” des photos. Etrange et bizarre. Les fichiers ne disparaissent pas comme ça...
La raison : son appareil numérote les photos toujours en partant de “1”. Peut-être s’agit-il ici d’un paramétrage qui peut être changé, mais preuve en est que ce genre de choix de par défaut est une très mauvaise idée. Mais l’appareil photo n’est pas le propos de cette histoire (même si lui-même illustre à merveille tout ce qui vient d’être dit).
Quand mon amie vide les clichés depuis l’APN dans son portable toutes les photos viennent dans le répertoires “mes photos”, cela est normal. Comme elle a fait le vide avant, aucun problème ni aucun dialogue à ce niveau. C’est ensuite que cela se complique.
Ensuite donc elle souhaite déplacer ses photos dans d’autres dossiers pour faire du classement, intention louable.
Et lors de cette opération une boite de dialogue de Windows surgit, celle qui indique qu’un fichier de même nom existe déjà dans le répertoire cible et qui vous demande ce que vous voulez faire. Forcément, l’APN produisant à chaque fois des PICT0001.JPG et 0002... il y a collision de noms pour peut qu’on déplace l’un de ces documents vers un répertoire contenant déjà certains numéros...
Le dialogue de Windows Vista installé sur sa machine (le même dans Windows 7 hélas) est à ce niveau un exemple de ce qu’il ne faut pas faire. Pas de clarté. Pas d’intelligibilité. Des actions par défaut qui détruisent l’information.
Comme elle ne comprenait rien à ce fameux dialogue elle répondait toujours de la même façon, et par malchance, le choix qu’elle faisait signifiait l’écrasement du fichier existant dans le répertoire cible.
Du coup elle perdait des documents : déplacés (donc détruits) du répertoire source et remplaçant les photos portant les mêmes numéros dans le répertoire cible (donc détruisant les anciennes photos de même numéro).
Une suite d’opérations simples, engageant les fonctions vitales de base d’un ordinateur, qui amène un utilisateur à détruire systématiquement des documents uniques et impossibles à retrouver... Le comble du manquement à tous les principes de Design !
Quand je lui ai fait remarquer que ce dialogue devait apparaitre (car elle ne m’en parlait, comme tout utilisateur, elle omettait ce qu’elle ne comprenait pas) elle m’a répondu “ah oui, il y a un truc qui s’affiche mais je n’y comprend rien alors je clique toujours sur le premier choix à chaque fois”. Diantre !
Edifiant non ?
Personnellement je trouve les dialogues de confirmation des opérations de fichier de Vista (et de Seven) une horreur anti ergonomique. Même moi je n’y comprends jamais rien entre ce qu’il faut accepter et refuser, où se trouve le fichier original, où se trouve celui qui va être écrasé. Le responsable de ce dialogue dans Vista devrait être fusiller pour l’exemple.
Voici le dialogue coupable qu’on fait apparaitre facilement (ici en dupliquant volontaire un fichier dans un second dossier avant de le déplacer vers le dossier où se trouve l’original) :
C’est confus.
Comment repérer rapidement quel est le fichier source et le fichier cible ?
C’est plein d’informations inutiles et de blabla.
Ce n’est pas lisible.
Ce n’est ni clair ni intelligible. Deux principes fondamentaux du Design piétiné par un incompétent et non corrigé par ses supérieurs. Ni dans Vista. Ni dans Windows 7. Une grosse tâche dans un OS conçu, justement, autour de l’UX et d’une UI plus abordable. Comment une telle erreur peut-elle être présente dans un logiciel tel que Windows contrôlé et re-contrôlé, designé, traduit, etc... ? Un vrai mystère, mais une réalité ! Alors vous, seul à programmer dans votre coin ou avec une équipe et des moyens bien plus restreints que ceux de l’équipe Windows de MS, forcément, des erreurs de ce type vous risquez d’en laisser passer encore plus si vous ne prenez pas le temps d’appliquer et de vérifier l’application des principes de Design que je présente dans cet article !
Pourquoi l’utilisateur vat-il se tromper à cause de ce dialogue ?
Apprendre des erreurs, les siennes et celles des autres, est une façon simple d’enrichir sa connaissance. Simple car des erreurs, dans tout logiciel, c’est plus facile à trouver que des points d’excellence... (et je n’ai pas la prétention de m’épargner pas dans ce constat). Regardons de plus près en quoi ce dialogue est fautif.
D’abord, en répondant par le premier lien proposé dans le dialogue, on écrase la destination.
Que le premier choix possible soit le plus dangereux est une première mauvaise idée. Certes aucun choix n’est fait par défaut et la validation par Enter correspond au bouton Annuler. Mais même cela est une énorme erreur.
Le principe de clarté et d’intelligibilité voudrait que la touche de confirmation, ayant un sens généralement positif (Entrer = avoir le droit de.. ne pas rester à la porte, avoir la possibilité de... valider... Tout un champ sémantique positif) ne soit pas utilisée pour une action négative (annuler = refuser, décommandé, non, refus. Tout un champ sémantique négatif). Ici, Enter ne devrait rien faire (il serait dans l’idéal relié à un bouton OK et comme aucune option n’est sélectionnée d’avance, cela ne ferait rien) et Annuler devrait être un second bouton. Autre avantage de la situation, deux boutons (OK/Annuler) font voir clairement à l’utilisateur qu’il a un choix à faire et qu’il peut valider ce choix ou l’annuler. C’est plus intelligible. Ce bouton Enter utilisé pour valider une Annulation me fait penser à la grossière erreur de XP et de son bouton “démarrer” qu’il fallait cliquer pour éteindre l’ordinateur. Il doit y avoir des gars de l’équipe XP qui travaillent donc toujours chez MS et qui sont sur Vista et 7 ...
Ensuite, l’utilisateur veut déplacer le fichier, donc il ne cliquera certainement pas sur “Ne pas déplacer” car c’est l’exact contraire de ce qu’il veut faire !
Il ne cliquera pas non plus sur “Annuler”. Il ne veut rien “annuler” il veut déplacer son fichier ! Vraiment idiot cet ordinateur !
Et le seul lien qui utilise le mot “Déplacer” (avec majuscule et en première position dans la phrase) c’est celui qui dit “Déplacer et remplacer” ! L’utilisateur lit le premier mot C’EST TOUT, celui qui correspond à ce qu’il veut faire et qui n’est écrit qu’une seule fois à l’écran, et il ne LIT PAS le reste de la phrase ! D’autant qu’il n’y a qu’une phrase qui contienne le mot de l’action qu’il souhaite effectuer, pas de confusion possible se dit-il inconsciemment ! Hélas confusion il y a... entrainant fausse manipulation et de perte inéluctable de données précieuses.
En cause ? Microsoft ici. Ce dialogue est une horreur incompréhensible. Une bavure énorme. La preuve, cette anecdote qui présente un scénario d’utilisation basique qui aurait du être testé et validé, entrainant le rejet de la solution apportée par ce dialogue.
Mais le but n’est pas ici d’accabler tel ou tel éditeur de logiciel, Windows est un exemple comme les autres et des incohérences encore pire il y a en dans beaucoup de logiciels qui ne sont pas signés Microsoft !
La leçon à retenir est bien celle que seul un design bien conçu respectant certains points essentiels tels que ceux développés dans cet article permet d’éviter des situations catastrophiques dans des scénarios pourtant élémentaires...
Les métaphores
Les métaphores permettent d’introduire la familiarité dont il a été déjà souvent question ici en créant un pont entre le monde réel dans lequel l’utilisateur se situe et le montre virtuel créé par le logiciel utilisé.
Pour fonctionner, les métaphores doivent donc prendre en compte le vécu et l’environnement spécifiques de l’utilisateur. On en revient à la bonne connaissance de celui-ci...
Les métaphores doivent être, dans ce cadre, directes et intuitives.
On peut penser aux métaphores utilisées par Windows : la notion de “bureau” qui définit bien un espace de travail de taille finie sur lequel on pose les documents sur lesquels on travaille. Ou bien la notion de “dossier” pour la gestion de fichier. Un utilisateur standard comprendra facilement cette analogie (alors que le terme “répertoire” est plus confusant). La notion de Document sous Word ou Excel est, elle-aussi, simple à comprendre.
Ces métaphores vous paraitront certainement un peu “simplettes” ou “évidentes” à la première lecture de cet article. Elles sont tellement bien choisies que vous les avez intégrées sans difficulté et qu’en parler comme d’un effort particulier fourni pour les inventer peut vous sembler à la limite du ridicule. Il n’en est rien... Je parlais ci-dessus du mot “répertoire”. Ce dernier est compris par tout informaticien. Mais on s’aperçoit que seul “dossier” et “sous-dossier” se popularisent bien que d’utilisation plus récente. C’est la même chose en anglais ou “folder” (dossier) remplace progressivement '’directory” (répertoire). Et si tout cela vous semble si “évident” et si “simple” c’est uniquement parce que ces métaphores sont excellentes et je vous souhaite d’avoir le talent d’en trouver d’aussi bonnes dans vos logiciels !
Les métaphores, pour important que soit le rôle qu’elle joue dans une interface réussie, peuvent aussi être des ennemis sournois ! La métaphore, dans le sens ou elle s’écarte volontairement de la réalité objective de la chose en imposant une autre réalité peut aussi brouiller le jeu de la compréhension fine du logiciel...
En effet, le “bureau” de Windows n’est qu’une métaphore. Un bureau physique n’est pas extensible, alors que nombre de cartes graphiques savent agrandir le bureau en scrollant automatiquement quand la souris se rapproche des bords. Si l’utilisateur intègre “trop bien” la notion de “bureau physique” il ne pensera même pas à se renseigner (dans l’aide ou auprès de quelqu’un) d’une telle possibilité !
De la même façon, les notions de “dossier” ou de “document” peuvent s’avérer trompeuses : j’ai souvent constaté chez des utilisateurs débutants que la compréhension de la “copie” d’un document qui n’efface pas l’original est loin d’être immédiate. En effet, un “vrai document”, si je le prend d’un dossier pour le mettre dans un autre, forcément, il disparait du premier ! Sous Windows et d’autres OS, les choses ne sont pas si simples. Le monde réel de l’ordinateur et de son OS est différent du monde physique d’où provient la métaphore, la réalité qui se cache derrière la notion de “document” est trompeuse et peut troubler. On peut copier, on peut déplacer. Dans la réalité seul le déplacement est possible, la copie est un fantasme de science-fiction ! Et ce genre de chose peut induire un blocage chez l’utilisateur. Je me rappelle d’un excellent livre de SF, “A for Anything” de Damon Knight où il est question d’un “Gizmo” une invention incroyable qui permet de copier n’importe quel objet réel. Le Gizmo est capable bien entendu de copier un autre Gizmo et cette invention géniale dévoile rapidement quelques problèmes... Comme dans notre histoire de métaphore avec les documents !
Les métaphores sont donc à manier avec précaution car elles induisent tout un “champ du possible” forcément différent de celui de la réalité informatique.
Ne pas oublier non plus que toute métaphore est spécifique à une culture.
Respecter les standard
C’est un point délicat car des standard il y en a plein... Ceux de l’OS sur lequel on travaille, ceux de la profession visée par le logiciel qu’on écrit, ceux du pays cible, etc. Par standard on peut entendre aussi “us et coutumes”.
Mais de nombreuses métaphores par exemple sont admises comme des standard “de fait”, autant s’en inspirer lorsqu’on veut que les utilisateurs comprennent immédiatement à quoi sert tel ou tel autre élément d’interface. L’essentiel c’est qu’elles fonctionnent, peu importe si vous vous les trouvez bonnes ou mauvaises.
Si vous pensez avoir trouvé un procédé original qui permet de faire des sélections à la souris alors que tous les logiciels du monde utilisent une autre et même méthode, oubliez votre idée : dans tous les cas elles perturbera les utilisateurs... (Cf. l’interface de Blender ou de Maya ou des produits Adobe).
Pensez aussi à “nettoyer” votre librairie d’icônes. Rien de plus navrant par exemple que de voir aujourd’hui un bouton de sauvegarde représenté par une diskette ! Les plus jeunes n’en ont même jamais vu une “vraie” de près !
D’un autre côté si tous les logiciels que manipule votre utilisateur cible (d’où, encore une fois, le fait de bien le connaitre) utilise cette métaphore alors surtout ne changez rien. Dans certains contextes des métaphores qui paraissent d’un autre âge gardent tout leur sens en tant que symbole largement compris.
Conclusion
On pourrait bien entendu encore dire des milliers de choses sur le Design. Mais cet article est déjà bien long, et son but est d’éveiller le lecteur à des problématiques que souvent il ignore. Et puis gardons-en pour le prochain billet de ce genre !
PS: la plupart des images utilisées dans cette article ont été puisées du Web par des recherches sous Google, elles ne servent que d’illustration au propos, voire à la simple “aération” du texte. Les copyrights éventuels de ces images appartiennent à leurs propriétaires respectifs.
Mais il y a deux sources que je souhaite citer et que je vous enjoins de visiter :
riagenic : http://www.riagenic.com/
et Mark Coleran, un génie des fausses UI pour les films, son site est bourré d’exemples, une pure merveille : http://coleran.com/
Enfin, je vous conseille cette très belle vidéo, pure produit de Designer, montrant une “journée faite de verre” où tous les objets sont en verre ou céramique et communicants. Une source d’inspiration à ne pas rater : “A day made of glass” produit par la société Corning spécialiste de la fabrication de verre et de céramique Hi-Tech (dont le site est en ASP.NET d’ailleurs, des gens qui ont vraiment bon gout donc 
).
so... Stay Tuned !