L'ergonomie, indispensable à l'adoption massive du libre - PSESHSF2016

De April MediaWiki
Aller à la navigationAller à la recherche


Titre : L'ergonomie, indispensable à l'adoption massive du libre.

Intervenants : Matthias Dugué (m4dz) - Luc Chaffard

Lieu : PSESHSF - Pas Sage En Seine - Hacker Space Festival

Date : Juillet 2016

Durée : 39 min 45

Pour visionner la vidéo

Licence : Verbatim

Statut : Transcription MO

Description

Une informatique libre est synonyme d’une société libre. Une adoption massive est nécessaire afin d’atteindre cet objectif.

Afin d’y arriver, une interface utilisateur facile d'approche et ergonomique, construite avec le support de ses utilisateurs, est la clé.

En partant de l'approche développée par une équipe de libristes, Cozy Cloud, nous verrons comment écouter ses utilisateurs et les impliquer dans les étapes stratégiques du projet, du support au design en passant par le développement : les mains dans le cambouis, laissez vos utilisateurs hacker vos interfaces.

Transcription

00'

Matthias : Ce n'était pas prévu mais nous voilà quand mème pour vous parler un peu d'ergo et de libre et de la nécessité de travailler l'ergo et de faire de l’ergo intelligemment quand on veut faire du libre, si on veut faire les choses bien jusqu’au bout. Alors qui qu'on est ? Ton micro, sinon les gens ne t’entendent pas en direct. Coucou les gens !

Luc : Ça va être un petit réflexe à prendre ça. Je suis Luc, le product designer de chez Cozy.

Matthias : Moi je suis M4dz, je travaille chez Cozy également, je fais du dev d'interface, principalement. Avec Luc, on travaille conjointement sur le design et sur l'ergo des interfaces de notre produit. Notre produit c'est donc Cozy. Cozy, pour ceux qui ne savent pas, c'est une solution de serveur </>open source personnel, auto hébergeable. L’idée c’est de permettre aux gens d’installer leurs propres instances de serveur et via des outils qui sont intégrés à l’ensemble, de pouvoir reprendre le contrôle sur ses données, de pouvoir se réapproprier tout ça, se libérer des GAFA ou des GAFAM, ou des GAFAMeee, mettez ce que vous voulez derrière, en gros de redevenir vraiment possesseur de ce qu'on a et d’arrêter de disséminer un peu des choses.

Pourquoi je vous dis ça ? Pour une raison simple c'est que si on veut que ça marche et si on veut que les gens adhèrent à notre produit et s'en servent au maximum et donc se libèrent au maximum, on n’a pas le choix, il va falloir que ça passe par une adoption de masse, parce que tout seul on ne gagnera jamais la guerre. Et pour cette adoption de masse, eh bien il faut que l'ergo soit au cœur de notre processus de réflexion. Sinon, les amateurs éclairés pourront toujours s’en sortir. Les gens qui ont juste besoin que ça marche seront clairement perdus avec ça.

Petite démonstration par l'exemple. Ça c'est le bureau GNOME de 2002. Je ne vous fais pas le topo, GNOME, tout ça, etc. C'est tiré des notes de version de GNOME.

Ça c'est le bureau GNOME 3, 2011, dix ans plus tard, cinq ans déjà, et il y a quand même eu un gap assez énorme entre ça, qui était utilisable, mais qui piquait un peu et ça, qui est utilisable et qui est déjà un peu plus mousse. Après on aime ou on n'aime pas, ce n'est pas forcément la question. Perso GNOME n’est pas mon bureau de prédilection, mais force est de constater que sur la même période de temps Mac OS faisait aussi un gap entre 2001 et 2010 avec une vraie progression en termes d’ergo et GNOME a suivi le même mouvement et, au final, on retrouve des paradigmes à peu près équivalents. Ça, ça a été très pensé au départ pour travailler sur de la tablette. L’idée c’est vraiment de permettre aux gens de s’approprier l’outil pour pouvoir s’en servir, parce que si on les force à utiliser un truc qui ressemble à Windows 95, ça va être un peu plus tendu quoi ! Donc il va falloir prendre ça en main dès le départ et il faut le penser.

