Collaborer pour un design plus accessible : l’exemple d’Exodus Privacy

Quand on prend conscience qu’un site web destiné au grand public devrait être plus facile à aborder et utiliser, il n’est pas trop tard pour entamer un processus qui prenne en compte les personnes qui l’utilisent… L’association Exodus Privacy prend la plume sur ce blog pour raconter comment elle a, avec Maiwann, une UX designeuse, amélioré l’interface de sa plate-forme d’analyse.

Exodus Privacy est une association loi 1901, créée en octobre 2017 et dont le but est d’apporter plus de transparence sur le pistage par les applications de smartphones. Dès le premier jour, le public visé était un public non-technique, afin de lui permettre de comprendre et de faire des choix éclairés.

Parmi les outils que nous avons développés, la plateforme εxodus permet d’analyser les applications gratuites du Google Play store et d’en indiquer les pisteurs et les permissions. Cette plateforme a été très utilisée dès son lancement, mais elle n’était pas facile d’utilisation pour les néophytes.

Comme nous n’avions ni le temps ni les compétences en interne, nous avons décidé de rémunérer une personne experte pour adapter notre plateforme à ce public de non-spécialistes. Il nous paraissait important d’avoir une personne qui comprenne qui nous sommes et quelles sont nos valeurs, nous nous sommes tourné·e·s vers Maiwann, UX designeuse.

Exodus Privacy : Maiwann, peux-tu expliquer qui tu es et ce que tu fais ?

« Bonjour, bonjour ! Je suis Maiwann, UX·UI Designer dans la vie, amoureuse du libre et du travail éthique. Je suis aussi membre de Framasoft depuis quelques mois. Je fais beaucoup de choses variées au niveau numérique, mais qui peuvent se résumer en : du design (au sens « conception » du terme).

Du coup je vais rencontrer des utilisateurs et utilisatrices, leur poser des questions pour comprendre quels sont leurs besoins et leurs frustrations, les observer utiliser des logiciels et voir où ça coince, puis je réfléchis à la manière de répondre à leurs problèmes en concevant des parcours fluides. Et enfin je peux faire des maquettes graphiques pour donner un peu « corps » à tout ça ^_^ C’est d’ailleurs exactement ce qu’il s’est passé ici ! »

D’abord, définir les personnes concernées…

Ce projet devait se dérouler en plusieurs phases et il partait bien des besoins du public. Pour mieux comprendre cette étape, voici un petit extrait d’une conversation de septembre 2018 entre Exodus Privacy et Maiwann :

Maiwann : Quel est votre public-cible ?
Exodus Privacy : Le grand public, bien entendu !
Maiwann : il va falloir préciser un peu plus, car à s’adresser à tout le monde on ne s’intéresse véritablement à personne 🙂

Cela nous a obligé·e·s à réfléchir justement à ce que nous mettions derrière ce terme qui nous paraissait pourtant si évident. Nous avons donc défini deux groupes plus précis de personnes.

Nous voulions tout d’abord faciliter la vie aux médiateurs et médiatrices numériques car nous sommes convaincu·e·s que ces personnes sont les mieux placées pour pouvoir accompagner le plus grand monde à mieux appréhender les outils numériques. Nous les avons donc incluses dans les personnes visées.

Nous avons co-délimité une deuxième cible : des personnes non-techniques et curieuses, prêtes à passer un peu de temps à réfléchir à leur vie privée sur téléphone.

Puis formuler les besoins

Le mois de janvier 2019 a permis à Maiwann de mener 14 entretiens avec des personnes correspondant aux profils sus-cités, trouvées par le réseau d’Exodus Privacy ou par les réseaux sociaux :

 

Laissons Maiwann raconter cette étape :

« Grâce aux réponses sur les réseaux sociaux et sur Cryptobib et Parcours numérique, des listes de diffusion pour médiateur·ices du numérique, j’ai pu discuter avec les 2 catégories de public que nous avions définies ! Ensuite, pour chacun·e, il s’agissait de s’appeler soit par téléphone soit en visio-conférence, de vérifier qu’iels étaient bien dans le public visé, et de discuter pendant à peu près une heure. L’idée était de voir où étaient les manques, pour savoir de quoi εxodus avait besoin prioritairement : une refonte du site ? De l’application ? Une campagne de communication pour faire connaître leurs actions ? Ce sont les entretiens qui allaient nous permettre de le savoir !

Je demandais aux médiateur·ices comment est-ce qu’iels menaient leurs ateliers, et comment la question du téléphone était abordée. Et j’ai découvert que, si le discours pour protéger sa navigation sur un ordinateur était très rodé, le téléphone était un sujet compliqué car… les médiateur·ices n’avaient pas de réponse lorsqu’on leur demandait comment agir !

C’était d’ailleurs un cas identique pour les personnes qui répondaient individuellement : elles avaient bien conscience de l’enjeu de vie privée vis à vis de leur téléphone, même si ce que faisaient ces pisteurs n’était pas toujours très clair, mais ne voyaient de toute façon pas du tout ce qu’il était possible de faire pour améliorer les choses !

Après tous ces appels, j’avais de grands axes récurrents qui se dégageaient. J’ai donc dessiné un petit résumé schématique, et nous nous sommes appelé·e·s le 28 février pour discuter de tout ça et de ce sur quoi on partait. »

 

Une fois le diagnostic posé (il y a X pisteurs dans telle application), la personne se retrouve bloquée avec des questions sans réponses :
– Ok, il y a des pisteurs, mais on fait comment pour faire autrement ?
– Qu’est-ce que ça fait réellement, un pisteur ?

