Naviguer jusqu'au contenu principal

5 choses que les designers doivent savoir pour une livraison en douceur

Lauren ByrneDesigner Advocate, Figma

La livraison est un processus, et non un moment. Étant donné qu'il s'agit d'un flux constant de designs en cours, de communication et de collaboration, comment la simplifier ? Lauren Andres, designer advocate, vous donne ses conseils.

Partager 5 choses que les designers doivent savoir pour une livraison en douceur

Il n'y a pas de meilleur révélateur de la vérité que la saisie semi-automatique de Google. Lorsque vous tapez « Design development handoff is... » (livraison design-développement) dans la barre de recherche, il suggère rapidement des termes tels que « issues » (problèmes) et « is not working » (ne fonctionne pas). Non pas que la livraison soit un problème pour tout le monde, mais nous recherchons constamment des moyens de l'améliorer.

C'est tout sauf surprenant. Il peut en effet s'avérer difficile de déterminer quand faire appel à des collaborateurs, quand partager le contexte et savoir comment faire avancer le travail quand tout bouge constamment et que votre équipe travaille dans plusieurs pays et sur plusieurs fuseaux horaires. Alors, comment vous assurer que le travail est réellement prêt pour le développement ? Lauren Andres, designer advocate chez Figma, a passé des heures et des heures à aider des équipes à rationaliser leurs processus, vous partage les cinq choses que tout bon designer doit savoir pour assurer une livraison rapide et réussie.

1. Rationaliser et clarifier les informations

Les annotations vous permettent de partager l'intention qui sous-tend les décisions en matière de design et de mettre en évidence les détails que vous ne voulez pas perdre. Si vous n'êtes pas sûr de la nature de ces détails, la meilleure chose à faire est de demander à vos développeurs ce qu'ils jugent le plus utile de signaler. Par exemple, mon homologue développeur n'aura peut-être pas besoin que j'annote l'espacement ou la couleur si je les ai déjà définis en tant que variables. En revanche, il peut être très utile que j'ajoute une note si j'utilise un nouveau composant, s'il y a une interaction spécifique qui doit se produire et qui n'était peut-être pas claire dans un prototype, ou s'il est nécessaire d'adapter un visuel à chaque plateforme.

Un fichier Figma montrant des annotations sur des designs, tels que la hauteur, le remplissage et le comportement.Un fichier Figma montrant des annotations sur des designs, tels que la hauteur, le remplissage et le comportement.

Avec les annotations, vous pouvez ajouter des informations (texte et propriétés, par exemple) pour aider les développeurs au cours du processus de livraison. Pour en savoir plus sur les annotations et sur la façon dont nous les avons créées, cliquez ici.

En plus d'ajouter des propriétés ou du texte à des couches spécifiques, vous pouvez facilement mesurer la distance entre les couches grâce au nouvel outil d'annotations de Figma et épingler cette information pour la livraison.

Par le passé, vous pouviez annoter des fichiers avec des commentaires ou des notes, mais vous aviez du mal à garder une trace de tous les détails. Chez Figma, nous avons récemment lancé les annotations dans Dev Mode pour faire gagner du temps aux designers lorsqu'ils ajoutent des détails importants tels que des spécifications, des mesures et des notes aux maquettes finales, et pour aider les développeurs à trouver la bonne information immédiatement. Dev Mode n'a pas pour but d'éliminer les discussions entre les designers et les développeurs, mais d'améliorer la communication entre eux.

2. Adopter un langage commun

Même si nous travaillons main dans la main, le design et le développement sont deux disciplines complètement différentes, ce qui signifie qu'il est facile de perdre le fil. (Vous voulez être sûr que lorsque vous faites référence à un toggle, par exemple, votre collaborateur ne suppose pas que vous parlez d'un switch). Plus vous passerez de temps à vous mettre d'accord sur la dénomination au début de votre collaboration, plus vous pourrez vous concentrer par la suite sur des discussions plus approfondies sans vous perdre dans des détails qui peuvent prêter à confusion.

Concernant les éléments les plus fondamentaux, tels que les polices, les couleurs et l'espacement, les variables et les styles sont un excellent moyen de rester synchronisés. Consultez vos développeurs : il se peut qu'ils aient déjà établi des conventions de dénomination dans leur code que vous pouvez appliquer à vos designs. Il est bien plus rassurant de savoir que votre développeur vous comprend lorsque vous dites qu'un bouton doit être bg-primary-active with body text que d'essayer de se souvenir du code hexadécimal exact et des détails de la police.

3. Organiser ses fichiers avec des libellés

En tant que designer, j'aime le plan de travail infini de Figma. Mais cela peut être déroutant et accablant d'être lâché dans un fichier si vous ne savez pas exactement où trouver ce dont vous avez besoin. Je suppose qu'un développeur aura du mal à s'y retrouver dans un tel fichier :