Luc : Attention, moment ???, si on veut une adoption de masse, il faut forcément rendre le produit accessible au maximum de gens.

Donc, prenons par exemple notre ami à tous Google, qu’on aime tous ici, Google, à l’époque, quand ils sont arrivés avec leur moteur de recherche, ils avaient juste un moteur de recherche. Leur plus gros concurrent, qui était en face d’eux, Yahoo, on arrivait sur leur site, c’était un peu de tout, de rien, des news, des images, enfin un gros n’importe quoi et on sait maintenant qui est devant tout le monde à l’heure actuelle. Donc autant s’inspirer de nos ennemis pour mieux les combattre.

Matthias : C’est Rage Against The Machine. C’est la slide corporate. Open source, ergo et design. Le statut de la relation entre les trois et les univers entre les trois, c’est que eh bien c’est compliqué. C’est compliqué parce que l’open source, le libre, l’ergo, et le design ensemble, ils ont parfois du mal à dialoguer.

Luc : Tout simplement, quand on arrive sur un logiciel libre, première phase à faire, l’installation pour la plupart des logiciels. Le commun des mortels n’a juste même pas envie. Ça demande des process des compliqués, une documentation que la plupart des gens n’arrivent pas à lire. Il faut un bac + 15, les gens ne vont pas à ce stade. Et même pour le peu des élus qui y arrivent, ils arrivent sur une interface, certes qui a des belles promesses, mais qui est juste inutilisable. Qui paraît cohérente pour un ingénieur, mais pour quelqu’un, on va dire, de plus normal, du commun des mortels, ça n’a aucun sens.

Matthias : Tout ça, ça implique un vrai manque de confiance entre les différents acteurs qui collaborent au projet. Il y a des gens qui dev dans la salle ? Il y a beaucoup de devs dans la salle, qui font un peu d’interface, un peu de machin comme ça ? D’accord OK . Il y a des gens qui font de l’ergo pur et dur ? OK. Ouais, en mode comme ça quoi ! Voilà ! En brasse coulée ! En gros, l’un des principaux soucis, c’est qu’il y a vrai manque de dialogue et un vrai manque de confiance entre les différents acteurs du projet. Quand vous développez une interface en tant que dev et que avez imaginé votre produit, vous, vous savez très bien où vous voulez aller. Donc pour vous c’est limpide. Ça ne le sera pas forcément pour l’essentiel des gens. Donc il faut collaborer avec des gens qui sont capables de vous apporter du savoir-faire, vous apporter de l’expérience, de l’expertise, des ergonomes, par exemple, des designers, entre autres, mais ça veut dire qu’il va falloir faire confiance à ces gens-là, il va falloir travailler avec ces gens-là et pas contre ces gens-là.

Donc le problème c’est qu’on est dans une espèce de relation qu’on a nommée assez aimablement une relation « égosexuelle », je nomme le « aimablement » quand même, parce que très vite on en vient à faire de l’entre-soi. On fait un produit, on l’a pensé pour nous, on l’aime bien, c’est notre bébé, on l’a vachement pensé, on le raisonne énormément. C’est super ! Pas très inclusif, mais c‘est super ! Donc l’enjeu c’est d’apprendre à vivre ensemble, c’est d’apprendre...

Luc : À travailler ensemble. Inaudible. Un, deux.

Matthias : Tu as un choc de micro ! Interlude. Ah c’est possible. Ça fait de la lumière. Tiens, parle avec moi !

Luc : On va se mettre avec Matthias. Bonjour Matthias. [Luc enlace les épaules de Matthias.]

Matthias : Coucou les gens !