Ces questions, que nous avions par ailleurs régulièrement en conférence, par mail ou sur les réseaux sociaux, nous ont permis de nous interroger sur le positionnement de l’association. En effet, nous avons toujours défendu une démarche scientifique, qui montre « les ingrédients du gâteau », mais ne porte pas de jugement de valeur sur tel pisteur ou telle application… et donc ne valorise pas de solution alternative.

Après discussions, nous avons convenu de l’importance de pouvoir apporter des outils de compréhension à ces personnes, afin que celles-ci puissent, encore une fois, décider en connaissance de cause. L’idée était donc de créer une page qui explique les pisteurs, une page qui explique les permissions et enfin une qui répond à la question « et maintenant, que puis-je faire ? », en proposant un panel d’outils, de réflexes et de ressources.

La conception des maquettes

C’était donc à nouveau à Maiwann de travailler. Tu nous racontes comment tu as débuté les maquettes ?

« J’ai repris les schémas-bilans des entretiens pour définir les parcours principaux des utilisateur⋅ices :

Arriver sur le site => Chercher le rapport d’une application => Comprendre ce qu’est un pisteur ou une permission => Trouver comment améliorer la situation.

L’enchaînement entre ces actions devait être facilité dans le nouveau parcours, et le contenu non-existant (ou non intégré) mis en avant. Par exemple, pour « qu’est-ce qu’un pisteur », εxodus avait déjà réalisé des vidéos que les entretiens avaient tous remontés comme « très bien faites » mais comme elles n’étaient pas intégrées au parcours, beaucoup d’utilisateurs·ices pouvaient passer à côté. Pour la page Alternatives en revanche, qui était la demande la plus forte, tout a été créé depuis zéro, en privilégiant les alternatives accessibles aux non-informaticien·ne·s et tout de même respectueuses de la vie privée.

Il m’avait aussi été remonté que parfois les formulations n’étaient pas très claires, parfois en anglais ce qui contribuait à un sentiment de contenu non-accessible à des néophytes. Cela a fait aussi partie des améliorations, en plus des pages explicatives, qui sont là pour dire « vous ne savez pas ce qu’est un pisteur ? Pas de souci, on vous l’explique ici ».

Et pour le reste, un travail d’harmonisation et de hiérarchisation du contenu pour que les différentes catégories de contenus soient bien distinctes les unes des autres et compréhensibles a permis de réaliser une refonte graphique aux petits oignons ! »

 

Le développement des maquettes

L’ensemble des membres d’Exodus Privacy étant bénévole, et donc le travail conséquent pour notre énergie et temps malheureusement limités, nous nous sommes mis d’accord sur un travail de développement itératif afin de mettre à disposition des utilisateurs et utilisatrices les nouvelles pages et fonctionnalités au plus tôt.

Après la présentation des maquettes en mai 2019, nous avons découpé les différentes tâches sur notre git, celles-ci ont été priorisées pour s’assurer que les besoins les plus importants soient traités en premier lieu, comme la page « mieux comprendre ». La majorité de ces tâches ont été implémentées, ce travail étant agrémenté d’allers-retours avec Maiwann afin de s’assurer que nous allions dans la bonne direction sans rater l’essentiel.

Notre code étant libre et open-source, une partie des fonctionnalités a même été faite par notre communauté !
Une partie du travail reste à faire, n’hésitez pas à aller jeter un œil si vous avez des compétences en développement !

 

Fiche météo-france "avant"
Fiche d’Exodus pour l’application Météo-France avant

 

La fiche de l’application Météo-France après travail d’UX

Et maintenant ?

Le travail n’est pas totalement terminé et, grâce au Mécénat de Code lutin, nous avons pu poursuivre ce projet de refonte, mais pour l’application cette fois.

Laissons donc les mots de la fin à Maiwann…

« Il reste une étape de test utilisateur·ice à réaliser, pour bien vérifier que cette refonte va dans le bon sens, est adaptée aux besoins et que nous n’avons pas oublié un élément important, ou laissé un trou dans la raquette dans lequels les utilisateur·ice·s vont s’engouffrer !
De même, nous avons amorcé un travail d’harmonisation de cette refonte pour que l’application corresponde aussi aux maquettes, car c’est le point d’entrée principal du public (puisqu’il est question d’applications et de téléphone portable, c’est logique qu’elle soit privilégiée !).

J’ai hâte de réaliser ces dernières étapes (avec l’aide de Schoumi côté application !) pour finaliser ce super projet, car il contribue à démontrer qu’il est possible de réaliser des choses techniquement pointues, tout en parvenant à les rendre accessibles à des personnes non techniques, soit directement en s’adressant à elles, soit en fournissant un outil pertinent pour les médiateur·ices du numérique.

Cela contribue à mon monde idéal qui connecte le monde du libre et de la protection de la vie privée aux non-connaisseur·euse·s, et je ne peux qu’encourager d’autres projets qui ont cette démarche de travailler avec des designers pour y parvenir ! »




Des Framapads plus beaux, grâce à une belle contribution

Framapad, c’est un de nos plus anciens services. C’est une page d’écriture, en ligne, ou vos ami·e·s peuvent venir collaborer en direct à la rédaction d’un texte. Un « Google docs », mais sans Google, sans pistage et même sans inscription !

C’était déjà pratique…

Le principe est simple : vous allez sur Framapad.org, vous décidez de la durée de vie de votre pad et de son nom, vous cliquez sur « Créer un pad » et… ayé, vous êtes dessus. Il ne vous reste plus qu’à choisir votre pseudo (si vous voulez que vos potes vous reconnaissent) et votre couleur d’écriture !

