Comment faciliter le dialogue entre designer et dev ?

Aujourd’hui je suis très heureux de recevoir l’agence Fantassin pour ce nouvel article invité ! Merci à eux de poursuivre l’initiative d’écriture communautaire avec ce superbe article. Je te dit à lundi prochain pour le retour normal à mon article hebdomadaire et je te souhaite une bonne lecture !

---

Fantassin est une agence WordPress créative basée à Lyon, qui aime le dialogue et la coopération efficace, en interne comme avec ses clients ! Elle est également à l’écoute sur Twitter, Facebook, LinkedIn et Instagram !

---

Si tu es développeur web, tu vas souvent devoir discuter avec un designer. Tu vas devoir traduire (et donc interpréter) son travail pour l’intégrer via ton code.

C’est dans l’ordre des choses, c’est inévitable, et il va falloir de la compréhension mutuelle si tu veux travailler efficacement et avoir un résultat qui fait honneur à la démarche de conception et de production graphique.

Sauf que les deux métiers ont parfois un peu de mal à communiquer. Ils n’ont pas le même référentiel, pas les mêmes outils, et souvent pas tout à fait la même vision sur ce qui fait un bon site web.

Bref, on a vu pas mal de développeurs avoir envie d’insulter des designers, et inversement. C’est un truc suffisamment courant pour croire que c’est normal, alors qu’il suffit de peu de choses pour que ça se passe bien.

Comme chez nous, ça se passe dans la paix et la fluidité (et un peu de comportement passif-agressif dans les cas difficiles), on a eu envie de partager notre expérience de ce qui peut venir faciliter le dialogue entre designers et développeurs.

Le point du vue du designer

La première clé pour dialoguer de manière constructive, c’est de clarifier avant tout la vision de l’objectif à atteindre, et de le faire ensemble. C’est la base pour éviter que chacun bosse de son côté, avec ses petits problèmes et ses contraintes, et produise un truc décevant du point de vue de l’autre.

Alors que se mettre d’accord sur le résultat final à obtenir, c’est ouvrir le dialogue pour s’intéresser au métier de l’autre, et à la meilleure manière de construire le projet ensemble. Ça permet à chacun d’exposer ses préoccupations et ses contraintes, et les petits trucs qui font la différence pour lui faciliter le boulot.

À partir de là, on définit les formats de livrable, le process, la terminologie, et avec un peu de chance les deux parties apprennent des trucs et se créent les moyens d’être plus efficaces ensemble.

Dans notre cas, ça a débouché sur la création d’un environnement de développement complet, pour automatiser et industrialiser les aspects récurrents des projets et laisser l’équipe technique se focaliser sur le développement custom. Du côté du designer, cet outil lui dicte certains formats et aspects techniques de ses Design Systems (ou Guides de Style), et lui permet de les rationaliser pour qu’ils soient “prêts à intégrer” dans cet écosystème.

“Si on est arrivé à cette solution qui nous rend service, c’est parce qu’on est partis de l’expression des besoins de chacun. Personne n’a essayé d’imposer ses habitudes, ses manies, ni même son langage. On est parti des besoins respectifs pour créer un langage et un outil communs”

“Si on est arrivé à cette solution qui nous rend service, c’est parce qu’on est partis de l’expression des besoins de chacun. Personne n’a essayé d’imposer ses habitudes, ses manies, ni même son langage. On est parti des besoins respectifs pour créer un langage et un outil communs”

Joffrey, directeur artistique et gérant de l’agence créative WordPress Fantassin

L’avantage, en plus, c’est que c’est un bon entraînement pour dialoguer avec ses clients, les pousser à définir un besoin clair qui te permet d’être efficace et de répondre à leurs attentes. Et la base, pour ça aussi, c’est de s’intéresser en profondeur à leur métier, à leurs préoccupations, à ce qu’ils veulent que tu insuffles dans ce que tu leur livres à la fin du projet.

Et bien sûr, c’est aussi une manière d’installer un état d’esprit général au sein d’une équipe, basé sur l’ouverture, quel que soit le métier (et tu as même des choses à apprendre chez tes collègues de la compta). Parce que c’est toujours sympa de comprendre ce que fait le voisin, et surtout, si tu es dev, c’est encore mieux quand le voisin comprend ce que tu fais.

Le point de vue du développeur

Parce que quand tu es développeur, c’est ton lot quotidien, les gens qui ne comprennent pas ce que tu fais. Et souvent, tu interviens après le travail du designer. Donc si il n’a pas compris certaines bases de ton travail, il va te fournir des éléments qui vont te faire perdre une masse de temps. Et ce sera trop tard pour que le dialogue se passe bien (parce que s’il doit refaire son boulot, alors que ça a été validé par le client, c’est lui qui va perdre du temps).

Donc, du point de vue du développeur aussi, tout se passe en amont : tu dois définir au préalable quels formats tu utilises, quelles déclinaisons il te faut, quels paramètres doivent être précisés, tout, tout, tout. Tu dois donner au designer les moyens d’anticiper tes besoins, et ce qui va te permettre de bien faire ton job. Après, s’il ne le fait pas, c’est que c’est une question de responsabilité personnelle, et que tu vas devoir l’esquiver au maximum.