Luc : Si la femme de Matthias regarde, il ne se passe rien, je tiens juste à le dire. En gros, la preuve en est c’est parfait pour cette slide, Matthias est développeur frontpage, je suis designer, nous partageons la même culture. On fait tous les deux partie de la génération Dragon Ball Z. On a passé beaucoup plus de temps derrière notre ordi ou notre petite ??? plutôt que dehors à jouer au ballon.

Matthias : Aller, au parc.

Luc : Je t’ai déjà vu jouer au ballon, excuse-moi Matthias, je ne suis pas bien en forme aujourd’hui. On partage des mêmes valeurs. On a peut-être un langage différent parce que, à un moment de notre vie, il y a en a un qui a choisi les crayons de couleur alors que l’autre a préféré se focusser sur l’ordinateur, mais malgré tout on partage des mêmes valeurs sauf que le langage est différent. Et c’est juste une communication qu’on a besoin de se réapproprier et être capable de ne pas juger l’autre parce qu’il n’utilise pas les bons termes. Et juste s’écouter et être capables de partager ensemble.

Matthias : Tu veux qu’on s’embrasse là ?

Luc : C’est un peu cochon ça !

Matthias : Non, on ne va pas le faire. Du coup, il y a une très belle citation dont je n’arrive pas à retrouver la source, que je vais peut-être un peu démesurément attribuer à Stallman qui est en face, donc coucou, et qui dit : « Si le libre ne parvient finalement qu’à libérer que du code source ça sera un échec : « Si vous retrouvez la source, j’offre des câlins, vraiment ! Je n’arrive pas à remettre la main dessus. L’idée c’est vraiment de dire ouvrir des choses, c’est super, libérer des choses c’est bien. Si tout ce qu’on arrive à libérer derrière ce n’est que de la ligne de code, on aura perdu quoi ! La philosophie est nettement plus énorme que ça. Elle va bien au-delà de tout ça.

Luc : Du coup l’ergonomie, eh bien késaco ? Qu’est-ce que ça veut dire ? C’est un joli terme.

Matthias : J’aime bien késaco !

Luc : C’est principalement ce qu’on utilise par le terme UX qui veut dire user experience en anglais donc expérience de l’utilisateur. C’est le principe d’offrir une utilisation de votre produit sans friction. La personne qui va venir là, elle n’est pas là pour vous faire plaisir, elle est là pour qu’on lui simplifie la vie sur une tâche de son quotidien. Elle n’est pas là pour réfléchir comment votre produit fonctionne et pourquoi il y a ça ici ou comment j’accède à ça, comment je configure telle chose ou quoi. Non ! La personne est venue parce qu’elle a un objectif, elle a compris une valeur ajoutée et son seul objectif, c’est d’être badass, c’est ce que vous lui avez vendu quoi : votre produit lui permet de résoudre des problèmes dans son quotidien qu’il ne pouvait pas avoir ailleurs. Ce n’est pas comprendre votre produit.

Matthias : Ça nécessite de savoir qui est votre utilisateur. Donc quand vous commencez à travailler sur une solution, quand vous commencez à réfléchir à un produit, vous avez une idée, un projet, un machin qui va changer la vie des gens, vous avez raison, on en a besoin. Il faut déjà savoir à qui vous vous adressez. Savoir à qui vous vous adressez ça veut dire déterminer un ensemble d’utilisateurs, en marketing on parle de niche ou de marché. C’est ça, c’est de savoir à qui vous voulez vous adresser. Parce que simplement dire mon produit s’adresse aux gens qui ont Internet, vous ciblez quand même une portion extrêmement large de la population. Ça va être extrêmement compliqué de les avoir. Donc il faut être suffisamment précis.

Et deuxième principe à garder à l’esprit, toujours, c’est que, même si vous avez imaginé votre produit, même si vous le connaissez, même si vous le savez, que vous le vivez, vous n’êtes pas un utilisateur avec un pouvoir de vote supérieur à celui des autres. Vous n’êtes qu’un utilisateur parmi tant d’autres. Ce n’est pas parce que vous avez votre usage et votre réflexion que c’est celui de l’ensemble des gens. Au contraire votre usage sera souvent un peu biaisé parce que vous connaissez votre produit. Donc il faut garder ça à l’esprit.