Oh, et si vous avez des ami·e·s (ou juste des gens avec qui vous collaborez, hein), il vous suffit de leur copier/coller l’adresse web du pad dans un message pour qu’iels viennent travailler avec vous sur votre texte, chacun avec son pseudo, chacune avec sa couleur d’écriture. Quand on arrive, ça ressemble à ça :

 

Framapad n’est pas développé par nos soins : c’est une instance (une installation sur un serveur) du logiciel libre Etherpad (ou Etherpad-lite pour être précis), et vous pouvez retrouver d’autres instances hébergées par La Quadrature du Net, le chaton Infini, les activistes de RiseUp et bien, bien d’autres !

… et maintenant c’est Beau !

Nous venons de procéder à une mise à jour d’Etherpad (vers la version 1.7.5) sur nos serveurs… Et désormais, Framapad, ça ressemble à ça :

 

Alors oui, c’est un peu injuste, car derrière cette mise à jour il y a de nombreuses contributions qui rendent le code plus solide, plus résilient, plus pratique aussi… Mais forcément, les changements esthétiques sautent aux yeux. Et en même temps, dans un milieu du logiciel libre qui (souvent) peine à améliorer l’expérience des utilisatrices et utilisateurs, il nous semble important de le faire remarquer !

Grâce à quelques modifications de CSS (les feuilles de styles des sites web), Etherpad est devenu plus lisible, plus aéré, plus pratique à utiliser. Cela signifie concrètement que vous aurez beaucoup moins de « non mais je veux pas utiliser ton truc, c’est moche et je comprends pas » lorsque vous proposerez une telle alternative à GoogleDocs !

Pour la petite histoire contributopique

Cette contribution qui améliore le look et la lisibilité d’Etherpad, nous la devons à Sébastian Castro, développeur principal de GoGoCarto, et mrflos, connu du monde du libre pour être le co-auteur de YesWiki. C’est en leur qualité de Geeks du Mouvement Colibris qu’ils se sont intéressés à Etherpad. En effet, nous accompagnons depuis deux ans déjà ce mouvement dans sa démarche de dégoogliser les pratiques de ses plus de 300 000 membres. C’est dans ce but que mrflos leur a concocté le site colibris-outilslibres.org qui rassemble plusieurs services libres :

Seulement voilà : fidèles à la devise du mouvement auquel ils participent, Sébastian et mrflos n’ont pas voulu simplement « utiliser » Etherpad, mais ils ont souhaité faire leur part. Et c’est ainsi qu’après avoir fait des tests et des bidouilles pour améliorer le look de l’Etherpad des Colibris, mrflos a fait remonter leur contribution à la communauté.

 

Après plus de 3 mois d’affinages du code, de discussions (plus de 60 commentaires variés sur la proposition), la contribution a trouvé sa place dans le code officiel d’Etherpad, et pourra être plus facilement utilisée par des milliers d’utilisateur·ices.

Depuis la sortie de la nouvelle version (la 1.7.5), toutes les instances Etherpad (dont Framapad) peuvent désormais profiter d’un thème plus clair, lisible, et qui facilite l’adoption d’outils libres par un plus grand nombre de gens !

Une fois encore, ceci n’est qu’une des milliers d’histoires de contributions libres que l’on pourrait raconter. Elle montre simplement que, lorsque l’on part à la rencontre de communautés différentes de la sienne, cela donne lieu à des contributions que nous n’aurions pas forcément imaginées ;).




Et si on tenait compte des utilisateur·ices dans les projets libres ?

Eh oui, chez Framasoft, on n’a pas peur d’utiliser des titres (légèrement) provocateurs — certain·e⋅s diraient même pièges à clic — quand on a envie de vous parler de sujets que l’on juge vraiment importants.

Et aujourd’hui c’est… l’UX Design dans les projets libres !

« UX-kwa ? Un logiciel libre, c’est créer du code qui fonctionne sans bugs, lui mettre une licence libre et c’est bon, non ? »
Alors, oui, mais pas que. Du coup on va faire le point avec vous sur ce qu’est l’UX Design et pourquoi c’est important (surtout pour le libre).

Et pour ça, on va vous raconter une première expérimentation réalisée lors du Framacamp !

Framacamp : la colonie de vacances de Framasoft ?

Il y a deux évènements annuels très très importants pour Framasoft :

  • l’Assemblée Générale de l’association (AG), où on va faire les bilans moraux et financiers, ainsi que définir les actions et les campagnes à venir,
  • et le Framacamp !

Le Framacamp, c’est l’occasion pour les salarié·es et les membres de l’asso de se réunir de manière conviviale pour se rencontrer, tisser des liens, boire des coups, délirer et surtout débattre, faire avancer les projets et expérimenter.

Au cours du Framacamp, Maïtané a proposé un atelier « Méthodes UX » pour présenter 4 méthodes utilisées par les UX designers et les faire tester aux développeur·ses sur place.

Alors déjà, c’est quoi l’UX Design ? UX Design, ça veut dire User Experience Design en anglais, ce qui revient à Design de l’Expérience Utilisateur·ice en français. C’est une discipline qui a pour objectif de prendre en compte les besoins, les attentes et les usages des utilisateur·ices visé·es pour proposer un service ou outil qui leur convient le plus possible et leur proposer une expérience positive. C’est donc très loin de « juste » réaliser des maquettes graphiques !

Pourquoi parler d’UX avec des devs ? Parce que tout le monde est convaincu chez Framasoft que le logiciel libre c’est bien, mais s’il est utilisé par un maximum de personnes c’est quand même mieux. Et il n’y a pas moyen de demander aux utilisateur·ices d’utiliser des logiciels qui ne sont pas correctement conçus, ou qui ne prennent pas en compte leurs besoins.

