Hand-off design, l’art de passer le relais dans la production digitale.

Qu’est-ce que le hand-off design ? Comment le rĂ©ussir ? Que faut-il Ă©viter ?

Nous avons voulu regrouper ce qui nous paraĂźt ĂȘtre les clefs d’un hand-off rĂ©ussi, ou au contraire, ce qui freine les Ă©quipes collaboratives dans leurs rĂ©alisations.

Designers ou dĂ©veloppeurs, cet article s’adresse Ă  vous !

Le hand-off, c’est quoi ?

C’est ce doux moment de passation entre concepteurs et dĂ©veloppeurs. Un relais entre spĂ©cialistes qui peut vite passer du travail d’Ă©quipe Ă  la guerre des clans, oĂč le produit pourrait ĂȘtre le grand perdant.

Dans le cycle de crĂ©ation d’un produit numĂ©rique, il existe quelques grandes phases thĂ©oriques. Trop souvent, la crĂ©ation d’un produit numĂ©rique s’Ă©tablit sur une mĂ©thode linĂ©aire et descendante oĂč les dĂ©veloppeurs, en bout de chaĂźne, doivent assumer et rĂ©soudre les erreurs faites en amont par d’autres spĂ©cialistes. Erreur.

Le client explique d’abord son besoin au chef de projet. Ce dernier le traduit en fonctionnalitĂ©s aux Ă©quipes, les designers imaginent le produit en faisant des maquettes, les dĂ©veloppeurs codent les maquettes par l’intĂ©gration (mais pas que).

Cette vision quelque peu rigide peut vite engendrer des dĂ©convenues. Certaines bonnes pratiques pourraient faire gagner un temps prĂ©cieux aux acteurs de la production digitale. À travers cet article, nous tentons de comprendre oĂč se font les frictions, pour finalement proposer quelques solutions.

La communication entre designers et dĂ©veloppeurs n’est pas forcĂ©ment acquise


Une fois les prototypes testés, validés et approuvés par les utilisateurs et le client, les développeurs doivent intégrer des maquettes pour en faire un produit fonctionnel, concret et utilisable. Pendant ce relais, la bonne collaboration entre designers et développeurs est vitale. Il en va de la qualité du produit et du succÚs de sa livraison : mieux vaut que ce dernier soit au plus proche de ce qui a été testé et validé, au risque de se confronter au courroux du client.

Cette Ă©tape de passation peut-ĂȘtre redoutĂ©e – tant par les designers que par les dĂ©veloppeurs – car elle peut entraĂźner des frictions entre Ă©quipes, mĂȘme les plus aguerries. Le potentiel de chacun en serait freinĂ©, entrainant alors des frustrations. Le rendu post-production peut en pĂątir et ne ressemble plus Ă  ce design sexy imaginĂ© par les designers.

« Pierre-Henri m’a pondu des designs… je m’en sors plus. C’est des effets infaisables, j’ai dĂ» bosser toute la nuit pour me rendre compte ce matin qu’i avait pas appliquĂ© de grid, j’ai mal… »

Tips & tricks pour un hand-off réussi

Empathie et connaissances des métiers

Que vous soyez designer ou dĂ©veloppeur, vous avez peut-ĂȘtre entendu dire qu’un designer devrait savoir coder un minimum pour comprendre le mĂ©tier de dĂ©veloppeur. À juste titre. Par essence crĂ©atif et idĂ©aliste, le designer emploie des outils de conception qui lui laisse une marge de manƓuvre trĂšs large, oĂč seule l’imagination sera la limite. Sauf que les whiteboard et les IDE (Environnement De DĂ©veloppement) n’ont pas les mĂȘmes contraintes.

Idéaliser la conception et réaliser la production (src : UX World Design VS implémentation)


CĂŽtĂ© production, il est souvent bien plus difficile d’implĂ©menter cette transition liquide aux dĂ©gradĂ©s changeants ; les designs et les effets « wahou » visibles sur les mĂ©dias comme Dribbble ou Behance peuvent ĂȘtre trĂšs difficile Ă  coder, sans forcĂ©ment rĂ©pondre Ă  un besoin fonctionnel. Demandez avant Ă  vos dĂ©veloppeurs ce que ces initiatives leur coĂ»teront, ils vous remercieront. Au pire, ils poseront leur vĂ©to, mais vous Ă©chapperez aux retards de production.