Il faut déterminer un parcours utilisateur. Déterminer un parcours utilisateur qu’est-ce que c’est ? Eh bien c’est déterminer quelle est la fonctionnalité phare de votre produit ou de votre solution. On ne fait pas des couteaux suisses, on ne fait jamais des couteaux suisses. La philosophie UNIX c’est ça, c’est un outil, une chose, et ça le fait bien, et ça ne fait que ça. Finalement, c’est ça qu’il faut appliquer quand vous concevez un nouveau produit, c’est que, même s’il y a une myriade de choses autour, vous avez une fonctionnalité qui est le cœur même de votre produit et c’est ça qui le fera vivre. Donc il va falloir trouver ce que c’est que cette fonctionnalité et il va falloir précisément déterminer comment on y accède et comment on s’en sert. À partir du moment où vous déterminez ce passage-là, ce parcours-là, le parcours de l’utilisateur, vous avez déjà libéré et défriché 60 % du boulot.


11’ 28

Luc : On a souvent aussi une confusion entre le principe de design et d’ergonomie. Le principe de designen fait, souvent également appelé UI, User Interface, c’est la partie graphique de son interface. Donc c’est se dire « ce bouton va être bleu parce que le bleu renvoie à telle émotion ou renvoie à mon produit qui a choisi cette couleur pour x raisons. » Je ne fais partie de votre branding, je ne sais pas pourquoi. Et l’ergonomie, donc l’UX qui est là, sur la partie comportementale. Donc comprendre le behavior de votre utilisateur et de dire, je prends l’exemple d’un bouton qui est un peu ridicule, mais bon, de se dire « ce bouton je vais le placer à cet endroit, ça va être mon action principale, parce que sur cette page, à ce moment-là, c’est ce qu’il y a de plus cohérent pour mon utilisateur, c’est ce qu’il a envie de faire. »

Après toute cette belle théorie qu’on va dite vous allez nous demander bullshit ou pas quoi ? Je pense que ce n’est pas non plus trop compliqué de vous expliquer que ouais, forcément, ça va améliorer la satisfaction de votre utilisateur pour la simple et bonne raison que votre produit n’est plus fait sans lui, mais il est inclus dans une boucle avec lui. Donc chaque intervention sur votre produit est faite avec cette personne qui l’utilise. Donc forcément ça va également augmenter votre rétention d’utilisateurs. Les personnes nouvelles qui vont arriver, de base, un produit qui a été fait avec d’autres gens comme elles, il y a de grandes chances qu’elles y restent et qu’elles se sentent à la maison. Et forcément, vous allez aussi réduire vos coûts de développement, pour la simple et bonne raison que vous allez arrêter de faire des trucs, perdre du temps en développement, l’envoyer dans la nature, voir ce qui se passe, ne pas savoir vraiment si c’est utilisé ou pas, les problèmes qui sont dessus, etc. Là vous rentrez dans une boucle où chaque chose qui est codée en soi a été validée. Donc ce ne sont plus des hypothèses, mais vous vous basez sur des données.

Donc, en gros, l’ergonomie qu’est-ce que c’est ? C’est créer une solution avec vos utilisateurs pour qu’ils se sentent à la maison, en fait. Tout simplement.