C’est un peu ça. L’UX, c’est créer des logiciels :

  • utiles (car ils apportent de la valeur aux utilisateur·ices) ;
  • utilisables (car ils peuvent être utilisés sans provoquer (trop) de frustration) ;
  • et utilisés (car du coup les utilisateur·ices ont envie de… les utiliser !).

 

Du coup, pour comprendre ce qui se passe dans la tête des utilisateur·ices, les UX designers ont tout un panel de méthodes et de techniques. Au cours de cet atelier « Méthodes UX », nous en avons testé quatre :

  • Le test des 5 secondes
  • L’AttrakDiff
  • Les courbes d’évaluation UX
  • Les tests utilisateur·ices.

Il existe évidemment un très grand nombre de méthodes, selon les étapes du projet, les objectifs visés, le nombre de participant·es (présent·es ou à distance), etc. Si vous souhaitez en découvrir d’autres, nous vous conseillons l’excellent ouvrage Méthodes de Design UX : 30 méthodes fondamentales pour concevoir et évaluer les systèmes interactifs, de Carine Lallemand et Guillaume Gronier.

 

Les méthodes de cet atelier ont notamment été choisies en s’inspirant de l’atelier qu’ils ont donné ensemble à ParisWeb 2015.
Il s’agit de méthodes plutôt simples à comprendre et complémentaires pour prendre le pouls de son projet du point de vue de l’expérience utilisateur.

Note anti-troll : les participant·es étaient quasi exclusivement des membres de Framasoft, donc pas vraiment représentatif·ves du public réel des outils testés, nous en sommes bien conscient·es. En temps normal, on aurait dû composer un panel réaliste de participant·es mais on n’avait pas d’autres cobayes sous la main !

Le test des 5 secondes

Pour tester quoi ?

La première impression qu’ont les utilisateur·ices en voyant une interface.

Comment on fait ?

On montre un écran d’une interface (logiciel, application mobile, site web, …) pendant 5 secondes, puis on pose quatre questions, qui permettent de connaître les a prioris des utilisateur·ices lorsqu’ils découvrent l’interface, et ce qu’ils en retiennent. Pratique si vous voulez savoir si votre interface est compréhensible au premier abord.

Cas pratique

Maïtané nous a fait essayer cette méthode sur une maquette d’interface de création de pads collaboratifs.

Maquette de l’interface de création de pads collaboratifs du Mouvement Colibris — Chez Framasoft, on propose le même service via https://framapad.org

 

Nous avons donc eu 5 secondes de visualisation de la page avant de pouvoir répondre aux questions.

Et là… révélation ! Sur la troisième question (définir les objectifs du système), on s’est aperçu qu’une des fonctionnalités n’était pas claire pour tout le monde.

Et donc, en à peu près 3 minutes de test, sur un groupe d’à peine 10 personnes, nous avions déjà relevé un problème d’ergonomie suscitant de l’incompréhension chez plusieurs d’entre nous, malgré l’interface très simplifiée. Pas mal pour un début !

Et si vous avez plusieurs prototypes, cette méthode peut permettre de soumettre chacun à un groupe différent pour comparer les résultats :

Les trois visuels ont été réalisés par Kristof Dreano, graphiste des Colibris, et sont disponibles sous licence Creative Commons BY SA.

L’AttrakDiff

Pour tester quoi ?

Pour analyser quantitativement l’expérience utilisateur, suivant ses qualités pragmatiques (j’ai l’impression que le produit me permet de réaliser ma tâche facilement) et hédoniques (j’ai envie de l’utiliser, ça me fait plaisir de l’utiliser)

Comment on fait ?

L’AttrakDiff est un questionnaire standardisé, il y a donc « juste » à récupérer la grille de questions, la grille d’analyse  et hop ça fait des Chocapics !

 

 

 

Un exemple de rendu final :

Source : UXmind.eu

Cas pratique

Pour l’atelier lors du Framacamp, on a pris le cas de Framadate avec une grille de questions plus réduite que celle normalement utilisée. Après un rapide dépouillement des résultats, on découvre sans trop de surprise que Framadate est un outil très « orienté tâche », c’est à dire fonctionnel et pragmatique mais qu’il lui manque un aspect attractif et procurant une expérience plus positive. Une tendance courante du libre ?

Les courbes d’évaluation de l’expérience utilisateur·ice

Pour tester quoi ?

Les courbes vont représenter, au cours du temps, les ressentis des utilisateur·ices sur différents points (que se soit l’expérience utilisateur·ice générale, son attractivité, sa facilité d’usage, …), ce qui permet d’avoir une vision sur la durée des différentes améliorations et détériorations !

Comment on fait ?

On demande à l’utilisateur·ice de tracer une courbe, en mettant en abscisse sa relation envers le produit (de « très positive » à « très négative ») et en ordonnée le temps. Dans l’idéal, elle place à certains endroits les événements marquants de son expérience, pour que l’on sache à quoi est dû un changement de direction de la courbe.

Cas pratique

Vous pouvez le faire chez vous, là, tout de suite ! Un papier, un crayon, et vous pouvez noter l’évolution dans le temps de votre rapport à Twitter par exemple ! Ce qui est assez marrant à voir, c’est la dégringolade de l’adhésion à Twitter lorsque Mastodon est apparu, mais vu le public testé ce n’était pas très étonnant. 😉

Le meilleur pour la fin : les tests utilisateur·ices !

Pour tester quoi ?

Ben, ce que tu veux, en fait !

Comment on fait ?

