Le design dans le libre : pistes de réflexion

Suite à une discussion sur Twitter (et à plein d’autres avant) je vais essayer d’exposer les obstacles qui font que design et open source font rarement bon ménage, essayer de comprendre pourquoi le grand public préfère utiliser des logiciels espions de sales capitalistes plutôt que leurs alternatives libres, et envisager des pistes de réflexion.

Le constat

Toutes ces discussions partent souvent d’un constat malheureux : certaines interfaces de logiciels libres semblent être designées avec du caca sur une paroi rocheuse inégale avec le soleil dans les yeux, ce qui a tendance à rendre le grand public hésitant.

On a beau aimer le concept, l’outil a beau être novateur, rien à faire, on ne peut pas l’utiliser sans devoir passer outre l’aspect repoussant du soft. Les succès libres conjuguant design et open source se comptent sur les doigts d’une main de choloepus didactylus (en gros, Firefox et Wordpress, sort of).

Comment en est-on arrivé là ? Quelles sont les pistes pour y remédier ? Est-ce juste un problème de design graphique ?

Voyons ça.

Les problèmes bloquants

Le manque de moyens et de compétences

Un développeur d’application libre commence souvent son application seul, et en général il n’est ni designer ni directeur artistique, donc il fait avec les moyens du bord. Même si à mon sens c’est une erreur, et qu’un designer (au sens large) devrait être intégré dès le début, c’est souvent difficile, donc on fait sans.

C’est beau donc c’est sale

C’est un élément qui bloque à mon avis toute progression du design dans le libre : le sentiment que ce qui est beau et utilisable est quelque part un peu malhonnête, et que rendre son outil agréable à utiliser serait un peu trahir en cédant aux sirènes du marketing.

Vieux réflexe hérité de la guerre du 1er janvier 1970 entre la tribu des techos et celle des marketos, une solution logicielle pure et efficace devrait se passer de tout design “superflu” qui dénote un manque d’intelligence.

Tous les indicateurs montrent que les utilisateurs ne sont massivement PAS de cet avis, mais le combat continue (car ce sont les utilisateurs qui n’ont rien compris et ne font pas d’efforts, ou sont si futiles qu’ils ne méritent pas de poser leurs sales doigts graisseux sur un logiciel supérieurement développé).

Les fonctionnalités parlent d’elles mêmes

Un peu dans la même veine que l’argument précédent, les fonctionnalités devraient suffire à assurer le succès du produit. Quelle injustice que les utilisateurs ne comprennent pas la supériorité de tel outil libre, qui est pourtant bien plus complet que tel concurrent fermé, tableau de features de 125 lignes à l’appui !

Avoir un minimum de fonctionnalités est parfois une fonctionnalité.

L’erreur ici est de ne pas voir que le positionnement, la stratégie ou le design sont des fonctionnalités plus importantes pour l’utilisateur que d’autres (comme le respect de la vie privée par exemple, malheureusement). Avoir un minimum de fonctionnalités est parfois une fonctionnalité.

La couche de peinture

Quand les créateurs de logiciels open source arrivent à se libérer des 2 points précédents (c’est de plus en plus souvent le cas, surtout avec l’arrivée de l’UX et de ses atours scientifiques) et qu’ils réalisent qu’il faudrait que leur logiciel soit “beau”, c’est souvent après tout le reste, à la fin, en se disant que ce serait pas mal si on passait un petit coup de peinture fraîche par dessus tout ça pour “rendre le tout joli”.

Ajouter un fond gris à votre visionneuse d’image n’en fera pas un Lightroom.

J’ai récemment proposé mes services pour aider des projets libres à communiquer, et j’ai eu plusieurs réponses du style “je pense que tout va bien, il faudrait juste designer une skin pour le site web” ou encore “si tu veux aider pour la com’ regarde dans le trello, y’a des pictos à faire”.

maxresdefault.jpg Contrairement à ce qu’il se passe dans Need For Speed Underground 2, superposer des couches de peinture n’augmentera pas votre succès.

