On a testé la refonte du site Troopers en pair design (ou conception à deux)

Il y a quelques mois nous avons décidé de refondre le site Troopers (c’est pour bientôt…) afin qu’il représente mieux nos valeurs et une nouvelle direction dans notre stratégie de communication (#spoilerAlert).

Nous avons donc décidé d’enfermer 7 Troopers pendant 5 jours dans un appartement Nantais avec toit terrasse pour un Ouvre une nouvelle fenêtredesign sprint sur cette vaste thématique ! À l'issue des 5 jours je pensais repartir avec mes centaines de notes collantes et mes grilles de tests utilisateur·trices sous le bras pour designer tranquillement le nouveau site dans mon coin… Et là c’est le drame…

Et si on faisait du pair-designing ?

Faisant admirablement écho à nos innombrables discussions sur l’inclusion du design dans le process agile, Johan, développeur Front de renom, à prononcé LA phrase :

« et si on faisait du pair design ?! »…

En tant que bonne designeuse old school, prise de court, j’ai aussitôt répondu « ah yes carrément ! »… pendant que mon cerveau était déjà occupé à déterrer les vieilles angoisses du créatif : le client derrière l’épaule, le gros index huileux sur l’écran…

Bon en fait c’était trop cool et je dois dire que Johan n’a pas les doigts si huileux que ça… Bref, plus sérieusement !

L’origine de cette lumineuse idée c’est le “pair programming”, une méthode de travail issue des pratiques agiles et plus précisément de l' Ouvre une nouvelle fenêtreextreme programming dans laquelle deux développeurs·peuses travaillent ensemble sur un même poste de travail. La personne qui rédige le code et l’autre observe. On part du postulat qu’un cerveau c’est bien mais deux c’est encore mieux ! L’observateur·trice assiste donc le·la “codeur·deuse” en décelant les imperfections, en vérifiant que le rendu est iso avec les maquettes et en proposant des alternatives de code. Les rôles peuvent bien sûr s’échanger.

Concrètement nous nous sommes installé·e·s l’un à côté de l’autre (masqué·e·s hein), moi avec mon ordi connecté à un grand écran et Johan avec son portable sur les genoux (oui il est comme ça Johan). Nous avions sur le bureau tout un tas de prototypes papier des pages que nous avions co-crées les jours précédents et que nous devions donc maquetter. La navigation, la disposition grossière des contenus, les textes et principaux boutons étant présents sur ces prototypes papiers, cela nous a permis de nous concentrer et d’échanger sur la charte graphique, les principes d’éco-conception, et sur la collaboration design/dev.

En effet, pendant que je maquettais, si cela était nécessaire j’expliquais à haute voix sur quel principe ergonomique ou graphique je faisais tel ou tel choix etc. parfois Johan acquiesçait et parfois il en profitait pour regarder si une solution technique non gourmande en ressources pouvait correspondre. Si tel était le cas on passait à la suite, sinon on réfléchissait à une autre solution en essayant de creuser les raisons du besoin initial « est-ce que l’utilisateur·trice à vraiment besoin de ça ? » ou « quelle va être la valeur ajoutée réelle de cette fonctionnalité ? » Si nous arrivions à trouver une bonne raison de conserver l’élément alors il était nécessaire de trouver une solution qui remplisse tous nos critères (graphiques, éco-conception, utilité…).

Une fonctionnalité non implémentée au profit d’un site plus léger, éco-conçu

J’avais designé un formulaire de contact en panneau d’un tiers de la largeur de l’écran. Il s’ouvrait sur la droite, accessible depuis toutes les pages. C’était vraiment très joli. Et là Johan attire mon attention: « il vaudrait mieux une page dédiée pour le formulaire de contact ça évitera le poids d’un script js qui se charge sur chaque page». De fait, c’était un comportement stylé graphiquement mais qui n’avait pas vraiment de valeur ajoutée pour l’utilisateur·trice et qui était plus lourd. Donc exit le formulaire “slider”, bonjour la page contact !

Comment réhabiliter les polices système par une astuce graphique ?

Je militais depuis le début du design sprint pour que nous utilisions une typo système sur le futur site. Une typo qui s'affichera sur tous les navigateurs sans problème, sans aucune dépendance (au hasard Google font) et qui ne pèserait rien… Personne n’était vraiment convaincu que cela pourrait rendre un bon résultat graphiquement, et, en tant qu’agence web, c’est compliqué de se lancer dans l’eco-conception trash métal (à l’instar de l’excellent Ouvre une nouvelle fenêtreLOW←TECH MAGAZINE 💜). Les typos système c’est (en gros) Arial, Trebuchet, Verdana, Times, Courrier… je crois même qu’il y a la-typo-dont-on-ne-prononce-pas-le-nom.

Lorsque j’ai montré à Johan de l’arial Bold en corps 96 avec un interlettrage resserré à -5% (🙏🏻 pardon les typographes mais bon), j’ai vu l’admiration dans ses yeux… et ça vous voyez, j’aurai jamais cru le voir dans les yeux de Johan, il a fait un petit rictus d’approbation avec sa bouche et il a légèrement incliné le menton vers le bas, je ne l’oublierais jamais… Bref. Je pense que vous avez compris.

En conclusion, quels sont les grands avantages de la conception en paire ?

Un·e designer avec un.e dev au-dessus de l’épaule, ça fait beaucoup moins le·la maligne, hein… Ici, tout s’est donc proprement goupillé dès le départ :

• Grille de construction des pages ✅
• Composants et leurs différents comportements renseignés dans le guide de style figma couplé avec storybook ✅
• Alignement des équipes design et dev sur l’esprit du site ✅
• un peu plus d’humanité dans ce monde de brutes ✅

Je pense que vous avez bien compris que la pratique du pair designing ou conception par paire, incluant les deux expertises à plus d’un avantage lorsqu’on veut optimiser la collaboration entre design/dev et penser agile dès la phase de conception. La méthode permet à la fois au designer de mieux comprendre pourquoi intégrer les problématiques et contraintes de développement à sa logique de conception et au développeur d’adhérer aux choix graphiques et ergonomiques qu’il codera avec plaisir dans le respect du pixel perfect ! De plus cela permet d’éviter des incompréhensions sur la maquette, de penser “éco-conception” dès le départ, alors c’est tout bénef !