Summary: En ce 8 mars, journée internationale des Femmes, j'ai laissé l'entièreté du blog, à des femmes que j'ai eu l'occasion de croiser, et qui m'ont fait l'honneur de me permettre de reproduire quelques uns des articles qui leur tenaient à coeur.

En ce 8 mars, journée internationale des Femmes, à la suite d'une idée de @kozlika qui me plu de suite, j'ai laissé la "tribune", l'entièreté du blog, à des femmes que j'ai eu l'occasion de croiser, et qui m'ont fait l'extrême plaisir et honneur de me permettre de reproduire quelques uns des articles qui leur tenaient à coeur.

Parfois, la vie met sur votre chemin des femmes avec lesquelles vous échangez des idées sur votre métier, vos projets (libres), la Société ... et vous marque d'une manière ou d'une autre, que ca soit à ParisWeb, sur Irc, dans un pub, un resto...

Voici donc ces "Fées marquantes" :

Parmi elles, Coralie Mercier, Romy Duhem-Verdière, Sophie Drouvroy et Emilie Diab

Coralie Mercier

I work for a neutral intermediary

I follow the International Committee of the Red Cross on Twitter and they twitted this earlier today:

@ICRC: Our role as a “neutral intermediary” is at the heart of #humanitarian action. Our director of operations explains: [link]

Original Message:

Our role as a "neutral intermediary" is at the heart of #humanitarian action. Our director of operations explains: http://t.co/A2d49Gi6ER

— ICRC (@ICRC) 30 mars 2013

The main part of their micro-post, “neutral intermediary” is at the heart of #humanitarian action, particularly resonated with me for several reasons, that I want to attempt to articulate in this post of what I did at one point as a hobby and how, in a way, some choices, people and events led me back to it.

My years with the French Red Cross

In my late teenage years I enrolled at the French Red Cross and during several years –until I started university– I participated in social, medical, training, fund-raising and first aid actions. It occupied my weekends, almost all my holiday time and several week evenings. I was very committed. I came to the Red Cross spurred by my twin brother who had recently become involved. It sounded useful and fun.

It was indeed useful and fun. Even sorting clothes was fun. It was daunting; several piles of garments and shoes, tall as dunes, dumped in the vast depot next to the offices, that we had to plough through during hours. But at the end of the day (that is, late at night) we felt we had accomplished a useful action. Clothes and shoes, categorised and packed, were ready to be picked and handed off somewhere else. My friends and I would find a bar open till late for coffee and drinks, sometimes a game of cards, but mostly bonding.

I met all kinds of people, from all walks of life, most of them interesting, some of them inspiring –students like me, nurses, police officers, business people, house wives, etc. I learned to give first aid, to operate a radio, to drive an ambulance (in particular to park it), to lead a team of first-aid workers, to cook for a crowd, to identify priorities, and to put things into perspective. I saw, heard, and experienced things that made me fully aware how lucky I was, and what a fine life mine was.

I don’t know if I was particularly gifted or actually good at it (I felt I was good), but my satisfaction was such that I wanted to make this my job. There even was a school I thought I might attend, Bioforce, which “specialises in ‘support functions’ (logistics, project coordination, administration and finance, human resources…) and in the field of water supply and sanitation.”

I didn’t attend that school. I went to a local university instead, embarking on a different path. A few years later I looked for a job. I was a temp for a while. I worked as a clerk in a British law firm, although I tried very hard to wiggle out of this, as soon as I saw the place and realised the work conditions were going to be terrible. I passed the one interview I so wanted to fail. Thankfully it was a short mission.

Discovering the world of a Research Lab

I got my next job by luck. A friend of mine, whom I had met while studying in Edinburgh, let me know she knew someone whose mother worked with someone who needed a temp for a semester. Two actually. And my friend was on the market too, so it was perfect for the two of us. We both interviewed on the same day. We had been pre-assigned a position but after interviewing they changed their mind and swapped. She joined the administrative and legal department at INRIA Sophia Antipolis, I joined a research project as administrative aid.