Logiquement, un dĂ©veloppeur connaissant les grandes rĂšgles du design pourra travailler plus proprement, notamment sur les intĂ©grations. Comprendre le mĂ©tier de chacun s’avĂ©rerait donc ĂȘtre une des clĂ©s pour fluidifier et optimiser le travail entre les Ă©quipes.

Est-ce vrai ? Sûrement. Est-ce suffisant ? Pas tellement.

Dans la pratique, rien n’est si simple. Les designers et les dĂ©veloppeurs n’ont pas forcĂ©ment le mĂȘme langage et chacun rĂ©flĂ©chit de sa propre maniĂšre Ă  une solution viable. Il est parfois difficile de se comprendre, mĂȘme lorsque l’intĂ©rĂȘt est commun.

« Coucou Pierre-Henri, la maquette du BO ne correspond pas à la modélisation de la data sur la base mongo, on a pas prévu la possibilité de faire la jointure entre ces deux Models, est-ce que tu peux changer le design pour que la créa fit le design pattern ? »

Une mauvaise communication engendre beaucoup d’allers-retours chronophages et augmente le risque de passer Ă  cĂŽtĂ© d’informations majeures. Mais du coup, on fait quoi ?

Une vision linĂ©aire (et dĂ©conseillĂ©e) d’un hand off design – dĂ©veloppement


L’avenir appartient Ă  ceux qui se parlent tĂŽt

Le hand-off est trop souvent vu comme un relais oĂč l’équipe des designers passe « le bĂąton » aux dĂ©veloppeurs qui doivent se dĂ©brouiller avec ce qui leur est transmis. Nous pensons qu’il serait bĂ©nĂ©fique d’envisager cette Ă©tape autrement : la passation entre les designers et les dĂ©veloppeurs doit ĂȘtre la consĂ©cration de ce qui a Ă©tĂ© dĂ©cidĂ© ensemble et ne devrait pas rĂ©vĂ©ler de surprises pour ces derniers.

« Au fait Chantale, j’ai ajoutĂ© une petite feature sympa pour impressionner le client, un petit calculateur de ROI intĂ©grĂ© Ă  la card de la homepage. PlutĂŽt simple Ă  coder pour toi, nan ?»

Si organiser des rĂ©unions peut donner l’impression de perdre du temps, il ne faut jamais oublier que les dĂ©veloppeurs sont les mieux placĂ©s pour savoir ce qui est rĂ©alisable et surtout, en (Ă  peu prĂšs) combien de temps.

En discutant ensemble des designs lors de la prĂ©sentation des wireframes, et notamment par la consultation d’un lead-dĂ©veloppeur au moment d’une rĂ©union de synthĂšse sur le recueil des besoins, des difficultĂ©s futures d’implĂ©mentation peuvent ĂȘtre rĂ©vĂ©lĂ©es. On peut alors Ă©viter de mauvaises surprises. Parfois, certains dĂ©veloppeurs auront par « chance » dĂ©jĂ  rencontrĂ© un problĂšme donnĂ©, ils pourront rapidement proposer une autre solution.

À distance ? Pas d’excuses

Comme dans n’importe quelle relation humaine, la clef du succĂšs d’un bon hand-off serait : đŸ„…đŸ„â€ŠđŸ„ La communication ! Vous le saviez dĂ©jĂ  ? Évidemment. C’est une chose de le savoir, s’en est une autre de la mettre en place. Une bonne communication s’apprend et surtout, elle se travaille Ă  travers des processus clairs et un suivi rigoureux.

Certaines entreprises sont spĂ©cialisĂ©es dans le design, d’autres dans le dĂ©veloppement. Si un projet se rĂ©alise Ă  travers deux prestataires diffĂ©rents, ces spĂ©cialistes ne seront pas dans le mĂȘme lieu physique. Cette distance pourrait avoir la fĂącheuse tendance Ă  dĂ©tĂ©riorer la communication. Pourtant rien n’empĂȘche de travailler ensemble, les outils d’aujourd’hui nous permettent de communiquer aisĂ©ment et constamment, plus d’excuses.Certains outils peuvent nous aider Ă  communiquer toujours plus (👋 coucou Zoom, Slack, Jira, Discord, Miro…).