Matthias : Ça c’est bien beau, c’est de la théorie c’est super, voilà comment ça marche. Question c’est : comment est-ce qu’on fait ça ? Comment est-ce qu’on arrive à ce degré-là ? Une bonne pratique, qui est celle qu’on essaie de mettre en place le plus possible chez Cozy c’est de travailler de façon user centric, donc travailler sur l’utilisateur, avec l’utilisateur, et ne pas le faire intervenir en fin de boucle. Ça veut dire que dès le départ, quand vous avez une hypothèse à valider, quand vous avez une idée qu’il va falloir confronter, on va déjà faire intervenir les utilisateurs, avant même que la fixture soit disponible, avant même que ça soit codé, que ça soit enfoncé dans le code, on va commencer à en parler aux gens. On va commencer par leur dire « voilà, on a pensé à ça, qu’est-ce que vous en pensez ! ». On va commencer à échanger avec les gens. Parce que travailler comme ça, ça va permettre de collecter des infos, de collecter leurs retours, de voir un peu ce dont ils ont envie, ce dont ils ont besoin. Synthétiser ces infos-là, les croiser, voir un peu ce qui s’en dégage, trouver les grandes tendances, les grands concepts, et puis, en tirer quelque chose de concret, quelque chose que vous allez vraiment pouvoir utiliser.

Vous avez plusieurs moyens de faire ça. Vous pouvez passer par plein de canaux et vraiment je vous encourage à passer par plein de canaux parce que, pour trouver les gens qui vont être accrochés à votre produit, vous n’avez pas le choix, il va falloir aller les chercher. Et vous ne pouvez pas aller les chercher si vous les faites sortir de leur zone de confort. Il faut aller les voir. Il faut aller les retrouver. Donc des canaux vous en avez plein : des forums, parce que c’est là que les utilisateurs lambda vont aller discuter le plus possible, l’IRC pour le support, les réseaux sociaux qui vont servir de levier pour attirer des gens, les plateformes de social coding pour pouvoir attirer des développeurs parce que les développeurs vont peut-être plutôt vous faire des retours sur des bugs et des tickets dans les issues dans les plateformes de gestion plutôt que de passer par les forums, etc. Donc c’est à vous d’être tentaculaire et ce n’est pas à vos utilisateurs de s’adapter à votre unique canal de discussion. Vous avez besoin d’adresser un maximum de monde.

Une fois que vous avez trouvé vos utilisateurs, l’important c’est de réussir à en tirer les informations dont on a besoin pour réussir à avancer. Donc ce sont des process d’interview, c’est le concept idéal, finalement, plutôt en face à face ou en petits groupes. En tout cas toujours avec une présence physique, même si ce n’est que de la visioconf, parce que ça va vous permettre à un moment d’avoir aussi une part de langage émotionnelle qui est importante. Il faut que les gens soient à l’aise quand ils discutent avec vous. Il faut que vous parliez à bâtons rompus de votre produit. Donc vous commencez. Vous, vous vous êtes défini un objectif. Vous savez ce que vous allez vouloir obtenir de votre utilisateur, quelles infos sont essentielles pour vous. Mais ce n’est pas comme ça qu’il faut le présenter à votre utilisateur. Il faut que ça soit une discussion sur un coin de table dans un bistrot. Il faut que le mec se sente bien. Même nous d’ailleurs. Il faut que tout le monde se sente bien, que votre utilisateur soit bien et qu’il ait juste envie d’en profiter et que vous puissiez discuter de votre produit, vous soyez suffisamment neutre pour ne pas trop l’influencer, pas le guider, pas noter. Ne prenez pas des notes ! Prenez des notes après, évidemment, puisque vous en avez besoin pour revenir dessus, mais ne prenez pas des notes en même temps. Il n’y a rien de pire que de parler à un type qui prend des notes. On a l’impression qu’il n’écoute pas ce que vous en train de lui raconter. D’un seul coup, ça ferme les gens et puis il n’y a plus d’échange, de vrai échange concret, émotionnel. C’est de la discussion, c’est de la discussion simple. Mais ça marche bien ! Nous on a des super retours quand on arrive à organiser des ateliers comme ça avec les utilisateurs. Alors, de part notre structure un peu décentralisée, on le fait par petits groupes, donc on fait cinq/six personnes et puis on discute un peu. Il en sort des idées qu’on laisse maturer après. Ce n’est pas grave, ça prend du temps, mais voilà ! Au moins il y a des choses qui en ressortent et puis ça décante.