De même, essayer de singer une app à succès n’est pas forcément un gage de réussite, surtout si c’est mal fait. Ajouter un fond gris à votre visionneuse d’image n’en fera pas un Lightroom. Agir comme ça ne mène à rien, ce dont manquent le plus ces projets, c’est une stratégie, un positionnement, de la conceptualisation et du design au sens large.

Pull request as design

On en arrive à la réflexion usuelle “c’est un projet libre, n’importe qui peut aider, propose tes services”.

C’est très juste, mais assez simpliste, le problème ne venant pas de manque de bonne volonté de la part des designers ni même du fait que ça ne soit pas rémunéré (aider un logiciel libre est une cause noble pour bien des designers, car le produit profite à tous).

Le problème vient du fait que collaborer en tant que concepteur, directeur artistique ou designer sur un projet libre, c’est L’ENFER.

Oui, l’enfer, et je pèse mes mots. Pourquoi ? Car le monde du logiciel libre est le royaume de la pull request et des commentaires éloquents, et ce mode de fonctionnement ne se prête pas à la conception et à la stratégie. Il y a bien du design itératif et du A/B testing qui peut se concevoir de cette façon en fin de chaîne, mais à part ça, c’est une solution inappropriée.

L’outil conditionne aussi le design. En plus de n’être pas familier avec ces outils de devs (non, ils ne doivent pas plus les apprendre que le dev ne doit apprendre Illustrator…) ces outils formattent la pensée et la façon d’aborder une problématique (c’est pareil pour Invision d’ailleurs, qui est pourtant un outil de designers).

La contribution apportée doit être jugée par des pairs.

Même si une fois maîtrisée, la “pull request” en elle même n’est pas un problème, c’est plutôt le fait qu’elle ne va pas être évaluée par des pairs qui en est un. En effet, dû à la supériorité numérique des développeurs sur un projet donné, toutes les propositions créatives seront jugées par des développeurs qui sont très bons en développement mais ne touchent pas un cachou en stratégie de communication (personne n’est parfait).

Du coup c’est un bal d’avis personnels et de ressentis non-étayés et condescendants tendant vers ce qui peut ressembler à un consensus, mais qui n’en est même pas un étant donné que ce consensus n’a même plus d’ancrage dans le réel. Ce phénomène est empiré par la philosophie du libre qui est que tout le monde contribue (dévoyée en “tout le monde donne son avis”) et au fait que la prestation est en général gratuite, donc sans limite.

Ce genre de retours complètement HS est le cauchemar de tout designer

Le directeur artistique (terme qui n’a rien de pompeux) peut même être vu comme une diva s’il refuse d’appliquer certaines modifications.

Or il faut comprendre que chacun connait son métier, et malgré la facilité de commenter du design (tout le monde peut se faire un avis / les goûts et les couleurs / on sait ce que l’on aime ou pas / c’est pas beau) cela demande certaines compétences.

Tout comme je n’irai pas tripatouiller un repo de code pour l’améliorer car je ne suis pas dev, j’aimerais que des développeurs ne viennent pas tripatouiller le design. Je souhaiterais juste recevoir des pull request de mes pairs ou du moins de la part de gens ayant assez de bagage et de connaissances pour commenter.

Comme nous en parlions lors d’une informelle Paris web au sujet du redesign du logo mozilla (une catastrophe à mon sens, dans la démarche et dans le résultat) le designer peut (et doit) expliquer et faire de la pédagogie, mais à la fin il faut le laisser travailler.

Sérieusement, qu’est-ce qu’on est censés faire avec ce genre de retours ?

Ça ne veut pas dire que le designer ne veut pas jouer le jeu du libre, mais qu’il veut le jouer dans les mêmes conditions que les devs.

Les pistes vers une solution

La stratégie, la conception et le design font le produit autant que le reste

En premier lieu, si l’outil libre est destiné au public, il faut qu’un designer/communicant soit intégré dès le début au projet afin de définir un positionnement et une stratégie (globalement : à qui on parle, quel est notre objectif, Asterix, pourquoi nous nous battons ?).