Si les mĂ©thodes agiles poussent les dĂ©veloppeurs Ă  faire part de leurs avancĂ©es, les designers doivent s’en inspirer pour informer rĂ©guliĂšrement les Ă©quipes techniques de l’implĂ©mentation de fonctionnalitĂ©s majeures. Nous pensons qu’il est judicieux de prĂ©voir des rĂ©unions hebdomadaires pour Ă©changer sur la conception de chaque fonctionnalitĂ© majeure.

Chacun sait alors oĂč en est le projet et Ă  connaissance des choix de conception qui ont Ă©tĂ© faits et surtout pourquoi ils ont Ă©tĂ© faits.

Selon nous, le hand off ne doit pas ĂȘtre vu comme un processus linĂ©aire et descendant. Il doit ĂȘtre une initiative inclusive et itĂ©rative.

Chantale intégrant les maquettes de Pierre-Henri (src : Adobe Stock)


En consultant les dĂ©veloppeurs au dĂ©but des phases de prototypage, chacun se sent impliquĂ© de façon Ă©quivalente et les deux Ă©quipes n’en forment plus qu’une.

Cette initiative Ă©viterait sans doute que la faute soit rejetĂ©e sur l’une ou l’autre des Ă©quipes lorsqu’un problĂšme surgit.

Pendant cette rĂ©union, posez-vous quelques questions : oĂč se trouvent les informations nĂ©cessaires Ă  l’intĂ©gration ? Existe-t-il une documentation disponible ? Faut-il prendre en considĂ©ration tous les Ă©crans des maquettes ? Mieux vaut se poser pour se synchroniser avant de dĂ©marrer l’intĂ©gration. Passons le relais sur une bonne base. Tout le monde y sera gagnant.

Organiser et encadrer le design

Un Design System (DS) est une « boite » permettant de rassembler un certain nombre d’outils communs aux designers et aux dĂ©veloppeurs. Ces outils sont variĂ©s : couleurs, typographie, icĂŽnes, illustrations, patterns, alignements, etc.

C’est une bibliothĂšque digitale qui rassemble tous les composants rĂ©utilisables de la future interface. Souvent assimilĂ© Ă  un kit UI (qui est une de ses parties), le DS est crĂ©Ă© par le designer et permet de travailler de maniĂšre plus efficace sur un projet. Surtout, il permet d’Ă©tablir des rĂšgles de conception pour harmoniser le travail du groupe.

Un Ui kit sans surplus pour un petit projet (src : Colm Tuite)


Aussi utile aux designers qu’aux dĂ©veloppeurs, le DS a pour objectif de faciliter la comprĂ©hension globale des Ă©lĂ©ments de l’interface. Il en dĂ©taille l’aspect, le comportement ou l’Ă©tat (hover, active, disabled, et toutes les autres variations possibles) de ses composants.

Attention, un DS gĂ©nĂ©rique est trĂšs complet (comme les guides Material Design de Google ou Human Interface d’Apple) et peut apporter un degrĂ© de complexitĂ© trop Ă©levĂ© pour la plupart des projets. Le nombre d’Ă©lĂ©ments est si consĂ©quent qu’un designer ou dĂ©veloppeur pourrait vite s’y perdre. Il est alors plus pertinent de crĂ©er un systĂšme qui dĂ©coule des composants utilisĂ©s dans les interfaces.

Avant de passer Ă  l’étape de passation, nous pensons que le designer doit vĂ©rifier si :

  • Tous les composants nĂ©cessaires sont bien prĂ©sents dans le DS
  • Les composants du DS ont bien tous Ă©tĂ© utilisĂ©s dans les interfaces, sinon, les supprimer afin de ne pas surcharger le dĂ©veloppeur, car il les aura intĂ©grĂ©s Ă  sa bibliothĂšque inutilement.

Au dĂ©but de la phase d’intĂ©gration, le dĂ©veloppeur peut crĂ©er sa propre bibliothĂšque de composants rĂ©currents pour faciliter son travail. Pour ce faire, il va aller chercher les Ă©lĂ©ments prĂ©sents dans le DS. Comme toute Ă©tape, celle-ci peut ĂȘtre chronophage, d’autant plus si elle n’a pas Ă©tĂ© pensĂ©e par le designer en amont.