On demande à l’utilisateur·ice de réaliser une « mission » qui est cohérente avec sa potentielle utilisation du logiciel. L’idéal c’est de le-la laisser assez libre, pour observer de quelle façon iel va remplir sa mission (on peut être surpris !). Ensuite, on lui demande de bien vocaliser ce qu’iel fait, pour qu’on puisse suivre son schéma de pensée.
Du côté des développeurs·euses, il est très important de ne pas intervenir au cours du test. Même si ça vous démange « mais le bouton est juste là ! »  et qu’on a très très envie de le montrer à l’utilisateur·ice. Le mieux à faire c’est de prendre des notes sur papier et de débriefer à la fin du test, une fois la mission remplie (ou son échec constaté).

Cas pratique

C’est le moment de laisser les développeurs en parler 😉

Et les développeurs, ils en ont pensé quoi ?

Interviewés : Luc, Thomas, Florian, Benjamin, Marien.

Salut à tous ! Pour commencer, vous pourriez vous présenter rapidement ainsi que vos projets ?

Florian : Salut ! Ici Florian aka mrflos, développeur web du mouvement Colibris, une association d’éducation populaire qui inspire, relie et soutient des personnes qui se mobilisent pour la construction d’une société plus écologique et plus humaine. Afin d’outiller nos membres avec des logiciels et services libres en adéquation avec nos valeurs, nous avons rejoint le collectif des CHATONS et nous proposons la plateforme https://colibris-outilslibres.org à toutes et tous.

Je suis par ailleurs co-auteur et principal mainteneur de https://yeswiki.net , un wiki ouvert et simple, avec des possibilités de base de données avec des restitutions variées (trombinoscope, cartes, agenda…)

Thomas : Salut ! Je suis Thomas alias tcit, développeur web au sein de Framasoft, une association promouvant les logiciels libres et plus largement l’univers libre. Nous avons dernièrement lancé une campagne Contributopia qui vise notamment à concevoir autrement des outils numériques. En dehors d’être responsable d’une bonne partie des outils Framasoft, dont certains ont été créés ou largement améliorés, j’ai aussi été mainteneur des logiciels wallabag (un service de lecture différée) et Nextcloud (une alternative à Dropbox et Google Drive).

Benjamin : Hello ! Ici Benjamin (ou encore bnjbvr), ingénieur logiciel chez Mozilla sur la machine virtuelle JavaScript / WebAssembly qui tourne dans le célèbre Firefox. Sur mon temps libre, je suis un peu membre de Framasoft où j’essaie d’organiser des ateliers de contribution au logiciel libre ouverts à tou.te.s, au sens large, en essayant d’attirer des personnes qui n’y connaissent pas grand chose. Je développe également Kresus, une application web de gestion de finances personnelles libre et auto-hébergeable, pour pouvoir comprendre comment notre argent est dépensé, comme une alternative aux apps Bankin ou Linxo.

Marien : Salut, pour ma part je suis Marien (alias, hum… Marien), ingénieur dans une boite qui s’appelle Sogilis et où je fais beaucoup de choses, mais notamment du développement d’applications web sur mesure. Je suis aussi membre de Framasoft : j’y maintiens Framaboard et je passe un peu de temps à consigner tout ce qu’il se passe au sein de l’asso dans notre wiki. Je réfléchis aussi à comment décloisonner les développeurs du Libre des sujets techniques (cet atelier tombait donc à pic !). Enfin, je développe Lessy, un logiciel de gestion de temps et j’ai été le développeur principal de FreshRSS, un agrégateur d’actualités, qui est depuis passé dans les mains d’une communauté active.

Luc : もしもし! (oui, Luc se met au Japonais, il a sûrement écrit un truc très chouette mais on n’a rien pané — NDLR)

Moi c’est Luc, alias (frama)sky, adminSys de Framasoft, et développeur aussi. J’ai notamment écrit Lstu, Lutim, Lufi et Dolomon, qui sont utilisés chez Framasoft sous les noms Framalink, Framapic, Framadrop et Framaclic.

 

L’UX, ça te parlait avant l’atelier ? C’était quoi pour toi ?

Florian : Comme je ne suis pas un très bon développeur, je compense en essayant de piocher dans les gros sites, des idées d’interfaces efficaces. Je me suis vite rendu compte que cela allait au delà de l’interface, et que c’était la convivialité de l’outil et l’expérience dans sa globalité qui faisait qu’on l’adoptait.

Pour moi, l’expérience utilisateur est primordiale, car si le but est d’amener nos utilisateurs à contribuer, il faut leur faciliter la tâche, et la moindre expérience négative peut facilement démotiver. D’ailleurs assez souvent les utilisateurs ne reprochent pas le manque de fonctionnalités d’un logiciel libre par rapport à son concurrent non libre, mais le fait qu’il soit plus difficile à utiliser (ou moins ergonomique).

Thomas : De même, la prise en compte de l’aspect convivial lors de mes développements se résumait à piocher des bonnes idées ici et là, suivre quelques pistes d’amélioration pour que certains aspects soient plus accessibles et des actions plus faciles à réaliser. J’avais largement conscience des manques que j’avais sur ces points.

Benjamin : J’ai eu l’occasion de discuter avec des designers, notamment parce que l’équipe de Kresus désirait avoir un nouveau logo. Alors que je pensais qu’il allait s’agir simplement de choix esthétiques, nous nous sommes retrouvés à parler d’aspects de bien plus haut niveau, comme les émotions que l’on voulait transmettre, ou les principes que devait respecter l’application. Même si ça relève du design, ces aspects se transposent également très bien à l’UX, et cette discussion a été le point de départ d’une réflexion plus globale pour re-prioriser certaines fonctionnalités et certains manques de Kresus. Par ailleurs, certains retours de personnes expérimentées en UX design nous avaient bien résumés l’intérêt de l’UX : un élément d’interface ou une action peu claire ou compliquée, c’est une incompréhension ; et une incompréhension, c’est une question au mieux (donc du support à effectuer), un blocage au pire (donc un.e utilisateur.ice perdu.e). Ce discours m’a marqué et incité à me plonger encore plus dans le sujet.

