Laisse-moi faire ma diva
Ou pourquoi détruire un design en dev c’est plus grave que ça en a l’air.
Développeurs, intégrateurs, je vous dédie ce poème.
Designers, graphistes, vous n’êtes pas seuls.
1. Les nuisibles
Quand j’étais intégrateur HTML chez Publicis, il y avait une race de chefs de projet qu’on redoutait plus que tout : celle qui croyait mieux connaître notre métier que nous. Cette espèce démoniaque débarquait de temps à autre dans l’open-space avec des idées débiles ou infaisables (ou les deux), et sortait de son chapeau des libs JS miraculeuses censées les réaliser toutes seules (libs découvertes en général dix minutes plus tôt lors d’une veille technique assidue sur Presse-Citron). On avait beau hurler, on savait tout au fond de nous qu’il allait bien falloir faire avec. Et évidemment on ramait pour faire marchouiller ces bricolages contre-nature en priant pour que leurs commanditaires retournent colorier leurs powerpoints sans blesser d’autres innocents.
C’était il y a dix ans. Je m’en souviens comme si c’était hier et si vous avez croisé leur route vous vous en souvenez tout aussi bien : les nuisibles, ça marque. On apprend à les renifler de loin et on redoute le jour où ils vont réapparaître.
Eh bien dites-vous que pour un créatif, ces nuisibles, c’est à chaque projet. À chaque livraison, à chaque argumentaire, à chaque email, à chaque conversation à la machine à café. TOUT LE MONDE croit connaître son métier mieux que lui et se prive rarement de le lui dire.
2. L’expertise créative
C’est humain : tout le monde a des yeux. Tout le monde a des goûts.
Sauf que le créatif qui a bossé sur votre projet n’a jamais eu pour objectif de vous plaire : il fait du design, pas de l’art. Son travail est de comprendre une problématique et d’y répondre avec son expertise métier et les outils qui sont les siens : des mots, des typos, des couleurs, des pictos, des illustrations, des photos, des vidéos, des animations…
Le designer n’utilise pas ces outils au hasard. Un choix de couleur ou de typo est tout sauf innocent : s’il doit certes assurer une lisibilité optimale et une compréhension intuitive du sujet qu’il sert, il ancre également un design dans un contexte, un univers, un imaginaire, une culture. C’est un exercice difficile au carrefour de nombreuses disciplines (parfois très disparates), un métier qui exige une grande culture générale, un socle de connaissances pléthoriques, une solide expérience et une bonne intuition.
Tout ça pour dire que cette expertise a une véritable valeur. Elle n’est pas moins (ou plus) importante qu’une expertise technique ou stratégique : elle est différente et complémentaire, elle sert son sujet avec autre chose que des balises ou des algorithmes. Une fois qu’on a accepté qu’un bon design ce n’était pas uniquement s’assurer qu’une CSS passe le RGAA, on a déjà fait un bon bout de chemin.
Alors si vous avez des idées à soumettre à votre créatif : il peut les écouter, mais il n’est certainement pas tenu de les mettre en œuvre. Et il peut même décider de ne pas les écouter du tout. C’est à lui de décider, c’est lui qui sait.
3. Savoir faire un retour créa
Votre designer vous a autorisé à parler ? Fort bien ! Maintenant il va falloir apprendre à faire un retour créa, de façon à ce que votre intervention serve à quelque chose et que vous fournissiez des leviers utiles à votre camarade.
Les développeurs présents dans la salle ont tous déjà croisé cet effroyable ticket JIRA du client stressé en train de recetter son site : « ça marche pas ». Aucune demande claire, aucun contexte, aucun indice, rien à en tirer. La grosse déprime.
Chez les créatifs, l’équivalent de ce retour stérile existe : c’est le « j’aime pas ». Variantes : « ça ne me plaît pas », « on n’y est pas », ou tout simplement « c’est moche »… Le grand classique.
Presque aussi redouté dans la hiérarchie des retours inutilisables, on aime aussi le célèbre ordre frontal non-argumenté. Vous savez, ces « mettre le titre en rouge » (pourquoi ?), « trait trop gros » (pourquoi ??), « les textes en capitales sont interdits » (quoi ???)… On ne compte plus les terreurs nocturnes générées chez les designers par ces tristes maximes.
Le vrai problème avec ces retours, c’est que ce ne sont pas des retours : on ne sait pas quoi en faire, on n’a aucune prise dessus, il n’y a aucune valeur ajoutée pour la qualité globale du projet. Dans l’absolu oui, on pourrait essayer de satisfaire les lubies des uns et des autres, mais on ne mettra jamais tout le monde d’accord et on cassera tout le travail déjà effectué sans aucune contrepartie.
Plus grave : ces critiques improductives nient totalement le travail intellectuel du designer, ce qui est un peu dommage parce que c’est tout-de-même pour ça qu’on le paie. Parce que s’il fallait juste un bras qui exécute bêtement des ordres dans Photoshop, on aurait pu se permettre d’embaucher des profils moins aguerris (et moins chers)…
Alors oui, bien sûr qu’un design est toujours perfectible, et bien sûr que s’il y a un vrai problème il faut le traiter : dans ce cas on argumente, on qualifie et on cible afin d’agir efficacement. Mais si le problème ce sont les goûts personnels de la personne qui parle, alors il n’y a pas de problème…
4. Pourquoi on ne casse pas un design en dev
Voilà pour la théorie et le modus operandi. Cela étant dans la vraie vie on ne va pas se mentir, souvent « tout est validé » quand la créa arrive sur le bureau du développeur et il n’y a plus le temps de la retoucher. Ou alors il y a du temps… mais il ne FAUT pas la retoucher.
Pourquoi ? N’y vois pas de volonté castratrice ici cher développeur, mais tu arrives simplement après la bataille. Les écrans que te livre ton designer ne sortent pas de nulle part : ils sont le fruit de laborieux échanges et souvent de compromis durement négociés avec le client, le client du client, le planning strat, l’équipe projet, le juridique, les UX, les CR, les autres créatifs et j’en passe.
Ce que tu vois atterrir tout cuit dans ton drive est l’aboutissement d’arbitrages complexes et de la gestion en amont de mille contraintes incompressibles. La victoire finale d’une guerre sans prisonniers dont tu ne soupçonnes parfois même pas l’existence. Personne ne t’en blâmera, ta guerre à toi reste à venir et le designer n’y fourrera pas plus son nez que toi dans la sienne. Gardons juste en tête que remettre en question le design alors qu’il passe en phase de dev, c’est mettre à la benne une négociation, une stratégie et un travail collaboratif de plusieurs mois, voire de plusieurs années. Par des gens dont c’est le métier.
Personne n’a envie d’être le nuisible de la boîte. Respectons l’expertise d’autrui et acceptons que oui, on sera moins écouté sur les domaines dont on n’a pas la charge, parce qu’a priori on est moins bon dessus que ceux dont c’est le boulot. Ça veut dire qu’on ne détruit pas un PSD parce qu’on a la flemme de coder une feature ou que « de toute façon ça sert à rien ce truc ».
Un exemple ? Un texte de mentions légales de 12 px, c’est pas 11 px ni 13 px : c’est 12 px. Ça a l’air ridicule pas vrai ? Et pourtant cette taille de texte a peut-être fait l’objet de deux mois d’échanges tendus avec le service juridique (ne rigolez pas, ça m’est déjà arrivé)… pour éviter d’en reprendre pour deux mois, on met 12 px et on ne discute pas. Et si on est vraiment obtus et qu’on s’acharne à mettre le texte en 11 px parce qu’on a déjà une super classe CSS qui fait du texte à 11 px : on ne glisse pas ça sous le tapis l’air de rien en espérant que ça passe crème, on le dit au designer, comme une personne civilisée…
Aparté sur le contexte :
Certains objecteront à ce stade que tous les projets ne mobilisent pas un service juridique ou un planneur strat. Et ils auront raison : pour ma part, j’ai l’habitude de travailler pour de gros clients via de grosses agences sur de gros sites « vitrine » qui ont souvent besoin de ce type de prestations, mais ce n’est évidemment pas une constante. Néanmoins si les enjeux stratégiques peuvent être moindres pour le site de la boulangerie du coin ou celui du club de foot du fiston, le fond de la réflexion reste le même : on respecte l’expertise des autres professionnels de la chaîne de prod AVANT TOUT parce qu’ils sont meilleurs que nous dans leur métier. Si en plus ça facilite les validations client et la politique interne c’est du bonus (mais du bonus seulement).
Aparté sur les méthodes de travail :
Quand on bosse sur de l’applicatif ou des produits en constante évolution, on n’a pas toujours des phases de production aussi strictement séparées que sur des projets purement axés communication. Pour autant, les méthodes de travail qui concentrent leurs efforts sur les itérations rapides, le fractionnement des tâches, les échanges constants entre métiers et autres (bonnes) idées n’échappent pas non plus à la règle du respect des compétences de chacun. Les allers-retours seront sans doute plus nombreux et moins hiérarchiques, mais c’est bien l’expertise du créatif qui devra prévaloir sur les questions de design tout au long du processus.
En d’autres termes ce n’est pas parce que vos méthodes de travail sont plus souples et plus horizontales que le dernier mot sur le design ne reviendra pas in fine… au designer.
5. La solution pour optimiser son workflow
La solution, et là je suis bien désolé de décevoir les adeptes de la démocratie participative, ce n’est PAS d’impliquer les développeurs le plus tôt possible dans la conception du site.
La solution, la vraie, celle qui marche, est beaucoup plus simple : c’est que les développeurs fassent leur job et codent la créa telle qu’elle a été validée, en étant sûrs de l’avoir bien comprise avant. Ils sont bien sûr invités à poser toutes les questions nécessaires et à râler si les livrables sont crados : les créatifs sont censés leur faciliter la vie, pas la leur compliquer, et ils sont faillibles comme tout le monde. Mais chacun à sa place.
Le designer a passé des semaines à argumenter et défendre chaque partie de son travail auprès de ses multiples interlocuteurs. Ces explications s’adressent d’abord aux personnes qui vont VALIDER le design, pour qu’elles en comprennent les enjeux et les choix. Elles ne s’adressent jamais (ou rarement) à ceux qui vont le coder, parce que le PSD (ou tout autre fichier servant de livrable graphique) sert justement à ça et qu’il se suffit à lui-même dans 99 % des cas.
Aparté sur les outils :
Pour que le livrable graphique remplisse pleinement son rôle, il faut qu’il soit ouvert dans son état original par tout le monde (non, ouvrir un PSD avec Gimp ce n’est pas pareil que l’ouvrir avec Photoshop). Assurez-vous de la cohérence des outils utilisés sur la chaîne de prod afin de ne perdre aucune information en route, et si besoin anticipez en demandant si tout le monde est bien d’accord sur les livrables et les logiciels avant de commencer à travailler. Ça semble une évidence mais il m’arrive encore de découvrir que certains développeurs n’ouvrent jamais mes PSD et se basent sur les exports JPG que j’avais fournis au chef de projet pour faire leur intégration…
Et si vous ne voulez pas acheter du Adobe ou vous payer un Mac pour ouvrir des fichiers Sketch, il existe quelques outils efficaces pour faire « parler » des fichiers sources propriétaires sans les logiciels qui ont servi à les créer (citons par exemple le très bon Zeplin).
À titre personnel je vends aussi de l’intégration HTML/CSS que je code depuis des créas faites par d’autres designers, et je suis rarement (jamais en fait) briefé sur la créa elle-même, uniquement sur les comportements (interactifs ou non) attendus. Parce que la créa dans ces cas-là je n’ai tout simplement pas mon mot à dire dessus… c’est plutôt dans l’autre sens que ça fonctionne : si je vois une incohérence, une chose infaisable ou un truc louche c’est moi qui me manifeste auprès du designer.
Impliquer les développeurs en amont c’est s’encombrer prématurément avec des contraintes d’implémentation qui vont polluer tout le reste de la réflexion stratégique. C’est subir des décisions design dictées par la technique, voire des économies d’échelle contre-productives sauce « ah bah on n’a qu’à utiliser ce truc qu’on a sur telle autre page qui ressemble un peu »… Non. Ce n’est pas comme ça qu’on fait du design.
Ça ne veut pas dire pour autant qu’un avis technique ne sera jamais nécessaire : soyez sûrs que des développeurs restent disponibles (et sur demande seulement…) pour des questions concernant leur périmètre dans le cadre de la conception du design. Mobilisez dès le début un chef de projet technique ou un lead dev qui sait ce qui est faisable et ce qui ne l’est pas, et qui sait combien ça coûte.
Mais gardez les développeurs pour plus tard. Pour la phase de développement.
Et quand ils développeront, laissez-les à votre tour faire leur travail comme ils le souhaitent… ils savent mieux que vous, non ?
25 commentaires sur cet article
Larrach, le mercredi 20 décembre 2017 à 06:46
Merci pour cet article dont la lecture m’a bien plu et sur un sujet que je trouve passionnant. Mais je suis assez mitigée sur l’idée de laisser faire sa diva au designer. Je m’explique
Oui il faut faire confiance à l’expertise du designer, c’est lui/elle qui sait. Et on ne le fait sans doute jamais assez. Jusque là je suis carrément d’accord.
En revanche ne pas impliquer les profils techniques en amont du projet (ou que sur demande), c’est selon moi une erreur car c’est résumé un projet à son objectif purement communicationel. Or un site web a aussi un enjeu fonctionnel qui n’est pas moins important et qui induit lui aussi des contraintes sur la conception et qui doivent être prises en compte le plus tôt possible.
Par exemple on ne peut pas réduire la contrainte technique d’une maquette à la faisabilité technique, pour moi, c’est plus que ça : il y a la faisabilité oui bien-sûr, c’est la contrainte numéro 1.
Mais il y a aussi le temps de développement, les performances, l’accessibilité, la gestion des contenus, leur administration et toute l’UX qui en découle en BackOffice.
L’interface n’étant pas le seul enjeu d’un projet web, sa conception ne peut pas exclusivement reposer sur les personnes qui ne s’occupent que du front.
Dans ma façon de voir les chose, le ou la dev (ou autre profil technique) devrait justement être un de ces interlocuteurs relous dont parle l’article avec qui le/la graphiste a à discuter et négocier lors de la phase de créa.
Nicolas Bocquet, le mercredi 20 décembre 2017 à 09:30
Oui alors il faut bien prendre en compte le contexte professionnel (voir les appartés), car l’approche sera obligatoirement très différente selon que nous soyons chez le client ou non, par exemple.
En tant qu’intégrateur, combien de fois je reçois des maquettes graphiques incomplètes, sans effets de survols, pages manquantes, erreurs d’ergo basiques, et compagnie… Quand on travaille chez le client, il est quasiment obligatoire de revoir ensemble les éléments graphiques fournis afin de compléter, ce qui nécessite d’être suffisamment compétent et à l’aise sur les outils graphiques. C’est d’ailleurs l’une des raisons pour lesquelles il est préférable de faire appel à un intégrateur plutôt qu’un développeur en ce qui concerne la partie HTML / CSS / JS (Sans compter l’accessibilité…).
Nat, le mercredi 20 décembre 2017 à 09:44
Bonjour,
J’avoue que je suis très surpris par cette articles, et je me demande presque ce qu’il fait ici.
Si je fait un résumé rapide, le lis : « Web = Créa ».
Si tel est le cas, alors il n’y a pas besoins de développeur, de gens « techniques»…
Ou sinon, et c’est sûrement le cas pour toi, tu es un profil multi-casquette, qui voit le projet sous tous ses aspect et dans ces conditions ce n’est pas de la « créa », mais de la gestion de projet.
Ne pas impliquer les dev plus tôt n’est pas forcément un problème, ne pas leur faire comprendre les problématique du projet est de l’incompétence (de la part du chef de projet) .
… et dans tous les cas, un peu de modestie ne serait pas inutile.
Emilie, le mercredi 20 décembre 2017 à 09:51
Toi, t’as commandé des trolls pour Noël c’est ça ? :)
Je t’avoue avoir un peu froncé les sourcils quand tu parlais de ne pas impliquer le dev en amont… mais tu t’es bien rattrapé en parlant du CP tech ou du lead dev à la fin, c’est bon nous sommes donc bien d’accord.
Tout est là : quand un développeur dira « non c’est pas possible/faisable », un lead te dira « attention, ton truc là, ça va me prendre 2 jours de +, je suis pas sûre qu’on puisse le vendre »
Alors, oui, c’est mon problème de le vendre ensuite, de faire comprendre au client que développer la créa qu’il a validée ça va coûter un peu plus cher. Et là en général, le client a 2 options : sentir qu’il s’est fait avoir, ou traiter la tech d’incompétents. (non mais 2 jours pour un formulaire en 6 étapes ça suffit et puis le client il le veut absolument pour demain – coucou a11y, coucou floating labels, coucou RWD, coucou… )
D’où l’importance de cette foutue communication ! Afin de pouvoir défendre un budget, une idée, ensemble.
Joyeux Noël
Benoît, le mercredi 20 décembre 2017 à 10:00
J’avoue rejoindre l’avis de Larrach. A moins que le designer soit « double-senior » et possède des compétences sur l’ensemble de la chaîne de production d’un site, notamment en accessibilité et en « bonnes pratiques » (je pense à Opquast par ex.), je trouve important qu’un intégrateur puisse donner son avis dès la phase de design. Mais j’entends par là durant la phase même de conception, pas pour démonter une maquette terminée… J’ai le sentiment que tu pars du principe que tous designers sont experts (ou, comme toi, ont des compétences fortes en intégration) ! C’était peut-être le cas dans les grosses structures où tu as bossé, mais je t’assure que ce n’est pas si fréquent que ça.
Cela dit, je me fais un plaisir de rien avoir à redire devant un design dont on sent l’expertise en amont… :-)
Nico, le mercredi 20 décembre 2017 à 10:51
Le titre est bien mal choisi : faire sa diva, c’est justement faire des caprices. Demander à se faire respecter son expertise, ce n’est pas un caprice, c’est NORMAL.
Par contre, il faut que cette expertise soit jusqu’au bout : typiquement, j’estime que le créa qui veut que le dev respecte sa maquette doit fournir moult indications (un guide de styles, etc.) afin de ne pas laisser d’ambiguïtés ou d’espace d’interprétation. Un fichier photoshop mal branlé/rangé n’est pas signe d’expertise.
Mon créa fait tellement d’efforts pour ça (maquettes, indications, guides, etc.) que je vais me plier en 4 pour le satisfaire. Et quand je dois – la mort dans l’âme – trouver une adaptation pour une contrainte donnée totalement imprévisible, je discute avec lui non pas de ce qu’on aime (on s’en branle de nos goûts respectifs), mais son intention, de nos contraintes et de l’objectif. Hop, discussion dépassionnée.
Et je peux tout à fait entendre un « écoute, j’ai lutté comme un taré pour arriver à ça, y a plus de négociation possible ». Ok. Si si. C’est vraiment ok, je comprends. :)
Pour ma part, je sais que les innombrables et interminables discussions en créa soient une plaie (rassurez-vous chers créas, on a les mêmes en responsive/fonctionnel/etc. et je ne parle même pas de l’accessibilité ou la qualité)… il m’arrive souvent de hurler contre un boss qui pense tout savoir et qui a besoin de nourrir son complexe du sauveur, alors qu’il n’a pas l’historique, et qu’il vient emmerder tout le monde pour un vrai caprice, créa/devs compris. J’en suis même des fois à dire « hors de question d’améliorer si c’est pour repartir dans des discussions interminables, d’abord on finit ».
Si si, on a les mêmes soucis.
Ce qui me permet de conclure => ces débats me semblent bien vains, et j’avoue que j’en ai marre qu’on oppose créas/dévs : ce n’est pas comme si on n’avait pas compris qu’il fallait être souple, car des contraintes improbables (contenus, etc.) arrivent toujours. A mon avis, plutôt qu’à se renvoyer la balle, il vaudrait mieux voir comment avoir des workflows plus résilients et souples… en respectant les expertises.
Luc, le mercredi 20 décembre 2017 à 11:01
C’est vrai que le titre est un vrai attrape-trolls ! :-p
Je suis d’accord sur tout le tableau, après on s’entend qu’on parle là de designers qui font un vrai travail de design.
Ce qui cause le plus de mal à ce métier, c’est qu’au-delà de sa méconnaissance de la part de certaines personnes, il y a aussi des pseudos designers qui ne font pas un vrai travail de design mais plutôt de l’art voire du coloriage. Ça existe aussi (et pas toujours forcément parce qu’ils le veulent) et ça aussi, ça n’aide pas à valoriser le métier.
Bref, il y a encore besoin de beaucoup d’éducation et cet article fait du bien à lire.
Sébastien DROUIN, le mercredi 20 décembre 2017 à 11:12
Ça fait du bien cet article !
J’hésite d’ailleurs à l’envoyer à la boîte de dev qui m’a pourri le webdesign conçu pour un client et qui m’ont presque fait perdre le client. Car celui-ci n’avait pas le même oeil, et il a donc un site qui n’est pas pleinement fonctionnel parce que le prestataire de dev par qui je suis passé (et qui faisait du bon taf le reste du temps) a décidé sur ce projet de n’en faire qu’à sa tête.
Quand tu as parlé d’une d’une guerre sans prisonnier ou de ces dev qui se basent sur les JPEG et qui n’ont pas Photoshop, j’ai tout de suite pensé à cette situation. C’est sans doute un de mes plus beau taf, les plus abouti, issu d’un travail monstrueux de plusieurs mois entre le client et moi. Et mis par terre parce que deux dev et leurs boss ont décidé que faire autrement était une bonne idée. Autant dire que quand je présente ce travail, ce sont toujours mes prods et non le site en ligne que je montre.
Merci pour cet article, je le garde sous la main pour faire de la pédagogie si je rencontre à nouveau le problème.
STPo, le mercredi 20 décembre 2017 à 11:17
Merci pour vos commentaires, j’espérais susciter quelques réactions avec le ton de l’article (volontairement taquin, vous l’aurez compris) donc je suis content de vous lire.
Bien sûr qu’un regard technique est indispensable à tout projet web (que ce soit chez des gros annonceurs ou sur des petits sites), c’est ce que j’essaie de dire en conclusion. Je le sais d’autant plus que j’en ai souffert moi-même quand je ne faisais que de l’inté : se retrouver devant des trucs infaisables ou explosant le budget à la toute fin, c’est trop tard, on est tous bien d’accord.
Cela dit (et là effectivement c’est peut-être un biais dû à mon propre environnement professionnel), il me semble que ça arrive de moins en moins (ou en tout cas bien moins souvent qu’il y a dix ans). D’une part parce que les designers sont de plus en plus formés à ce qui est faisable ou non, et d’autre part parce que de plus en plus de choses sont effectivement faisables techniquement (merci les progrès de CSS et de JS). Et également, dans l’autre sens, parce que des profils créatifs ET techniques émergent sur nos technos (cf. l’article du début de mois sur les creative developers).
Bref, les lignes bougent, et c’est tant mieux.
(Mais 12 px c’est 12 px…)
Etienne, le mercredi 20 décembre 2017 à 15:51
Si je suis tout à fait d’accord pour reconnaître à chacun sa compétence et le respect dû entre toutes les parties au regard de ces compétences, cette vision linéaire du processus de production tend à devenir obsolète, et tant mieux.
Le « design » est de plus en plus corrélé à l’expérience utilisateur (c’est évidemment une bonne chose). L’ergonomie passe en premier, le design le sert.
Dans ergonomie, il y a aussi ergonomie fonctionnelle, donc in fine une vision technique à avoir.
Toutes les parties prenantes doivent donc participer dès le départ si l’équipe veut produire un design qui a du sens.
Ce n’est pas pour cela que le développeur doit changer la typo du designer, bien au contraire. Mais pendant la phase de conception, chacun peut (doit) apporter sa vision, pour peu qu’elle soit étayée et constructive.
Julien, le mercredi 20 décembre 2017 à 16:10
@Nico :
>Par contre, il faut que cette expertise soit jusqu’au bout : typiquement, j’estime que le créa qui veut que le dev respecte sa maquette doit fournir moult indications (un guide de styles, etc.) afin de ne pas laisser d’ambiguïtés ou d’espace d’interprétation. Un fichier Photoshop mal branlé/rangé n’est pas signe d’expertise.
–
Le problème c’est que « jusqu’au bout » c’est quel bout ? Parce que justement les intégrateurs ont apparemment décrété depuis quelques temps qu’il était tout bonnement IM-POS-SIBLE de travailler sans un styleguide atomic fonctionnel en react, ce qui justifierait qu’une couleur de fond ne soit pas de la bonne couleur, et une typo pas à la bonne graisse. De mon temps les intégrateurs se débrouillaient pourtant très bien avec un PSD et une charte globale (on appellait ça comme ça) et allaient même jusqu’à déduire ou inventer quelques comportements et rollovers.
Comme expliqué dans l’article, le métier est vaste et ce qui semble être un prérequis obligatoire pour des devs ne peut être qu’une formalité optionnelle pour un graphiste qui doit déjà gérer bien des choses en amont pour ne pas en plus ajouter la création de composants complets et codés (même si tu ne parlais pas forcément de les coder dans ton commentaire, ça arrive de plus en plus).
J’ai l’impression (personnelle, échantillon non représentatif) que bien des intégrateurs ne prennent même plus la peine d’ouvrir la maquette dans Photoshop pour prendre les bonnes couleurs utilisées à même l’élément et non pas salement avec la pipette, ou recopier les valeurs de typos exactes au lieu d’essayer de les déduire à l’œil.
Heureusement, des solutions comme zeplin, avocode ou adobe extract ont l’air de simplifier la vie de tout le monde, mais quand c’est pas possible il faut juste se fier à la maquette.
Stephanie, le mercredi 20 décembre 2017 à 16:16
Je suis un peu attristée de voir le nombre de réponses qu’on peut résumer en « oui mais mon designer fait pas son boulot/ est mauvais je dois corriger ses erreurs ». Je me demande avec quels genre de designers vous bossez :(
Et puis bon j’ai déjà fourni la totale, style guide, maquettes rangées (mieux que mon appart je suis flippante) et CSS pour les interactions (je peux avoir un cookie ?) ça pas empêché le dev de me tuer ma maquette en « pennant des libertés » comme il dit. Du genre « j’ai retiré du whitespace et j’ai changé l’ordre titre image ». Au final la cliente était super embêtée parce qu’elle avait validé ma maquette et savait pas comment lui dire qu’elle était pas satisfaite (t’inquiète je m’en occupe ^^). Et oui, le whitespace sur un site d’architecte, il fait parti de la charte graphique, NON MAIS HO :D
Quant au « designer qui fait du coloriage » bah elle ou il n’a pas forcément toujours le choix. Perso c’est marrant (non) j’ai parfois le problème inverse : je suis UX/UI designer, on m’implique souvent qu’en bout de chaine, quand toutes les décisions de design et d’ergonomie (mot à prendre avec du second degré ici) ont été réglées à coup de « on a pris un template – material angular bootstrap zurb rayez la mention inutile‑, tu peux rendre tout ça joli plait mais touche pas à la structure c’est déjà en place ». Oups ? Je parle ici surtout d’interfaces et de dashboards complexes, on s’éloigne sans doute un peu des sites vitrine de Christophe. Du coup parfois on est aussi dans l’extreme inverse, au lieu d’avoir des maquettes validées et des devs qui n’ont pas pu donner leur avis sur la faisabilité, on a des non-décisions de design et d’ergo qui sont prises par du code pour se simplifier le dev sur des projets, l’interface graphique est vue comme « un truc qui permet de rentrer les données dans la base de donnée », au final, ça pique tout autant.
Bref à un moment j’aimerai vraiment qu’on arrive à trouver un équilibre entre les métiers. Comme souvent ça manque cruellement de communication, chacun prèche pour sa paroisse et personne n’avance :)
Gaël Poupard, le mercredi 20 décembre 2017 à 17:30
Merci pour cet article, je l’adore !
Et les commentaires sont bien juteux aussi, alors je participe :)
Pour faire simple, je suis d’accord avec l’intégralité de l’article. Cependant je pense qu’il y manque une information précieuse : le designer qui démarre son travail a généralement un brief, avec des demandes, des contraintes (techniques ?) et tout du moins un périmètre d’intervention bien défini. Ce dernier est supposé avoir été décidé par le client, mais également étudié (si c’est n’est carrément proposé) par l’équipe de choc qui constitue la chaîne de production du projet.
Il ne sort pas toutes ses décisions d’un chapeau, comme tu le dis si bien. Il sait les argumenter, les défendre, et parfois revenir dessus si un argument le fait changer d’avis. Le designer peut-être sauvage mais il est rarement complètement stupide.
D’un autre côté, dans les commentaires beaucoup soulignent l’incompétence de leur designer (merci Stéphanie de l’avoir relevé, c’est effectivement flagrant). J’aimerais aussi évoquer le (petit) détail que cet appeau à troll signé par Christophe met tous les développeurs dans le même panier, mais c’est pour servir l’objectif et le ton de l’article. Pour dénigrer les qualités professionnelles du designer avec lequel vous coopérez (hein, vous coopérez, quand même ?) vous le jugez sur un bout d’iceberg qui dépasse, un truc qui vous agace, et surtout, surtout, vous estimez être bon dans ce que vous faites et avez des exigences.
C’est super cool (pour de vrai), par contre les exigences ça se négocie et ça se partage avec les collègues : notamment le – désormais fameux – designer.
Je relance de deux avec un autre appeau à troll : tous les développeurs ne sont pas bons. Ah, et les intégrateurs non plus. Comme les designers, ce sont de vrais gens, avec des qualités et des défauts, des expériences et des ignorances.
Maintenant pour partager un peu ma vision du sujet (parce que pour l’instant je rebondissais seulement), j’adore cet article car j’ai présenté le sujet du point de vue de l’intégrateur à la KiwiParty 2016. Le cas existe, effectivement, d’un designer qui vous livre un fichier tellement crade que vous aurez du mal à l’exploiter, ou avec des incohérences qui vous défrisent.
Ben vous savez quoi ? Dites-lui (gentiment) parce que communiquer permet de comprendre, appréhender, gérer, et échanger pour (parfois) convaincre. Mais surtout : faites de votre mieux, avant. Un PSD mal organisé, qui pèse une tonne, avec un nommage inintelligible, ne discrédite en aucun cas le travail graphique fourni. Vous pouvez (et devez, hein, vous êtes payés pour ça) faire une intégration qui respecte le design fourni, même si vous n’aimez pas le designer ou que son PSD pèse 163 Mo.
Vous pouvez dialoguer, vous entendre sur les outils à utiliser (du versionning, des fichiers partiels, un guide de styles, etc.), les règles à respecter (coucou la Photoshop Etiquette, par exemple) et si vous trouvez que votre designer n’est pas bon, aidez-le à progresser. Généralement, vous progresserez autant que lui.
Et si d’aventure le dialogue n’est pas possible, ne saccagez pas son travail : organisez-vous pour nettoyer le PSD, vus mettre à l’aise techniquement – toujours en vous assurant de conserver son travail intact ! C’est possible.
PS : avant de devenir intégrateur, j’étais… graphiste. J’ai justement arrêté cet exercice parce que je n’en pouvais plus d’argumenter perpétuellement, de voir mes choix remis en question pour rien, d’être finalement forcé à faire de la merde parce que le chef préfère la Comic Sans MS. La digue a cédé le jour ou un client, fournisseur de crustacés surgelés, à insisté pour utiliser du vert comme couleur dominante « parce qu’aucun concurrent ne le fait ». Je n’ai jamais réussi à lui faire comprendre qu’ils avaient une excellente raison de ne pas faire ça.
Encore merci pour cet article, il fait chaud au cœur en cette période de fête <3
Bernard Michel, le mercredi 20 décembre 2017 à 20:24
Merci !
Vision intéressante et j’avais compris que dans un cadre agile et responsive, je mettais un ux, un ui et un dev front, que je secouais bien fort et qu’en j’en récupérai un board responsive à faire valider aux instances de validation. J’avais également compris que ça fonctionnait bien dans un cadre scrum.
Qu’est ce que j’ai loupé ? Le fait que tu bosses en remote ? C’est marrant mais je pensais fort à toi ces derniers temps et je me demandais comment ça se gérait et j’ai une partie de réponse ici.
Et pour répondre à Stéphanie, on bosse avec les profils qu’on a et oui ils ne sont pas toujours adaptés au travail demandé. Je réitère ma remarque du dessus, il me semblait que scrum résolvait une partie de la responsabilisation des équipes et la communication en leur sein. Je manque quelque chose ?
fvsch, le mercredi 20 décembre 2017 à 22:00
« Vision intéressante et j’avais compris que dans un cadre agile et responsive, je mettais un ux, un ui et un dev front, que je secouais bien fort et qu’en j’en récupérai un board responsive à faire valider aux instances de validation. Qu’est ce que j’ai loupé ?»
C’est assez rare d’avoir le financement pour ce genre de fonctionnement. Sur beaucoup de projets le temps de dev de l’interface coute au moins aussi cher voire plus cher que sa conception (UX + UI), à tort ou à raison, donc on évite d’engager du dev avant la validation du design.
Olivier, le jeudi 21 décembre 2017 à 04:05
Un billet d’humeur provoquant et péremptoire à souhait mais j’y retrouve parfois certaines de mes propres réflexions. Les commentaires aussi sont intéressants et significatifs d’un métier labile et impermanent où chaque webdesigner et graphiste web arrivent avec ses compétences expertes ou pas. Il est évident que le temps du travail en silo est terminé et les créas dont je suis ne font pas exception. On ne peut pas vraiment faire sa diva entre un client exigeant et des contraintes techniques fixés par les devs. Il faut une bonne dose d’adaptabilité pour survivre en tant que webdesigner et je comprends ceux qui peuvent se décourager où vouloir qu’on respecte plus leur travail. Mais attention à ceux qui se prennent pour des artistes, le web est avant tout un outil technique et nous sommes là pour résoudre des problèmes afin de répondre à des objectifs qui vont bien au delà des contingences esthétiques. Comprendre cela permet d’améliorer le workflow avec les autres acteurs du projet et permet de mieux apprécier toutes les facettes d’un projet à travers l’uX, le design, le SEO…
Gaël Poupard, le jeudi 21 décembre 2017 à 08:46
@Olivier
> Mais attention à ceux qui se prennent pour des artistes, le web est avant tout un outil technique et nous sommes là pour résoudre des problèmes afin de répondre à des objectifs qui vont bien au delà des contingences esthétiques.
C’est parfaitement formulé, je trouve ♥
STPo, le jeudi 21 décembre 2017 à 10:03
Oui alors pour le coup c’est à dessein que je n’ai pas parlé de designer « artiste », ce combat-là est clairement révolu —et gagné— pour moi. J’espère que depuis le temps tout le monde a compris qu’un designer ne faisait pas ce qu’il voulait, et que son boulot consistait à répondre à un brief précis et à servir un sujet qui n’est pas le sien… Ça ne se cantonne d’ailleurs pas au web, c’est valable pour toutes les disciplines des métiers créatifs.
Concernant ces histoires de silos : je suis passé rapidement dessus parce que ce n’était pas le sujet de mon billet, mais c’est ce que j’essaie d’aborder quand je parle des méthodes de travail. Respecter l’expertise du designer n’interdit pas les allers-retours et le travail en team, on est simplement sur des échanges plus courts et une imbrication plus forte. La première version de mon article parlait d’agile, de sprints, d’atomic design et autres méthodos mais je me perdais dans des détails qui diluaient le message initial.
Maintenant dans les faits oui, personnellement c’est vrai que je bosse rarement en agile. Et quand ça arrive (j’ai une mission en agile qui va débuter en février), c’est en tant qu’externe en remote et donc ça fausse sans doute un peu la donne… mais pas tant que ça non plus. Le propre du freelance est de s’adapter aux méthodes de ses clients et aux typologies de projet, donc je suis assez souple sur ce point. Encore une fois ce n’est pas contradictoire avec mon message ici : dans la team UX/UI/dev que tu secoues Bernard, le créa se battra pour faire respecter son travail même si c’est transparent dans le produit qui en sortira derrière.
Nico, le jeudi 21 décembre 2017 à 12:39
> Le problème c’est que « jusqu’au bout » c’est quel bout ?
@Julien : question de contexte comme toujours.
Perso, j’ai une préférence pour que le périmètre du créa soit plus grand (oui, un inté/dev qui dit ça et qui assume !) et qu’il designe carrément les éléments du site au lieu de pondre qq maquettes justement pour que sa vision et son expertise ne soit pas massacrée… ou en tout cas le moins possible.
Y a un moment, on est obligé d’avoir une vision aussi globale que possible sur un projet sinon ça risque de partir en sucette à un moment ou à un autre. Je pense que le DA que tu es ne pourra qu’acquiescer.
Après, c’est comme tout : je sais que des fois, ce n’est ni possible ni souhaitable, je m’en accommode. Et question de dimensionnage : pour 5 éléments sur un site qui ne va pas ou peu bouger, j’ai pas besoin d’une armada de guides de styles, une couleur et ça suffit ^^
Après, avec 7 ans de pratique dans l’agence web où je suis, je constate que fonctionner ainsi fait fortement monter en compétence le créa, qui du coup connait mieux les possibilités, fait moins de trucs impossibles/délirants, etc.
Perso, mon créa est une rolls-royce rutillante, c’est un réel plaisir de bosser avec : exports au poil, indications, guides, etc. et du coup, ça nous tire aussi vers le haut, ce qui est normal => il se casse le cul, donc on n’a aucune raison de ne pas autant se casser le cul que lui. Et du coup, il nous challenge :)
En gros, on a scindé le pur job d’inté (fait les exports et templates) => les devs templatisent, le créa exporte, et au final, c’est pas plus mal.
Certes, c’est du boulot… mais on limite les risques. Je constate que les retours sur nos intés sont de plus en plus légers, donc c’est plutôt bon signe (et nos retours sur ses maquettes sont minimes aussi… ils sont devenus l’exception). On peut bien « siloter » tout ce que l’on veut, travailler en confiance et en respect, ça vaut bien tous les titres ronflants et tous les trolls du monde.
D’ailleurs, quand je récupère des trucs de créas qui ne sont pas aussi sérieux, c’est là que tu te rends compte que… pinaise y a du boulot.
Sinon y a pas de mystères : au vu de ta remarque, de celle de Stéphanie et des autres, une constante => les gens sérieux pâtissent toujours des amateurs/branleurs. Malheureusement, ça n’est pas prêt de changer ^^
Julien, le jeudi 21 décembre 2017 à 13:45
>pour 5 éléments sur un site qui ne va pas ou peu bouger, j’ai pas besoin d’une armada de guides de styles, une couleur et ça suffit ^^
Ben à ce moment là tu la prends comme un grand dans le PSD, il est là pour ça :D.
J’ai très bien compris que les intés aimeraient que les designers fassent de l’inté, fassent du code, du proto responsive, des exports en retina etc, mais une fois de plus vous regardez le métier par le petit bout de la lorgnette, cad celui qui vous simplifie la vie.
Le créa/DA à fort à faire, et il est tout autant tiré de l’autre coté par le planning strat et le DC (ou par lui tout seul qui veut « se challenger » sur la conception justement, merci)
Donc si vous trouvez super d’avoir transformé votre graphiste en intégrateur c’est cool et ça doit vous simplifier la vie, mais c’est un autre métier (et qui demande du temps comme tu le soulignes).
Maintenant, pensez à ré-embaucher un DA !
RastaPopoulos, le jeudi 21 décembre 2017 à 15:05
> 2017
> donner des indications en pixels et pire des tailles de texte en pixels
> article suivant
STPo, le jeudi 21 décembre 2017 à 15:09
@RastaPopoulos
Donner oui, pas coder. Bienvenue dans le monde de la prod.
(Tous mes sites sont codés en unités relatives hin, textes et dimensions)
Essaie encore.
Nico, le jeudi 21 décembre 2017 à 15:35
Julien : sauf ton respect, tu trolles là ^^
Mais je ne peux pas croire que tu trolles bêtement :p
Justement, au lieu de faire de la petite lorgnette, on a fait le contraire => on lui a donné les billes pour qu’il pense en amont plus de choses et qu’il prenne plus de responsabilités (avec clairement le droit et le DEVOIR de hurler si on est hors des clous qu’il a posés), mais on n’en a pas fait un inté. Ce n’est pas son job (même s’il a qq billes basiques en CSS).
On va dire qu’on a scindé le poste d’inté entre le dev front et le créa.
Son job est de mieux transmettre son travail, à nous de la traduire au mieux de notre côté. Et on se démerde pour le responsive, le code, le passage en unités relatives, la réutilisabilité/DRY, le suivi du styleguide, etc. Il fait sa part, on fait la nôtre. Et chacun la fait au mieux en se mettant à la place de l’autre.
Pense-en ce que tu veux, mais l’engueulade créas/devs ici, c’est l’exception, pas le standard. Et c’est même plus souvent lui qui a le dernier mot (si si, on plie énormément, même et surtout quand ça ne nous arrange pas… justement parce qu’il est au top).
Et on n’a pas besoin de lui demander des exports retina, il le fait tout seul comme un grand : tout est exporté automatiquement en PNG/PNG2x/SVG (si applicable) pour la plupart du temps :p
Après simple choix : soit on tire vers le bas en mode batailles de tranchées, soit on tire vers le haut et tout le monde s’élève.
Julien, le jeudi 21 décembre 2017 à 22:16
C’est ce que je dis, vous l’avez rendu en partie intégrateur. C’est une solution (qui vous arrange) mais il faut juste comprendre qu’il aurait très bien pu être tiré dans l’autre sens (la conception) sans que ce soit une tare pour autant.
> « Justement, au lieu de faire de la petite lorgnette, on a fait le contraire => on lui a donné les billes pour qu’il pense en amont plus de choses et qu’il prenne plus de responsabilités »
Vous êtes bien gentils mais vous l’avez formaté selon votre besoin à vous, et c’est UNE vision, pas forcément mieux ni moins bien, juste votre vision de dev sur ce que devrait être un créa et sur votre « amont » et votre conception des responsabilités.
De mon point de vue vous lui avez justement retiré pas mal des « vraies » responsabilités du créatif qui ne sont pas nécessairement de créer un styleguide.
Forcément les devs ne voient que l’aspect du graphisme qui les touchent (en fait le webdesign) sans se rendre compte que c’est bien plus vaste. Il n’y a pas de mal à être un excellent webdesigner, à la frontière de l’intégration, mais reconnaissez juste qu’il existe autre chose.
Bernard Michel, le vendredi 22 décembre 2017 à 13:18
@Julien,
De la même manière qu’il n’y a pas UNE organisation, il n’y a pas UN profil de WebD, Designer, Graphiste et c’est plutôt bénéfique d’avoir des profils qui ont une appétence « Concept » et des profils avec une appétence « Front ».
Par ailleurs, c’est très français d’avoir une séparation aussi fort entre WebD et Dev. Front, par exemple en Angleterre (basé sur mes rencontres et discussion là-bas et pour éviter de faire une généralité, pourtant on est pas loin), les profils sont souvent hybrides Designer / Front ce qui permet en amont de réduire les sollicitations d’un Front en conception / design et de produire du proto / styleguide / moodboard rapidement et de la modifier tout aussi rapidement et en autonomie.
Mich mich