Mais pour lui donner envie de te rendre la vie plus facile, c’est bien de faire un peu de pédagogie, et de lui expliquer pourquoi c’est important de te sortir des maquettes détaillées et des .svg propres (déjà lui expliquer ce qu’est un svg propre).

Mieux, de t’expliquer sa démarche de création : si tu sais comment le designer a conçu sa grande œuvre, tu vas en tenir compte dans ta manière de l’intégrer, et ça va te permettre d’optimiser le code qui est rendu pour matérialiser sa vision le plus fidèlement possible.

Tout le monde en sort gagnant, victoire partagée, sérénité, congratulations, packs de bière, etc…

Là, c’est le moment où tu vas me dire, “mais on parle pas le même langage, même en prenant le temps de se parler, on se comprend pas”, parce que c’est une réalité vécue par beaucoup de développeurs.

Il y a deux options : soit tu as affaire à quelqu’un qui ne veut pas comprendre et on ne va pas pouvoir y faire grand chose. Soit tu n’as pas réussi à formuler tes attentes de manière compréhensible.

Si tu n’es pas sorti de ton jargon, et que tu es arrivé face au designer en lui parlant uniquement de CSS et de JavaScript, c’est pas forcément étonnant qu’il soit passé à côté du message.

Là tu as deux options : tu prends le temps de formuler le sens de ton travail dans des termes accessibles à n’importe qui (comme dirait l’autre, quand on maîtrise un sujet, on est capable de l’expliquer à un enfant de 5 ans ^^), ou tu t’appuies sur un outil commun pour échanger en s’appuyant sur du concret.

“Pour nous, l’introduction de Gutenberg dans l’écosystème WordPress nous a énormément simplifié la vie. La logique modulaire permet de discuter de manière constructive, avec une direction clairement visible pour les deux parties : les différents blocs de contenu sont des unités logiques. Un designer va facilement pouvoir assimiler les différentes options de bloc pour concevoir tous les affichages possibles, et le développeur saura facilement le traduire côté front-end. Et même quand on travaille avec du sur-mesure, des grilles custom ultra-complexes et des animations, le fait de les faire évoluer sur un système de blocs permet à tout le monde de bien matérialiser les choses”

Florian, directeur technique de l’agence Fantassin

Bien sûr, ce n’est qu’un exemple, Mehdi t’a déjà parlé de l’importance des Soft Skills et c’est encore une fois la capacité à écouter les besoins de l’autre qui va être décisive pour travailler efficacement.

Et là, tu te retrouves normalement au point de poser la sempiternelle question, celle qu’on a tous entendu et qui doit permettre de résoudre tous les problèmes de dialogue. 

Should designers code ?

Et oui. C’est évident que ça ne peut pas être une mauvaise chose. Et de la même manière, les développeurs devraient aussi s’initier au Design. Ça ne fera pas de miracle sur la capacité de chacun à discuter, mais ce genre d’émulation collective est toujours bénéfique.

En défrichant de nouvelles zones d’expression, on tire le web vers le haut, et tous les professionnels du secteur en profitent.

Après, il faudra aussi compter sur la mise en jeu des egos, et la capacité à respecter les territoires de chacun. Parce qu’à chaque fois qu’on a entendu cette question, à chaque fois qu’on a entendu quelqu’un demander si les designers devaient coder, on a aussi eu droit à des débats claqués au sol qui n’ont pas de sens ailleurs que dans l’expression de l’ego d’une profession.

Tu vois le genre : si les designers se mettent à coder, est-ce qu’ils ont besoin des développeurs ? Si les développeurs entament une réelle démarche de conception et de design, est-ce qu’ils ont vraiment besoin des designers ? Les deux métiers sont-ils condamnés à la concurrence ? À chercher à tirer la couverture à soi ? Les technologies à venir vont-elles provoquer la disparition de l’un d’eux ? Skynet va-t-il prendre le contrôle de nos lignes de commande ?

Ce sont des vraies questions, que de vraies personnes posent. Et pourtant, elles passent complètement à côté du sujet. Plutôt que de parler d’un métier, plutôt que de rester centré sur le prestige et l’avenir d’une profession, on pourrait pas plutôt parler de comment faire avancer le web, et construire les meilleurs sites possibles ?

Un site conçu par un designer qui code sera obligatoirement moins solide et pérenne qu’un site réalisé par un designer ET un développeur qui savent se mettre au service du résultat. Un site conçu par un développeur à la fibre créative sera toujours moins riche visuellement, moins harmonieux dans ses proportions, qu’un site conçu par un développeur ET un designer qui s’entendent sur leur objectif.

Alors je te laisse imaginer quand un développeur créatif et un designer qui code se mettent à travailler ensemble en parlant le même langage : c’est là qu’on peut espérer le meilleur résultat.

Bien sûr, si tu as d’autres clés pour déverrouiller un dialogue constructif et améliorer le quotidien de nos professions, on a hâte de lire tes commentaires.