Marien : J’ai la chance de travailler dans une boîte qui employait déjà une UX/UI designer lorsque je suis arrivé. Aujourd’hui j’ai deux autres supers collègues ergonomes et/ou UX designers avec qui je peux travailler et échanger (je recommande d’ailleurs leurs « ergogames » lors desquels j’ai appris et pu mettre des mots sur plein de concepts), j’étais donc déjà plutôt bien rodé avant cet atelier et persuadé des bienfaits de l’UX. Pour moi, toute l’importance de cette discipline est de remettre l’utilisateur·ice au centre des préoccupations du logiciel : on cherche avant tout à comprendre ses problèmes et ses besoins. Ça peut paraître idiot dit comme ça, mais bien souvent j’ai affaire à des utilisateurs qui expriment leurs problèmes à travers des solutions qu’ils ont eux-mêmes imaginés. Le problème c’est qu’ils ont toujours une connaissance limitée de ce qui peut se faire (et moi aussi !) La complexité consiste à faire abstraction de ces solutions pour essayer d’en imaginer une qui sera potentiellement mieux adaptée aux besoins exprimés bien souvent indirectement. C’est là tout le talent de l’UX designer. 🙂

Une autre chose que j’apprécie – et c’est assez contradictoire avec mon statut de développeur – c’est que ça nous fait redescendre de notre piédestal. Dans les projets de logiciels libres, le développeur est toujours celui qui imagine, décide et code ; ça ne fait pas de mal de se remettre en question parfois ! Et puis nous avons déjà suffisamment de responsabilités comme ça (« Code is Law » comme dirait l’autre), pas la peine de nous en rajouter.

Luc : Oui… et non. Oui, parce que je savais que ça existe, non parce que je n’avais pas le temps de me pencher dessus.

 

Est-ce que tu avais déjà appliqué ou envisagé d’appliquer des méthodes UX sur tes projets ? Est-ce que par exemple tu avais déjà fait des tests utilisateur·ices auparavant ?

Florian : Au sein des contributeurs YesWiki, certains avaient déjà fait des tests utilisateurs, mais moi-même, je n’avais pas eu l’occasion de tester. J’avais entendu parler d’une méthode rigolote, qui consiste à tester un site en étant complètement saoul pour voir si la navigation était facile ! Une version plus « sobriété heureuse » consisterait à juste plisser les yeux et voir si vous arrivez à naviguer sur votre site, ou sinon http://www.drunkuserexperience.com/?url=https%3A%2F%2Fframasoft.org .

Thomas : Il y a quelques mois je ne désirais rien de plus que des mockups tout faits que j’aurais juste à intégrer. Aujourd’hui j’ai compris qu’il est préférable d’avoir un processus d’accompagnement, de travail itératif en collaboration et en discutant avec quelqu’un ayant les compétences.

Les seuls tests utilisateurs que j’aie effectués dans le cadre de mon travail se résumaient à envoyer un aperçu quasiment achevé à des membres de l’association n’ayant pas ou peu de compétences techniques, mais je n’étais pas derrière eux pour obtenir d’autres retours que ceux qu’ils peuvent me faire eux-mêmes. En dehors de cela, zéro, nada.

Benjamin : Non, jamais, je partais donc d’une expérience totalement vierge.

Marien : Oui, mais c’est assez récent au final ! J’avais fait appel il y a un an à Marie-Cécile Paccard pour m’aider sur Lessy. L’expérience a été tout aussi déstabilisante qu’enrichissante : alors que je pensais qu’on parlerait de l’UX de l’application, on a parlé de beaucoup de choses en amont, notamment à quels problèmes je cherchais répondre et à qui je m’adressais. Au final, elle a appliqué les méthodes UX à l’idée du projet elle-même ! Pour ce qui est des tests utilisateurs, j’ai participé à une session mais en tant qu’utilisateur, je connaissais donc déjà le format mais pas l’angoisse de se faire « juger » son travail ! J’avais toutefois eu le sentiment que c’était un format lourd à mettre en place et j’ai été agréablement surpris de la manière dont ça s’est passé au Framacamp.

Luc : À chaque phase de tests des nouveaux services Framasoft, on avait des retours de la part des membres de l’asso, mais ça s’arrêtait là.

 

Qu’est-ce que tu as pensé des méthodes vues ? Une méthode favorite ?

Florian : Le panel des méthodes vues était très large et c’est difficile de donner une favorite, car elles sont complémentaires ! Comme elles sont toutes assez courtes, je recommanderais plutôt de les faire toutes pour avoir une idée globale. S’il fallait choisir, la méthode du test en 5 secondes est vraiment rapide à faire, l’expliquer et la faire ne prend pas plus de 5 minutes, douche comprise ! Après, les tests utilisateurs sont ceux qui amènent sans doute le plus de pistes concrètes d’évolution pour son projet car on voit de façon flagrante là où l’utilisateur a des difficultés.