My years of volunteering and charity work were far behind me. The researchers I met were committed and inspiring people. Most wore shoes but many didn’t. Most people appeared to not see the people around them, absorbed as they were. All had pens in the breast pocket of their shirt, or the pocket of their shorts. Most carried laptops. There were whiteboards everywhere and I had no idea what the colourful scribblings and equations meant.

In that INRIA research project, I learned to type on a qwerty keyboard, to use e-mail on exmh, to print from a unix terminal, to get geek humour. I also learned LateX. Just for fun. When the end of my mission was near I wrote a fictitious humorous report, in LateX, featuring some of the people that crowded our floor. A thirty or so page report that I gave to the two project managers and a researcher I was particularly fond of. In exchange (not really), I was congratulated by the Director of the institute, and the project managers each gave me the bestest recommendation letters ever. I was on the dole for five months afterwards. My great letters, for all the power that I thought they wielded, didn’t get me my next job.

Joining the W3C

Lucky again, someone who knew me was asked to tell me that the World Wide Web Consortium needed an administrative aid and that I should apply. The W3C was hosted at INRIA Sophia Antipolis and oddly enough people there seemed to remember me and speak highly of me! I interviewed and was hired. That was 14 years ago.

What we do at W3C is basically convening the people who make the Web and the people who consume the Web, around a neutral table. The staff (there are between 60 and 70 of us, mostly technical, located throughout the world) is involved to help the Web stakeholders converge. From that collaboration, web standards are born, refined, and perfected.

At W3C, I met the most incredible colleagues and co-workers, the most inspiring people, the most dedicated folks, bright, clever, helpful, friendly, reliable and supportive. Working with them, doing our job, doing this job, is fulfilling and gratifying.

It’s been a while so I have learned so much that it is difficult to synthesise. The one easy thing that comes to mind is NOT that I learned HTML or CSS (however, some of that I did learn), it is that I learnt to pack lightly, pragmatically and efficiently for trips abroad. We used to travel a lot. We still travel but not as much. I visited a big city for the first time during a W3C trip to a WWW conference. It was in Toronto. Then Boston, Tokyo, Hong Kong, Hawaii, Western Europe, Montreal, etc. I now pack in twenty minutes and travel with my purse, one carry-on and a laptop bag. For short trips, the carry-on is a small backpack.

I can say that I have learned various jobs within our organisation. I started as administrative aid, and as such I organised meetings, ordered stationary, managed hirings and interns, I wrote internal policies, then managed the local office. I joined the Communications team and wore several hats. From secretary of the Advisory Board, translation community monitor, blog master, to Community Manager. I gather the press clippings, I send transition announcements to our Members when a technology progresses from one state to another, ultimately reaching that of Standard. I write to our Web site, which I occasionally break so I sweat a bit and eventually fix it. I do other internal comm things too.

A couple years ago I had a skills assessment. I was at a point in time I wanted to focus on what I was good at, and what it was that I was skilled for. The exercise was interesting and useful. I was told my area of interest revolves around humanitarian activities and care giving. And that I have more than one string to my bow. No surprise, really, but it was reinforcement that I was in my field.

My job is a passion. It may not be the humanitarian field action I dreamt of as a young woman, but many in our trade liken our job to humanitarian work. And indeed, we are a “neutral intermediary” at the heart of making free and open Web standards.

billet à retrouver à sa source

Romy Duhem-Verdière

UX et logiciels libres : retour d’expérience (TAILS)

Pas Sage En Seine, NUMA, jeudi 18 juin 2015

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, l’incubateur numérique NUMA a 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.

Quantifier les retours d’usages et problèmes observés

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 : quel gloubi-boulga !

Il a fallu repenser le parcours utilisateur pour l’install…

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 design.

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 quand même 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 design, 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 particulièrement 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, slides de la présentation, ainsi que 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.

billet à retrouver à sa source

Sophie Drouvroy

Je ne pense pas trop vous faire découvrir Sophie, que j'ai rencontrée il y a des années, au hasard d'un resto un midi avec le sieur @notabene, puis revue lors d'un mémorable Ligthning Talk à ParisWeb2012

Emilie Diab

Je ne pouvais pas finir sans lui faire un petit coucou, elle qui ne publie plus (DoooOOmage), et, que j'aprécie également beaucoup ;-)