J’ai décidé de me lancer dans une série d’articles de vulgarisation de papiers de recherche, avec une présentation sous forme de slides. Le premier d’entre eux concerne la manière de représenter les toggles.
Pas de teasing, voici directement la synthèse des bonnes pratiques présentées dans ce papier de Al-Jasim & Murano, 20231 :
Aïe aïe aïe, quand on a tellement de retard dans les nouvelles, j’ignore quelle est la meilleure stratégie. Alors je fais un post ultra vite fait pour annoncer la sortie du jeu 5 des Ergogames, que je vais antidater comme une malotrue pour faire genre que ça a été publié quand il est sorti, c’est à dire, heu… en décembre. Bon.
Grande nouvelle, voici tout droit sorti de l’œuf le 5ème Ergogame ! Si vous ne savez pas ce que c’est que les Ergogames, vous pouvez cliquer ici pour connaître la démarche de conception ou là pour en savoir plus sur la démarche d’évaluation, mais le mieux c’est d’aller découvrir directement ici. Et en deux mots, c’est des mini-jeux pour démontrer et enseigner des principes fondamentaux d’ergonomie numérique. Cette fois, votre mission sera d’aider Colin le poulpe à sauver ses amis de la pollution aquatique !
Le mois d’août c’est toujours calme, l’occasion d’écrire un article de blog ! Cette idée me trottait dans la tête depuis un moment, je me suis amusée à écrire les 10 commandements de l’ergonome IHM / de l’ux-designer.
C’est la base, nous nous battons pour faciliter la vie des usager·e·s. Pour cela nous devons les connaître. Pour les connaître nous devons les rencontrer, leur parler, les observer.
Il ne suffit pas de les rencontrer, il faut creuser tous les aspects en lien avec le projet sur lequel on travaille. Quels sont leurs problèmes ? Leurs manques ? Leurs spécificités ? Est-ce qu’ils ou elles travaillent la nuit ? En marchant ? En étant interrompu toutes les 3 minutes ? Tout cela influence les choix de design.
Notre cerveau nous joue des tours, alors mieux vaut connaître les principaux biais cognitifs pour savoir les déjouer. En particulier, lors de la préparation d’un questionnaire ou d’un entretien, la formulation des questions peut biaiser les réponses.
Et nos propres besoins, on s’en cogne, ce n’est pas pour nous que nous designons ! Un mantra à se répéter chaque jour, à coller au dessus du bureau si nécessaire.
Lorsqu’on bloque sur un sujet, 2 solutions : en parler avec des collègues (ça aide souvent), ou faire autre chose et attendre l’illumination. Celle-ci peut survenir à tout moment, et surtout lorsqu’on ne s’y attend pas ! Il ne faut donc pas hésiter à travailler sur un autre sujet quelques heures ou quelques jours. La solution pourra venir d’elle même pendant ce délai, ou au moment de reprendre le sujet.
Quand on maquette, il faut imaginer l’IHM dans tous ces états possibles, pas simple de ne rien oublier ! Cette liste de 9 états m’y aide :
Plus on attend longtemps avant de prendre du feedback, plus celui-ci sera douloureux si on est parti sur une mauvaise voie (le bais des coûts irrécupérables !). La communication avec l’équipe décideuse sur ce qu’on fait, où on est, quelle sera l’étape suivante (surtout dans la phase exploratoire qui est souvent longue) est également hyper importante dans le cadre d’une relation commerciale : ça rassure, ça donne de la visibilité et ça inspire confiance.
Idéalement, dès le maquettage, pour récolter du feedback rapidement et ne pas perdre du temps et de l’argent à développer une solution inadaptée.
Nul besoin de se vexer, c’est la base du métier : on fait, on défait, on refait, on re-refait, jusqu’à obtenir quelque chose de vraiment adapté. Les personnes avec lesquelles nous échangeons (Product Owner, client·e·s ou usager·e·s) connaissent généralement mieux le métier que nous, et c’est en itérant avec eux qu’on obtiendra le meilleur résultat (bon, pas 100 fois en vrai hein !).
Parce qu’entre les maquettes basse fidélité et haute fidélité, certaines choses doivent être changées pour rendre le design agréable, et d’autres doivent rester identiques car elles ont été mûrement réfléchies en amont. Mais les graphistes ne peuvent pas le deviner, si on ne leur dit pas !
D’abord de notre côté pour vérifier que tout est bien comme on l’avait pensé. Si on a oublié de concevoir des états (on en oublie toujours) ou si techniquement ce n’est pas simple, les devs improvisent parfois. Alors autant jeter un œil avant que ça ne parte en prod’.
Ensuite, auprès des utilisateurs et utilisatrices, encore et toujours. Même si les maquettes ont été testées, ce n’est tout à fait pareil une fois développé. Et c’est leur avis qui compte vraiment !
Voilà, ça fait 10 !
J’ai fait un petit poster décoratif si ça vous intéresse, à télécharger ici.
Pas simple de choisir, mais je crois que ça résume assez bien ma pratique et les erreurs qu’il m’est arrivé de faire. Vous en voyez d’autres ?
Photo de bannière by Sergiu Vălenaș on Unsplash
Adaptation des outils aux personas et aux hypothèses à tester
Cet article a été écrit avec ma collègue Marion Georges. Nous sommes toutes les deux ergonomes à uxShadow, agence de design orienté utilisateurs de Sogilis.
Les Ergogames est un projet de sensibilisation à l’ergonomie à travers des jeux disponibles sur le web qui démontrent de manière ludique les principes essentiels de l’ergonomie numérique. Nous avons décrit dans des précédents articles la génèse des Ergogames et la manière dont ce projet a été mené en interne. Ce 3ème article vise à décrire la démarche que nous avons eu pour évaluer notre IHM avant de l’ouvrir au public. En effet, dans une démarche ergonomique, nous avons souhaité effectuer des tests utilisateurs pour améliorer Les Ergogames.
Comment rendre accessible à toutes les équipes de développement un concept testé et approuvé en interne ?
Depuis quelques mois, nous travaillons sur un projet interne avec mes collègues de Sogilis Lyon : développer une version web ouverte à toutes et à tous des Ergogames, un ensemble de petits jeux permettant de découvrir et de comprendre les bases de l’ergonomie (on en parlait ici). La vision de Sogilis étant de “rendre le développement informatique de meilleure qualité”, c’est pour nous important d’exploiter le travail de construction des jeux pour apporter notre contribution en partageant ces jeux afin qu’un maximum de personnes puissent les utiliser.
La thèse, une école du management
Ça fait longtemps que j’y pense, écrire un article sur ce que ma thèse m’a apporté dans mon métier actuel. C’est une question qui m’est régulièrement posée, en entretien mais également dans un cercle plus privé, ou par les membres de mon ancien labo de recherche : probablement un besoin de se rassurer sur le fait qu’ils m’ont aidé à m’accomplir telle que je suis aujourd’hui. Spoiler : bien sûr que ma thèse m’a apporté beaucoup, mes études m’ont construite à de nombreux points de vue et je ne serais pas la personne que je suis aujourd’hui si j’avais suivi des études différentes et été entourée de personnes différentes.
Je n’ai rien publié ici depuis janvier, gros contraste avec l’année précédente. J’ai été occupée par des aventures personnelles, je n’avais pas forcément d’idée d’article à écrire, ni l’envie ou le temps d’écrire. En gros, j’ai choisi de ne pas me forcer.
J’ai tout de même écrit 2 articles sur le blog de mon entreprise :
Les meilleures réussites business se construisent sur des expériences utilisateurs (UX) bien pensées, qui apportent de la valeur à l’usager∙e et répond à ses besoins. On parle souvent d’UX pour évoquer le produit fini, mais ne serait-il pas intéressant de s’intéresser à l’UX vécue par les développeurs∙ses lors de l’écriture du code ? En effet, les développeurs∙ses sont utilisateurs∙trices du code écrit par quelqu’un d’autre. Et de manière intéressante, ils ou elles sont également UX designers du code utilisé par d’autres.
Les 6 semaines qui viennent de s’écouler ont été intenses en activité. J’ai changé de boulot. J’ai participé à 6 jours de conférences. J’ai été oratrice dans 2 d’entre elles. Je me suis mise aux sketchnotes. Et j’ai fait plein de projets personnels de montage vidéo et photo pour Noël et anniversaire. Ouf, je souffle.
J’avais affirmé que je publierai mes sketchnotes sur mon blog, alors ça aura pris plus de temps que prévu, mais les voici.
Dans le cadre de mon prochain départ de mon entreprise actuelle, j’ai compilé divers documents de travail et articles de blogs autour de l’UX. Dans la partie méthodo, un article sur les tests utilisateurs manquait. J’ai donc rédigé le document suivant, adapté ensuite rapidement pour une publication sur mon blog.
Aussi souvent que possible, je fais passer des tests utilisateurs. Comme nous travaillons en méthode agile et que nous n’avons pas de budget pour mettre en place ces tests, il ne s’agit pas de tests très rigoureux type laboratoire de recherche, mais plutôt de tests sporadiques permettant d’apporter de la matière pour faire de l’amélioration continue sur les interfaces déjà développées. Je pourrais également m’essayer au guerilla testing qui est une méthode intéressante pour faire du test sans budget (aller interroger les gens dans la rue, dans un café, etc).