Benjamin : Si l’on se concentre uniquement sur l’aspect UX, la méthode des 5 secondes me semble plus amusante qu’utile, parce qu’elle ne reflète pas le fait que les gens cherchent toujours un peu avant d’abandonner. Elle permet cependant de dégager un avis esthétique et une émotion de manière très pertinente, ce qui provoquera l’envie d’utiliser par la suite. Clairement, le test d’utilisation, effectué sur Kresus, a été le plus utile et le plus fructueux pour moi : malgré la frustration qui parfois s’installait, puisque j’avais envie de dire « mais non, c’est pas comme ça qu’il faut faire », ou encore de dire « tu as remarqué qu’il manquait telle fonctionnalité, tu es au moins la 100ème personne à me le dire », j’ai trouvé très intéressant le fait de tout garder pour moi, et de juste écouter les utilisateur.ice.s pour comprendre quels étaient leurs points bloquants et leurs interrogations.

Marien : Très clairement j’ai préféré les tests utilisateurs. Je rejoins pas mal Benjamin là-dessus, j’ai le sentiment que c’est ce qui a été le plus utile. Mais c’est aussi l’aspect humain que je trouve intéressant : cette posture tout d’abord d’écoute et d’observation silencieuse (ça empêche de tenter de se justifier !), puis l’échange qui suit après. Ça permet aussi aux différents protagonistes de se rencontrer et de mieux se comprendre. Toutefois, pour un logiciel Libre ça peut être compliqué à mettre en place par sa nature décentralisée. L’AttrakDiff est peut-être alors plus adapté tout en se rapprochant de ce que peut apporter les tests utilisateurs d’un point de vue retours UX. J’imagine assez bien utiliser la méthode des 5 secondes « à l’arrache » lors de différents évènements. Concernant les courbes d’évaluation, je ne connaissais pas du tout et j’ai trouvé le concept super intéressant même si j’imagine un peu moins quoi faire des résultats.

Thomas : Je rejoins les deux commentaires précédents pour dire que j’ai probablement considéré le test utilisateur comme le plus productif du point de vue d’un développeur. Cela permet de découvrir des utilisations complètement à l’opposé de ce que l’on peut imaginer, et ainsi sortir de sa bulle de filtre concernant la vision que l’on a de son projet. J’aime aussi également bien le test des 5 secondes, mais je l’ai trouvé particulièrement efficace surtout lorsqu’on imagine un utilisateur arriver sur un site web sans à priori dessus, pas forcément quelqu’un de très motivé voir obligé d’utiliser une application.

Luc : Tout comme les autres, le test utilisateur est sans doute le plus intéressant pour les développeurs. On a ainsi un retour rapide mais surtout concret sur les points de friction.

 

C’est quoi le ressenti pendant et après les tests utilisateur·ices, quand on observe un·e utilisateur·ice manipuler et faire des retours sur son projet adoré ?

Florian : Mon cas est particulier, car on testait des visuels fait par Kristof, le graphiste des Colibris, pour le test des 5 secondes, donc j’ai moins pris pour moi les retours. Par contre j’ai été testeur pour Luc et son projet dolomon.org, et c’était bien drôle, je l’ai vu rougir quand je n’ai pas cliqué sur le lien « comment ça marche » et directement m’empêtrer dans les fonctionnalités compliquées, mais je crois que je me suis comporté comme un utilisateur lambda ! 😉

Benjamin (en continu depuis la question précédente) : C’est extrêmement utile comme exercice, parce que chaque élément remarqué devient utilement concret et peut se transformer en un « ticket » ou un élément partiel de ticket, tout du moins. C’était aussi marrant de voir, lors du débriefing, chacun exposer les *problèmes* auxquels iels étaient confrontés, et d’y aller de sa *solution* pour les résoudre, sans connaître l’ensemble des contraintes du projet. 🙂

En tant que mainteneur d’un projet, cela m’a permis de rester humble auprès du travail restant à accomplir, et ne m’a pas atteint émotionnellement ou attristé, parce que je considère que tout est toujours améliorable, et la finalité commune (de cellui qui teste ou cellui qui observe) est d’améliorer le logiciel dans son ensemble, pour le rendre plus utilisable, donc plus utilisé. 🙂

En dehors de la sphère propre au logiciel Kresus, je me sens plus légitime et j’ai aussi beaucoup plus confiance en ma capacité à mener et assister à des tests utilisateurs, ce qui me sera utile lors de nos célèbres Contrib’Ateliers .

Marien : Le plus compliqué était sans doute de rester silencieux ! D’ailleurs j’ai posé une ou deux questions au début pour essayer de comprendre le ressenti de l’utilisatrice (mais j’ai vite arrêté parce que je sentais que ça pouvait influer sur son utilisation). Il y a une forme de frustration qui se développe au fur et à mesure que la personne observée cherche mais ne trouve pas (pour les deux tests effectués j’ai eu envie de dire « Tu n’as pas besoin de rechercher l’icône de flux RSS sur le site, l’outil le détecte pour toi ! ») Une chose amusante en revanche, c’était de se sentir par moment tout aussi perdu que la personne qui testait (« Bah tiens, pourquoi ça réagit comme ça ? », « Oh un bug… ah non c’est vrai, c’est le comportement « attendu » »). Au final on n’est pas seulement observateur de l’utilisateur·ice, mais aussi de sa propre application ! En sortie de cette expérience, j’ai été rassuré sur la facilité de mise en place, ça m’a vraiment réconcilié avec cette méthode UX. Hâte de réitérer l’expérience !

Luc : C’est dur pour moi de me taire… et de voir que les utilisateurs ne prennent pas le temps de lire les explications qu’on s’est fait c… suer à écrire !

 

Suite à l’atelier, est-ce que tu penses que tu vas essayer de mettre en place de l’UX ? Si on te trouve un·e UX Designer, tu l’accueilles les bras ouverts ?