Ça devrait être naturel (ça fait belle lurette qu’aux USA les startups candidates à des levées de fonds intègrent des designers dès le départ) mais ça ne l’est pas. Pourtant on ne concevrait pas un projet sans développeur, l’inverse est tout aussi vrai.

Le design fait partie du Minimum Viable Product. Sans parler de la stratégie globale par dessus.

Par exemple, le fait qu’un projet libre avec l’importance et l’ambition de Cozy Cloud n’emploie qu’un designer sur 27 salariés me fascine. On ne concurrence pas DropBox, Google et consorts sans un positionnement, une communication et un design béton.

Ça n’est pas que du graphisme ou de l’UX

Bien souvent, avant même de se poser la question de la tronche du service ou du logiciel, il faudrait se poser la question de la stratégie et du positionnement, qui sont des portions importantes du succès du projet. Or j’ai constaté que ces questions ne sont jamais abordées. Si les développeurs acceptent de plus en plus les notions d’ergonomies et d’UX (qui viennent peu à peu remplacer la notion de “beau”, c’est déjà ça de gagné) il manque toute la partie principale en amont.

L’UX a également un coté séduisant pour les développeurs car il y a des facteurs mesurables, mais attention, ça ne fait pas tout (et aussi ce qui marche chez le voisin ne marchera pas forcément partout).

À Chacun son métier

Si un designer participe à un projet libre, il faut le voir comme étant d’égale compétence avec un dev, mais dans un autre domaine. J’ai 11 ans d’expérience dans la communication, j’ai réglé des problématiques conceptuelles sur des sites et des projets stratégiques gargantuesques impliquant des dizaines de personnes juste pour la partie créative, donc chill, je peux gérer ton projet (d’ailleurs hein, n’hésite pas si tu cherches un directeur artistique) :).

Lâchez prise et laissez-moi faire mon boulot.

Ça ne veut pas dire que je me la pète ou que je n’accepte pas la critique, mais au même titre que je laisse les développeurs faire leur boulot, je veux pouvoir faire le mien.

Ayez confiance, lâchez prise, faites vos retours dont je tiendrai compte, mais globalement, laissez-moi bosser comme je vous laisse bosser.

Cadrer les retours

Rien n’est pire que le design en comité.
Ah si, le design en comité avec une communauté du libre.

La facilité de faire des retours sur chaque élément individuellement multipliée par le nombre de personnes donnant leur avis multiplié par le manque de qualification des participants donne invariablement un résultat déplorable.

Je comprends que l’esprit du libre veut que chacun apporte sa pierre à l’édifice, mais il n’est pas possible d’adopter ce mode de retours stérile si on veut arriver à quelque chose de bien. Il est très difficile de faire des retours créatifs pertinents, et encore plus si des dizaines de personnes s’y mettent. La solution serait de limiter le nombre de décisionnaires et de toujours juger la pertinence des retours à l’aune des objectifs définis en amont.

Alors ?

On ne peut pas se passer de communication (au sens large) si on veut que son projet rencontre le succès. On constate que les projets open source les plus pertinents en positionnement, stratégie et design sont ceux qui ont des équipes design et dev travaillant séparément mais en concertation, avec un objectif bien défini.

En fin de compte, il n’y a pas de secret, c’est comme ça que fonctionnent tous les projets. Il faudrait donc admettre qu’il n’en va pas différemment pour le libre, et faire en sorte que tous les métiers soient intégrés dès le départ pour obtenir un résultat probant.

Addendum

  1. Ce sujet sera justement discuté dimanche après midi à partir de 14h au hackerspace “Le Reset”, et il est très possible que du coup j’aille y faire un tour, le monde est bien fait.
  2. Je viens de lire ce billet très intéressant sur le retour d’expérience de la collaboration avec des designers sur le système d’exploitation Tails, et l’importance du design avec une approche holistique pour répondre à leur problématique et protéger leurs utilisateurs. En gros ils ont réussi à mettre en place efficacement ce que j’essaye d’expliquer laborieusement ici, et c’est beau :)

Edit 10/02 - 16 h 25

J’ai modifié la tournure de phrase pour Cozy Cloud.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Haut de page