Retour d'expérience après un an de collaboration entre UX designers et développeurs libres, dans le but d'améliorer l'usage du logiciel Tails.
Le but du logiciel libre Tails est de préserver votre vie privée et votre anonymat, de vous garantir un haut niveau de sécurité, c'est-à-dire de retrouver le même niveau de confidentialité que dans la vie hors ligne : lorsqu'on discute dans la rue, nos échanges ne sont pas systématiquement écoutés et enregistrés, contrairement aux échanges internautiques.
Tails est né de la volonté de rendre cette protection accessible à tous et toutes, d'être facile à utiliser, là où il fallait auparavant installer plein de trucs compliqués. Ses utilisateurs ne sont pas des geeks, mais des lanceurs d'alerte, des opposants politiques, des ONG, mais aussi des victimes de violences conjugales, pour lesquelles utiliser Tails permet de contourner le contrôle abusif exercé par le conjoint.
Problème : Tails reste encore trop difficile à utiliser.
S'intéressant depuis toujours au design dans le logiciel libre, NUMA a donc apporté son aide pour en améliorer l'expérience utilisateur. Plusieurs sessions de tests et de conception ont été organisées pour améliorer le projet Tails depuis son site web jusqu'au cœur de ses interfaces.
Après une collaboration d'un an, un très intéressant retour d'expérience conjoint de Fiodor Tonti et Claudio Vandi, UX designers à NUMA, et de Tchou, développeur contributeur libre à Tails, a été partagé lors de Pas Sage En Seine 2015. En voici (enfin) ma prise de notes.
D'abord observer les utilisateurs
La méthode de recherche a été le « test utilisateur ». Ressources nécessaires : des utilisateurs et de la patience. Pas besoin d'un laboratoire, ni d'outils particuliers. Il faut juste avoir envie de s'y intéresser, précise le dev. Concrètement, il s'agit d'observer des utilisateurs à l'œuvre et tout noter. Avec méthode.
Les utilisateurs observés sont pour la plupart des journalistes volontaires, qui ont déjà entendu parler de Tails et savent à quoi ça sert. Celleux-ci se voient confier des missions précises, représentatives des usages principaux de Tails : comment créer un document ? comment utiliser le mail une fois Tails lancé ? Il est important ici d'isoler des variables : identifier des buts clairs, élémentaires, afin d'identifier avec précision où l'utilisateur réussit et échoue. Ensuite, laisser les utilisateurs se démerder avec leur mission : l'équipe adopte une position d'observation, sans intervenir, même si l'envie démange de les dépatouiller.
Il faut tout prendre en note, mais attention à le faire de façon formelle, pour ne pas rester dans le subjectif et pouvoir analyser ensuite. Utiliser pour ça un rainbow spreadcheet permet de regrouper les notes par sources de problèmes, fréquence, et les hiérarchiser ensuite pour dégager leur impact sur le logiciel.
Résultat : trop difficile à… installer !
De nombreuses difficultés se révèlent, qui sont liées, moins aux tâches confiées, que l'on souhaitait observer, qu'à l'usage basique de Tails… à son installation même : carton rouge !
Ouvrir les yeux
Du point de vue du développeur, il faut faire un travail sur soi, parce qu'il est vraiment naturel, quand on développe un logiciel, de vouloir répondre à l'appel à l'aide d'un utilisateur en difficulté comme il est tout « aussi naturel de ne pas vouloir voir les problèmes ». Par exemple, sur l'installation, on pensait que ça marchait parfaitement : puisque ça fonctionnait, il ne devait pas y avoir de difficulté d'usage, pas besoin de tester. Or les tests ont montré que c'était au contraire le cœur du problème.
À l'observation des difficultés d'usage, quand on se dit « Ohlala, ça va être compliqué » (à corriger, à coder), c'est plutôt bon signe : c'est qu'on a identifié une vraie difficulté. Observer ainsi les utilisateurs permet de se décaler, sortir un peu de sa passion de développeur, pour voir autrement.
En effet, en tant que développeur, l'idée de ce que vous être en train de construire n'est pas du tout alignée avec l'idée que les utilisateurs en ont. Ce n'est pas forcément que le logiciel est compliqué, ni mal fichu, mais que les utilisateurs ne le comprennent pas. Parce qu'on ne leur explique pas ! En fait, Tails n'est pas bon dans sa communication.
Installation bloquante
Tails est un système d'exploitation « live », c'est-à-dire installé sur un support amovible, à partir duquel on fait démarrer un ordinateur : c'est-à-dire que vous pouvez démarrer, sur quasiment n'importe quel ordinateur, depuis un DVD, une clé USB, ou une carte SD.
Mais il est difficile de comprendre cela en visitant le site web de Tails. Pour nous les dev, c'est évident, mais en réalité les utilisateurs ne comprenaient pas du tout. C'est pourtant expliqué, mais avec des mots : trop peu expliqué, avec trop de mots.
De fait, l'installation s'avère très difficile. Bloquante. Il faut d'abord télécharger des logiciels qui permettent d'installer Tails. Les users téléchargeaient plusieurs fois le truc sans comprendre. Un user est resté bloqué 30 min ! sur le reboot… Enfin, les users n'identifient pas quand Tails se lance, ni donc quand ils bénéficient de sa protection.
En fait, tout le monde bloquait à l'installation. Pour les geeks, c'est facile, mais les users n'y arrivent pas. En réalité, qu'un utilisateur y arrive était exceptionnel. Et c'était parce qu'il était geek. La doc qu'on fournissait était trop laconique et les gens étaient perdus.
Recherche de solutions
Repenser en amont
Suite à cela, il a fallu repenser jusqu'au user flow, le parcours utilisateur, dès l'installation. On a repris toutes les étapes pour les remettre à plat : lesquelles peut-on supprimer ? Quels scénarios d'usage veut-on privilégier ? On s'est rendu compte qu'il y avait 13 façons différentes d'installer Tails : gros gloubi-boulga !
Dessiner avant de coder
La conception UX peut se faire très simplement, avec du papier et un crayon. Il faut d'abord réfléchir avant de se lancer dans le code. Si c'est clair sur papier, si d'autres réussissent à comprendre, c'est bon signe. Mais si un user ne comprend pas le process schématisé, ça ne sert à rien de le coder.
Mieux vaut commencer sur papier, plutôt qu'en codant direct, parce que, si on se rend compte que ça ne marche pas, il est plus facile de jeter le papier que de jeter tout le code. C'est aussi moins douloureux.
Pistes d'amélioration
Plutôt qu'une documentation complète, opter pour un dévoilement progressif de l'info évite de noyer l'utilisateur dans une masse d'info qu'il ne comprend pas, qu'il ne sait pas par quel bout prendre.
Deuxio : rapprocher l'info de l'endroit où en a besoin. Donner la bonne information dans le bon contexte. Souvent l'user bloquait parce qu'il n'avait pas l'info au moment où il en aurait eu besoin et il ne sait pas forcément que l'info existe et encore moins où la chercher. En réalité, il aurait fallu lire toute la doc avant, et l'avoir bien comprise, pour avoir une chance de réussir avec Tails.
Enfin, faire une vidéo pour expliquer les étapes ? Trop long ! En testant, on s'est rendu compte qu'un gif animé suffisait. Faites des choses simples et efficaces, qui coûtent moins de temps et d'énergie.
Pourquoi se préoccuper d'UX ?
Pour être utilisé
Se préoccuper d'UX est important si vous souhaitez que davantage de monde utilise ce que vous faites. Si vous n'avez pas besoin d'utilisateurs, alors pas besoin d'UX.
Découverte des UX designers dans cette collaboration : autant l'UX est naturelle est évidente pour les startups, autant ce n'est pas évident dans le monde libre. Dans le logiciel commercial, le besoin d'UX est implicite, car l'objectif étant de vendre, il est nécessaire de faciliter l'usage. Dans le monde libre et gratuit, c'est moins évident, certains logiciels libres n'ayant pas pour ambition d'être très utilisés.
Mais que Tails soit simple d'usage est incontournable, pour éviter, par exemple, qu'un blogueur au Pakistan qui a compris que Tails est indispensable pour sa sécurité, soit incapable de l'utiliser, malgré toute la bonne volonté qu'il peut y mettre, et se retrouve donc exposé. C'est la raison d'être de Tails : que ce soit plus simple que d'installer des tas de logiciels.
Pour éviter de contre-performer
Seconde raison : éviter que le manque d'utilisabilité produise l'effet contraire de celui voulu. Que les utilisateurs croient bénéficier de la confidentialité promise par Tails, ignorant qu'ils n'ont tout simplement pas réussi à l'installer, est un très sérieux problème pour un logiciel dont le but est de garantir la sécurité de l'utilisateur. Si l'objectif même du service est que les gens puissent agir en sécurité, mais que celui-ci ne permet pas d'identifier si on est dans un usage sécurisé ou pas, il faut savoir se remettre en question.
Pour éviter cela, il ne faut pas perdre de vue l'utilisateur auquel votre logiciel prétend rendre service.
Qu'avons-nous appris de cette collaboration ?
Ce qu'il faut savoir, quand on fait de l'UX, c'est qu'on remet en cause les fondamentaux. Il faut être prêt à se remettre en question, et accepter de questionner la raison d'être du logiciel. Et ça, c'est le dev qui le dit ! Ça va bousculer les choses. Et prendre du temps.
Les développeurs ont tendance à mesurer le progrès en nombre de lignes de code, de features produites, de tickets fermés… Mais ça ne compte pas dans l'expérience utilisateur. Il faut adopter une autre modalité d'appréciation, passer de feature-driven à value-driven development. Il ne s'agit plus d'apprécier si le logiciel ou une fonctionnalité marche, mais si elle sert. C'est-à-dire évaluer si le blogueur pakistanais a réussi à transmettre de l'information sans se faire choper par la police. Bref, on n'utilise pas les mêmes metrics pour évaluer un bon code et un bon design. Qu'un logiciel soit fonctionnel et qu'il soit utile sont deux choses très différentes.
Il y a un grand gap culturel entre UX et logiciel libre. Ce n'est pas un mariage évident. Autant on peut faire et distribuer des bouts de code assez facilement, autant l'UX est une démarche globale, avec une vision holistique du service. C'est donc compliqué à intégrer dans une équipe où chaque développeur bosse isolement sur un bout du projet.
Attention, se soucier de l'utilisateur, ce n'est pas satisfaire le moindre de ses désirs. Les UX designers rappellent qu'il faut :
- avoir la patience de considérer les feedback utilisateurs. Si quelqu'un fait un retour critique, ce n'est pas parce qu'il est con. Ni méchant. Il faut prendre ça comme une occasion d'améliorer.
- D'un autre côté, avoir l'intelligence de ne pas implémenter aussitôt la moindre chose demandée ou critiquée par les utilisateurs, mais prendre le temps de réfléchir, de tester. Suivre les demandes des users peut faire complètement dérailler un projet.
- Bref, quand un utilisateur demande un feature, la première chose à faire n'est pas de la coder, mais de demander pourquoi, c'est-à-dire d'identifier la source de la difficulté rencontrée.
Enfin, c'est plus facile si le souci de l'utilisateur est partagé par toute l'équipe et reste une vigilance constante : vaut mieux désherber régulièrement que de laisser une forêt de ronces s'installer. Les designers ne sont pas des magiciens.
Dernière chose : travailler ensemble, UX et dev LL, ça marche ! Pour finir : « J'invite tous les dev à payer un coup à un UX designer, à parler avec… Vous avez plein à y gagner ! » Hips :)
J'ai mis du temps à assimiler et retranscrire ce retour d'expérience passionnant. Ce qui est assez symptomatique, c'est que je ne comprenais rien lorsque le développeur parlait — trop de jargon technique pour moi — alors que son témoignage est vraiment intéressant : il m'a fallu réécouter plusieurs fois l'enregistrement pour bien comprendre et pouvoir ici en rendre compte.
Merci beaucoup à Tchou, Fiodor et Claudio de nous avoir partagé leur retour d'expérience après cette collaboration !
- Au programme : UX et logiciels libres : retour d'expérience (TAILS), Pas Sage En Seine, NUMA, 2015, avec archive vidéo.
- Le livetweet, avec questions-réponses de la salle
- Lire aussi : Tails, l'outil détesté par la NSA, qui veut démocratiser l'anonymat en ligne, Le Monde, 2014 et Tails raconté par ceux qui le construisent, par Amaelle Guiton, Techn0polis, 2014
- Rainbow Spreadsheet : A Collaborative Lean UX Research Tool, by Tomer Sharon, Smashing Magazine, 2013
Jeu de briques
Snake
Pacman
Bubble