Un fichier Figma qu'un designer Figma s'apprête à transférer à un développeur.Un fichier Figma qu'un designer Figma s'apprête à transférer à un développeur.

S'il n'y a rien de mal à ce que nos fichiers aient l'air, disons, « en cours d'élaboration » lorsque nous sommes dans la phase de réflexion et d'itération, lorsque nous commençons à inviter nos collègues développeurs, il est temps de faire le ménage.

Réduisez le plan de travail infini en utilisant des sections pour créer des groupes de design qui se tiennent. Ajoutez un statut « Ready to dev » à ces sections, ou à tout autre frame prêt à être utilisé, pour aider votre développeur à repérer les éléments les plus importants.

Les templates peuvent également réduire les changements de contexte. Si votre équipe s'aligne sur un template unique, les développeurs n'ont pas à réapprendre comment un fichier est présenté chaque fois qu'ils travaillent avec un designer différent. J'aime aussi demander à mes homologues développeurs ce qu'ils veulent voir lorsqu'ils codent un design, que ce soit pour mobiles, tablettes ou ordinateurs, ou une distinction claire entre ce qui est du texte codé en dur et ce qui est dynamique. À partir de là, vous pouvez établir une checklist qui réduit une partie de la charge mentale et vous permet, ainsi qu'aux autres designers, de savoir quand vous pouvez poser les crayons.

Un fichier Figma montrant « Ready for dev »Un fichier Figma montrant « Ready for dev »

4. Archiver les anciens designs

Quand vous organisez les pages en fonction de leur importance, séparez les recherches passées du travail en cours. Je ne suis pas favorable à l'idée de tout effacer ; le plus souvent, je passe par dix itérations pour finir à peu près au point de départ (est-ce que ça vous parle ?). Et puis, il est utile de revenir en arrière et de comparer ce que nous avons fait avec ces anciennes versions. Le plus important est de bien distinguer ce qui est ancien de ce qui est nouveau. Je vous recommande de placer les anciens designs dans une page d'archives clairement identifiée pour limiter au maximum la confusion. Vous pouvez également créer des branches pour figer uniquement le travail sur lequel vous voulez que les développeurs portent leur attention dans la livraison.

5. S'appuyer sur les composants

Bien entendu, quand on parle de livraison, il n'est pas seulement question du design en soi. Il s'agit de s'assurer que nos collaborateurs comprennent comment nous sommes parvenus à cette solution, pourquoi et quelle est notre vision pour la concrétiser. Pour les développeurs, Figma est souvent un espace de collecte d'informations et de contexte, même si leur travail se déroule en dehors. Tout ce que vous pouvez faire pour les aider à trouver ce dont ils ont besoin en réduisant les allers-retours est utile. D'un point de vue tactique, j'aime utiliser les component descriptions. Les détails de l'utilisation de mon composant sont ainsi toujours présents et les développeurs n'ont pas besoin de retourner dans la documentation pour comprendre comment l'utiliser.

Un designer et un développeur déplacent leurs curseurs autour d'un fichier prêt pour la livraison.Un designer et un développeur déplacent leurs curseurs autour d'un fichier prêt pour la livraison.
Un fichier Figma avec un surlignement sur la section « Dev resources »Un fichier Figma avec un surlignement sur la section « Dev resources »

J'encourage également les développeurs à utiliser les Dev resources dans Dev Mode, afin d'ajouter des liens qui leur seront utiles. Je pourrais certes ajouter des liens à la description de mon composant, mais je ne suis pas toujours sûre des liens qui seront les plus utiles (et je n'y ai peut-être même pas accès). Pour moi, il est beaucoup plus logique que les développeurs ajoutent eux-mêmes ce qu'ils savent être utile plutôt que j'essaie de deviner.

En tant que designers, nous utilisons souvent Figma. Beaucoup de choses sont devenues une seconde nature pour nous, et il est facile d'oublier que ce n'est pas le cas pour tout le monde. Lorsque j'ai présenté Figma aux développeurs avec lesquels je travaillais il y a des années, j'ai pris beaucoup de choses pour acquises, notamment en supposant qu'ils sauraient comment exporter des assets eux-mêmes ou mettre un fichier dans leurs favoris. (De même, si j'entrais dans VS Code aujourd'hui, je ne saurais pas la moitié de ce que je pourrais faire sans quelqu'un pour me guider). Figma n'est qu'un des nombreux outils utilisés par les développeurs. Nous devons donc les accompagner et de leur donner les moyens de travailler main dans la main avec nous.

En savoir plus sur les annotations et sur les nouveautés à venir de Dev Mode.

Découvrez comment rationaliser la livraison dans Dev Mode et débloquer la collaboration entre designers et développeurs.

Créez et collaborez avec Figma

Lancez-vous gratuitement