En regroupant un maximum d’informations au mĂȘme endroit, le DS s’inscrit donc comme un outil de documentation utile sur lequel designer et dĂ©veloppeurs peuvent s’appuyer pour faciliter la transmission d’informations et minimiser les erreurs de communications.

Parlez-vous français ?

Pas le mĂȘme mĂ©tier, pas le mĂȘme jargon, pas la mĂȘme rĂ©flexion


Se parler n’est pas si simple, surtout quand on ne parle pas le mĂȘme langage technique.

Nous sommes tous empreints d’habitudes, il est difficile de modifier notre vocabulaire parlĂ©. Une convention de nommage des dossiers, de fichiers, de composants et de sous-composants possĂšde un avantage certain. 

C’est un gain de temps pour les dĂ©veloppeurs, notamment lorsqu’ils recherchent des Ă©lĂ©ments dans un environnement auquel ils peuvent ne pas ĂȘtre habituĂ©s. En se repĂ©rant via des conventions qu’ils connaissent, ils pourront naviguer plus facilement dans l’interface et surtout comprendre quels sont les cheminements dans des composants imbriquĂ©s.

La convention de nommage des couleurs dans le DS d’Expedia (src : Expedia)


Ne pas perdre une miette

La dĂ©multiplication des moyens de communication crĂ©e un risque. Si la communication est une des clef d’un hand-off rĂ©ussi, il faut faire attention Ă  ne pas se perdre parmi tous les canaux disponibles : gestion de projet (Trello), brainstorming sur whiteboard (Miro), plateformes de chat (Slack), outil de gestion des tickets (Jira), commentaires dans les outils de conception (Figma) etc.

Cette variĂ©tĂ© des supports peut parfois entraĂźner des pertes d’informations capitales, notamment si celles-ci ne sont pas placĂ©es au bon endroit. MĂȘme si chacun de ces outils possĂšde son rĂŽle, est-il pour autant nĂ©cessaire de tous les utiliser ? Évidemment, cela dĂ©pendra de la taille du projet et de l’Ă©quipe impliquĂ©e. Dans la plupart des projets d’envergure moyenne, il faudra surtout s’attacher Ă  sĂ©lectionner les bons canaux tout en dĂ©finissant strictement les rĂšgles de leur utilisation.

Documentons, documentez. Pour minimiser les pertes, nous optons parfois pour un enregistrement des rĂ©unions majeures, synthĂ©tisĂ©es dans des espaces de stockage unique avec les liens des diffĂ©rents documents nĂ©cessaires, pour suivre l’évolution des dĂ©cisions ou les itĂ©rations. Un dĂ©veloppeur n’a pu ĂȘtre prĂ©sent lors d’une rĂ©union ? Hourra ! Il peut aller consulter les rapports sans solliciter ses collaborateurs.

Si tout le monde travaille de façontransparenteet que les informations sontrassemblĂ©es au mĂȘme endroit alors chacun saura exactement oĂč trouver les informations. La collaboration sera plus fluide et permettra de faire gagner du temps lors des prochaines Ă©tapes. 

Aux bons outils

Bien du chemin a Ă©tĂ© parcouru depuis l’époque oĂč les maquettes Ă©taient conçues sur Photoshop ou pire : Paint. Figma, Sketch, Adobe XD, ont rĂ©volutionnĂ©le monde de la conception de produits numĂ©riques. La plupart des Ă©quipes Ă  l’origine de ces outils ont rĂ©alisĂ© un travail colossal pour ajouter des options utiles au hand-off.

GrĂące Ă  l’ajout de nouvelles fonctionnalitĂ©s, notamment tournĂ©es vers l’inspection et les commentaires automatiques inclus dans des blocs CSS, ces outils permettent aujourd’hui de rĂ©duire la charge de travail des intĂ©grateurs ou dĂ©veloppeurs front, tout en fluidifiant les Ă©changes.

L’inspection d’un composant dans Figma


Il existe un grand nombre d’outils utiles aux passations, le site uxtools.co propose Ă  ce titre une comparaison intĂ©ressante de certains d’entre eux : 👉 UX Tools | Compare Handoff Tools.

« Créez une source unique de vérité pour tous les aspects de votre Design System, en rassemblant les outils que vos équipes utilisent déjà. » Zeroheight tagline

Selon nous, le principal outil du handoff est Zeplin.