Florian : Oui, bien sûr, c’est un retour précieux, et une science à part entière ! Vu le peu de moyens humains derrière un projet libre, on se retrouve souvent à être en même temps le graphiste, l’UX designer, le développeur et le chargé de comm. de ce projet libre, et souvent quand on touche à trop de choses simultanément, on ne fait pas tout bien. J’ai très envie d’approfondir le sujet, si possible accompagné, mais j’attends aussi de voir comment en tant que développeur, implémenter les améliorations d’UX, car les choses les plus simples ne sont pas toujours les plus faciles à coder ! Donc vive la complémentarité mais en ayant la curiosité de s’intéresser à ce que l’UX Designer apporte et réciproquement, histoire de s’enrichir entre designer et développeur et d’être réaliste sur ce que l’on peut faire ensemble !

Benjamin : Absolument ! Au titre de mon projet Kresus, je vais sûrement réitérer l’expérience, et nous serions ravis d’accueillir un.e UX designer pour nous aider à assurer un suivi de l’amélioration de l’UX dans le projet. Nous allons d’ailleurs revoir nos méthodes de contribution pour simplifier la découverte et la participation à ce projet. Par ailleurs, je vais très probablement réutiliser les méthodes vues ici lors des Contrib’Ateliers, pour pouvoir tester et faire tester d’autres projets qui ont bien besoin d’aide, en espérant que cela mène à des actions concrètes et un suivi de la part des auteur.ice.s.

Marien : Je ne vois pas trop comment répondre négativement à cette question après les réponses que j’ai données jusqu’ici. ^^

Oui, évidemment que j’en accueillerais un ou une ! Mais j’aimerais aussi réfléchir à comment faciliter une telle collaboration. Aujourd’hui les outils que nous avons à notre disposition ne sont pas adaptés (je ne vise absolument pas GitHub ou plus généralement les forges logicielles, ce serait mal me connaître). Et si, justement, on appliquait les méthodes UX pour réfléchir à un tel outil ? 😀

Thomas : De même, c’est évident qu’il faut que nous impliquions davantage des gens comme des UX designers prêts à participer dans nos projets libres. Et pour accueillir des gens qui ne sont pas développeurs, ce n’est pas uniquement une question de réfléchir à un processus pour l’entrée de nouveaux contributeurs, c’est peut-être penser dès le début à faire en sorte que les décideurs et responsables de projets ne soient pas uniquement des développeurs, que ces derniers ne soient pas toujours au centre du projet. C’est loin d’être facile dans le milieu du logiciel libre, mais je veux y croire. 🙂

Luc : Non, je souhaite continuer à faire des logiciels inaccessibles. Tout le monde sait bien que les logiciels tournent bien mieux sans utilisateurs pour déclencher des bugs ou poser des questions. 😛

 

Et la tradition Framasoft : un dernier mot pour la fin ?

Florian : Merci Framasoft de décloisonner le libre et d’ouvrir vers de nouveaux horizons avec des outils qui ont du sens et des valeurs et qui pourraient grâce à des apports dans des domaines comme l’UX, de plus en plus répondre aux besoins des usagers ! J’en profite aussi pour inviter des animateurs de réseaux, les techniciens, les citoyens engagés, et toutes les personnes de bonne volonté de venir participer au projet Contributopia, qui pourrait être un beau levier de changement sociétal et de convergence !

Benjamin : Merci Framasoft pour ce Framacamp, et merci beaucoup Maïtané pour nous avoir présenté et ouvert les yeux sur l’UX, dans la joie et la bonne humeur, sans m’avoir fait ressentir ce tristement classique blocage entre les développeur.euse.s et les designers. J’invite tout le monde à s’intéresser également à ces méthodes, ne serait-ce que pour en comprendre les enjeux, qui dépassent largement la simple facilité d’utilisation et l’aspect esthétique des choses. :3

Marien : Au final, comme dans tout projet, l’important c’est de se parler et de s’écouter. Ce Framacamp a été une formidable occasion de faire cela dans une ambiance détendue. Je suis vraiment ravi de pouvoir apporter ma patte au projet Contributopia qui se propose justement d’encourager et défendre tout ça. Je suis persuadé que nous sommes sur la bonne route (mais qu’est-ce qu’elle est longue !). Et merci aussi à Maïtané de nous avoir proposé cet atelier qui m’a permis (enfin) de mettre en pratique des choses qui traînaient dans ma tête depuis des mois.

Thomas : Merci aux membres de Framasoft et à tous les contributeurs pour leur bonne volonté toujours impressionnante. Merci à ceux qui animent des ateliers qui permettent de faire des énormes pas en avant à chaque fois. J’ai hâte de voir ce qu’on va tous faire ensemble !

Luc : Merci à tous ceux qui vont mettre en place des ateliers UX lors des prochains contrib’ateliers. 😁

À leur tour, les auteur·ices de cet article remercient chaleureusement Florian, Thomas, Benjamin, Marien et Luc pour le temps qu’ils ont bien voulu nous accorder pour répondre à nos questions. Merci également à Carine Lallemand pour nous avoir autorisé·es à utiliser les images d’illustration de l’AttrakDiff et des courbes d’évaluation UX.

Que vous soyez UX Designer (professionnel ou amateur) ou simple utilisateur·rice qui veut contribuer au logiciel libre et au libre, n’hésitez pas à venir à notre rencontre, soit sur Framacolibri ou lors d’un des Contrib’ateliers.  ;-).

 

 

Pour aller plus loin

  • Lallemand, Carine. Paris Web 2015. Atelier Évaluer l’UX : des méthodes simples mais efficaces !

Paris Web 2015 Atelier « Evaluer l’UX : des méthodes simples mais efficaces ! » from Carine Lallemand