Je suis ergonome de formation. La première chose que j’ai apprise, c’est que mon intuition est à chier. Dit très clairement: si je design un site Web basé sur ce que je pense être utilisable, je vais me planter.

Même après des années d’expérience, mes premières idées sont très classiques, formatées, et Max me met des taquets derrière la tête régulièrement en guise de rappel.

Pour rendre une interface utilisable, il n’y a qu’un moyen fiable: le test. Pour apprendre en une journée tout ce que sais de l’ergonomie, vous pouvez en fait plus ou moins vous limiter à lire et appliquer le bouquin culte de Steve Krug.

Et c’est quelque chose que les designers ont du mal à comprendre. Ils font souvent des choses très belles, mais n’est pas Apple qui veut. Faire quelque chose de beau ET d’utilisable est très difficile.

Et si on doit choisir, il vaut mieux faire utilisable que beau.

Les états

Les états sont par exemple un vrai problème. En informatique, il n’y a pas vraiment de moyen de connaître l’état de quelque chose, et donc on crée artificiellement des repères visuels en espérant que l’utilisateur comprenne ce que l’on veut dire.

Seulement beau n’est pas forcément explicite. Est-ce que quelqu’un peut me dire ici quel bouton correspond à l’état “on” ?

Le premier bouton, il est sur “off” parce qu’il affiche “off” ou il est sur “on”, offrant la possibilité de slider vers l’état “off” ? Les deux comportements existent dans le monde matériel.

Nous avons déjà des boutons qui reflètent très bien on / off: les checkboxes. Tout le monde sait comment ça marche, mais c’est moche, alors la plupart des designers essayent de les remplacer.

Si la designite vous démange, il faut alors sérieusement réfléchir, et ne pas proposer une solution moins efficace que ce qui existe déjà. Par exemple, une bonne implémentation du concept ci-dessus est:

L’auteur a ici ajouté un simple effet grisé sur le “off” (qui a la connotation de “désactivé”) et un effet de lumière sur le “on” (qui à la connotation de “en fonctionnement”). On sait clairement que le premier est l’état “off”, et que si on clique dessus, on va obtenir le second état: “on”.

Mais les états ne sont pas toujours aussi simples que on / off, et surtout, ils se cachent parfois dans des situations naturelles. 37signals ont largement défendu l’idée de parer à ce que l’utilisateur va vouloir faire, plutôt que d’attendre qu’il le fasse. Et cela passe par la prédictibilité, et la compréhension du contexte, donc par l’affichage d’états et d’intentions.

Un exemple simple: l’état vide. Vous n’imaginez pas combien il est courant de ne pas travailler l’état de départ, ou vide, d’une UI. Pourtant, c’est primordial car c’est le premier contact de l’utilisateur avec votre logiciel, et surtout, par principe, vide signifie qu’il n’y a aucun indice sur ce qu’il faut faire par défaut.

Prenez l’explorateur de fichiers par défaut d’Ubuntu, Nautilus. Il est globalement très bon. En revanche, sur les gros dossiers, ou sur les dossiers contenant beaucoup de thumbnails, il y a un instant plus ou moins long durant lequel on ne sait pas si il charge, ou si le dossier est vide.

Une fois qu’on a décidé que l’état “n’affiche rien” était bien non un temps de chargement, mais le fait qu’il n’y a rien à afficher, le cerveau fait la déduction, “le dossier est vide”.

Prenez par contre Marlin, l’explorateur d’Elementary OS, et donc bien moins intégré à Unity, dans lequel il ressort plus laid que Nautilus. Mais il vous montre instantanément de quoi il est question.

Ceci vous parait un détail. En fait, certains geeks trouvent même énervant tous ces trucs qui “ne servent à rien” pour “les gens qui ne veulent pas réfléchir” car “c’est quand même pas compliqué de voir que le dossier est vide”.

Oui, sauf que comme je vous en parlais précédemment, il existe une telle chose que la charge cérébrale, et que tout ce qui y participe se cumule.

Faire un beau design allège la charge cérébrale, mais faire un design utilisable la soulage sans commune mesure. Qui dit moins de charge, dit une utilisation fluide, sans peur (car oui, la peur de cliquer est un facteur étonnamment important dans le schéma de décision des utilisateurs lambdas), et donc des users qui aimeront votre app.

Le but est d’obtenir le même résultat que le crayon: quand vous écrivez, vous pensez à ce que vous écrivez, pas au crayon. Bien sûr que réfléchir un tout petit peu n’est pas la mer à boire, mais c’est autant de neurones que vous consacrez à votre outil plutôt qu’à votre travail.