Au-delĂ  d’un ballon dirigeable jaune, c’est un SaaS qui comble le fossĂ© entre concepteurs et les dĂ©veloppeurs par la gĂ©nĂ©ration de blocs CSS pour chaque composant utilisĂ© dans la conception. Ce logiciel permet entre autres :

  • de regrouper plusieurs plans de travail dans un groupe et de les organiser selon votre choix, ce qui sera indiquĂ© aux autres utilisateurs comme faisant partie du projet.
  • de travailler en groupe sur un projet et d’ajouter des commentaires/remarques, de mettre de cotĂ© une maquette particuliĂšre
  • de suivre efficacement le versioning et de mettre Ă  jour les maquettes en consĂ©quence

Si l’outil ultime rĂ©pondant Ă  toutes les phases de la conception n’existe pas, le bon alliage des logiciels permet un combo gagnant.

Nous aimons construire les composants sous Figma que nous exportons sous Zeplin pour consolider la documentation. S’il existe un DS important pour le projet, nous le dĂ©posons sur Zeroheight pour faciliter la consultation. Certains dĂ©veloppeurs complĂštent la mĂ©thode par la mise en place d’un Storybook.

Nous conseillons d’organiser les composants et systĂšmes de composants de façon simple, claire et surtout d’une maniĂšre collĂ©giale. Les maquettes doivent ĂȘtre documentĂ©es le plus finement possible, allant jusqu’Ă  expliquer par bloc de texte les informations sur les animations/interactions Ă  implĂ©menter.

Pour citer un cas d’Ă©cole que l’on considĂšre comme rĂ©fĂ©rentiel dans ce domaine, nous parlerons du brand styleguide interactif du SaaS Webflow, un web builder Ă  la mode. Pour dĂ©montrer le sĂ©rieux de leur travail, er pour faciliter la tĂąche Ă  leurs dĂ©veloppeurs comme aux designers curieux d’en apprendre plus sur leur DS, les Ă©quipes de Webflow ont construit un site vous permettant de rĂ©cupĂ©rer trĂšs simplement les Ă©lĂ©ments (logo, couleurs, typographies, photos, tone of voice…) qui dĂ©finissent leur identitĂ© graphique. Cerise sur le gĂąteau ? Cette bibliothĂšque est elle-mĂȘme conçue avec… Webflow.

Et aprĂšs ? 

Une fois le produit livrĂ© et la recette terminĂ©e, nous pensons qu’il est intĂ©ressant de demander un rapide feedback Ă  toutes les Ă©quipes. Comprendre quels ont Ă©tĂ© les points forts de cette collaboration et quels sont ceux qui restent Ă  amĂ©liorer est nĂ©cessaire, pour mieux faire au prochain coup. Ainsi, de nouvelles mĂ©thodes pourront ĂȘtre testĂ©es, validĂ©es et la mĂ©thode de travail sera consolidĂ©e. Au mĂȘme titre que les projets, le travail en Ă©quipe s’amĂ©liore par itĂ©ration

Si les outils de conception ont beaucoup Ă©voluĂ© et donnent l’impression d’ĂȘtre intuitifs et simples au premier abord, il ne faut pas penser qu’ils le seront pour tous. La maĂźtrise de ces outils prend du temps, denrĂ©e trop rare pour les dĂ©veloppeurs. Cette multitude d’écrans, de calques, de groupes, de calques peut rapidement crĂ©er de la confusion pour des dĂ©veloppeurs dont ce n’est pas l’environnement de travail habituel et qui ont dĂ©jĂ  beaucoup Ă  faire.

L’idĂ©e de cet article ici est d’abord de prĂ©venir sur cette mĂ©thode simpliste qui consiste Ă  – passer la patate chaude aux dĂ©veloppeurs – exit la flemmardĂŻte aiguĂ« et vive les Ă©changes ! Finalement, le job d’un designer, c’est aussi d’aider ceux qui travaillent dans la production en essayant de leur faciliter la tĂąche.

Les diffĂ©rentes mĂ©thodes et outils mentionnĂ©s dans cet article sont propres Ă  notre façon de faire et ne sont en aucun cas exhaustifs. À chaque Ă©quipe de trouver la mĂ©thode qui lui convient !

Articles similaires
—

Parlons de votre projet