Luc : Une fois que vous avez collecté toutes ces données, c’est là où vous pouvez enfin retourner derrière votre petit bureau, enfin avec vous-même, et du coup, avec toutes ces informations, le plus gros challenge que vous allez avoir à ce moment-là, c’est d’être capable d’extraire l’information. Les gens aiment dire des choses. Il y a une grande différence entre la demande et le besoin. Quelqu’un va essayer de dire n’importe quoi et, au final, il faut comprendre pourquoi il l’a dit. Comment, dans son usage, je pourrais, en fait, lui simplifier la vie ? Quelle est vraiment l’information à extraire de ce qu’il m’a raconté ? Être capable, aussi, de croiser du coup toutes ces informations collectées avec tous mes utilisateurs. Être capable de prioriser ce qui est important dans ce qu’on m’a dit. Où je vais ? Où sont sont mes erreurs ? Qu’est-ce que j’ai fait de complètement ridicule ? Pourquoi les gens n’arrivent pas à faire telle action sur telle page ? Apprendre, du coup, de toutes ces données, en les croisant.

Une fois que vous avez tout ça, c’est là où vous pouvez vous amuser avec votre petit papier à faire, des petits ???, qui est de faire des sketches sur papier ou, si vous êtes plus à l’aise, vous pouvez directement partir sur Gimp à faire des formes un peu plus simplifiées. Si vous sentez encore plus à l’aise vous pouvez vous amuser à mettre votre charte graphique à l’intérieur pour donner une sensation un peu plus réelle. Si vous êtes vraiment motivé, vous pouvez aller même jusqu’à utiliser des prototypes dynamiques type, InVision ou ???. Je n’ai pas, je ne connais pas de logiciels open source malheureusement qui font ce genre de choses. Je m’en excuse de donner des logiciels privateurs.

Matthias : Pas encore !

Luc : Pas encore, mais j’espère que ça va donner des idées à certains. Et en fait, ces prototypes dynamiques permettent à travers des images de mettre des zones cliquables et de donner l’impression d’une vraie app codée, alors que non, c’est juste du bluff. Ce sont des images et on clique et ça nous envoie à un lien vers une autre image. Et rien qu’avec ça, en fait, on peut de nouveau tester rapidement sans développement, ça prend en général pas plus de quelques jours, quand on commence à être un peu à l’aise dessus. Et une fois de plus, ça permet de collecter de l’information, de collecter de nouveau de l’information sur ce qu’on a fait, ce qu’on a fait rapidement, genre sketcher sur un bout de papier, en terme général, vous avez une idée, vous avez fait attention à ce que les gens vous ont dit. Vous challengez ce que vous avez appris avec vos hypothèses. Vous pouvez vous amuser, du coup, à le mettre sur papier. Hop, un petit message sur IRC, un petit message sur le forum. Qu’est-ce que vous en pensez ? Est-ce que je vous ai bien compris ? Est-ce qu’on va dans le bon sens ? Etc. Passer, comme ça, à différentes étapes, apprendre, itérer, être capable du coup d’améliorer ce que vous avez dessiné. Être capable de réparer si c’était directement sur du développement et même, si vous étiez juste dans cette phase de design, là vous pouvez passer sur une phase de développement où, du coup, vous perdez beaucoup moins de temps et votre développement a beaucoup plus de sens.

En soi, vous arrêtez de développer pour voir puisque vous savez déjà, vous avez collecté les data, vous êtes déjà dans la validation. Donc maintenant vous pouvez juste rester focus sur le développement. Et, tout simplement, on répète à chaque fois qu’on fait quelque chose, toujours redemander à sa base d’utilisateurs, voir ce qu’ils en pensent. On en arrive au cycle Lean, très simple, qui est « je construis, je mesure et j’apprends », etc. Dès que je balance quelque chose, dès que j’ai une hypothèse, il faut la confronter avec les gens, être capable d’avoir de l’information des gens qui utilisent quotidiennement votre produit.

20’32

Matthias : Seconde citation, on aime bien, de Henry Ford cette fois