Mais faire un design, plus que beau, utilisable, c’est aussi proposer à l’utilisateur ce qu’il peut faire. Mettre en avant les solutions les plus importantes. Les menus ajoutent à la charge cérébrale, ce sont des accès secondaires.

UsabilityFriction a posté une bonne illustration de la démarche. Ils sont partis d’un truc vide et pas top:

Et ils ont ajouté:

• Des raccourcis vers les actions de certains menus pour ajouter des photos.
• Un album photo d’exemple facilement supprimable pour que l’utilisateur puisse déjà se balader.
• Une vidéo de démo qui disparait dès qu’on ajoute un élément.
• Une courte et simple explication en forme d’invitation à l’action.

Ici il n’y a pas d’enjeu esthétique car c’est un mockup. Et c’est tout l’interêt du mockup pourri, fait avec balsamiq ou même au feutre Veleda sur brouillon: on se soucie de l’utilisabilité, pas du look. Le premier est la priorité car un bon designer rendra votre site qui est déjà facile à utiliser beau, alors que rendre un site déjà designé facile à utiliser demande beaucoup plus de travail additionnel.

Un bon dessin vaut mieux qu’un long discours, sauf si on dessine mal

Utiliser des icônes, c’est bien, non ?

En théorie, les formes et couleurs sont plus faciles et rapides à identifier que des mots. Et on évite les problèmes de traduction.

Mais, le hic, c’est que la signification d’une icône, contrairement à un mot, n’est pas garantie:

• Il existe des centaines de milliers de mots. On est loin d’avoir autant d’icônes.
• Les concepts abstraits sont très durs à icônifier. Essayez de trouver un symbole pour “niveau de difficulté” pour voir…
• Selon le contexte (culturel, expérience, environnement…), un symbole peut avoir des sens différents. Ainsi, le blanc est la couleur du mariage pour nous, mais du deuil dans certains pays musulmans. Le rouge est la couleur du mariage en Chine…
• Les icônes se périment plus vite que les mots. On a en encore beaucoup de logiciels qui symbolisent “sauvegarder” par une icône en forme de disquette. Combien d’utilisateurs actuels savent à quoi sert une disquette ? Ou même ce que c’est ?

Et si on choisit les icônes, on est obligé d’en mettre de manière cohérente, donc quand on rajoute un nouveau bouton, c’est une nouvelle icône à rajouter: il faut en trouver une correspondante, et au sens, et au design.

Un exemple: j’aime le nouveau design de Gmail. Mais le tout icône n’est pas forcément une réussite. Dans l’ancienne version, trouver comment marquer un mail en tant que spam était évident:

Le nouveau design est plus beau, mais par contre, pour mettre son mail en spam…

L’objectif n’est pas de pinailler sur les qualités de x ou z, mais d’illustrer. Stackoverflow est un modèle d’utilisabilité, mais le site comporte pourtant très peu d’icônes. Mnmlist prouve qu’on peut être jusqu’au boutiste pour aller à l’essentiel. Drudge report prouve que… heu… Je vous laisse lire.

Encore une fois, ne laissez pas la fièvre graphique prendre la priorité sur l’utilisabilité. Un beau design est important. Un design utilisable est primordial. Il n’existe pas de solution clé en main telle que “utilisons des icônes” qui pallie le travail de réflexion ergonomique dont votre projet à besoin.

Tous les types de designs ont leur place: avec et sans icônes, avec des images, sans, avec du texte, sans, avec des jeux de couleur, sans. La recette à elle seule ne peut pas rendre un plat délicieux, il faut de bons cuisiniers, de bons ingrédients et du travail.

(et la métaphore de la bouffe est particulièrement adaptée, car quel que soit l’acharnement que vous mettez à votre popotte, y aura toujours un connard pour trouver ça dégueulasse)

Un dernier exemple de “ça dépend”. Gedit (Gnome) VS Scratch (Elementary OS), deux éditeurs de texte, deux approches pour “l’état de départ”, aucune n’est meilleure que l’autre, et elles ne satisferont pas le même public.

 

Tout comme on oriente son design en fonction de son public (hacker news peut se permettre l’aspect WEB 1.0, pas Facebook), l’ergonomie doit viser aussi le type d’utilisateur auquel vous souhaitez plaire. Car il n’y a aucune chance que vous plaisiez à tout le monde.