Laboratoire de workflow : déployer des designs directement avec Figma Make

Bienvenue au Laboratoire de workflow, où nous présentons un exemple de workflow utilisant les produits et outils Figma.

Généralement, le parcours entre « j’ai remarqué un détail mineur » et « la modification e été déployée » passe par la création d’un ticket. Le designer rédige le ticket, celui-ci atterrit dans le backlog, puis il se retrouve noyé sous toutes les tâches déjà attribuées à l'équipe d'ingénieurs. Pour les petites retouches de haute précision, c'est le cimetière des bonnes intentions. Le travail est trop minutieux pour être priorisé et trop important pour être abandonné, il reste donc en suspens.

Le problème implique également un deuxième coût. Lorsque le designer remet une description écrite, la nuance se perd. « Resserrez un peu l'espacement » ou « le lecteur d'écran présente mal ce passage » : ces remarques donnent lieu à un va-et-vient de captures d'écran et de précisions, et l'ingénieur doit interpréter des décisions que le designer aurait pu prendre lui-même. Mais que se passerait-il s'il existait un autre moyen de gérer ce workflow ?

Le problème

Prenons comme exemple le Musée de l'avenir spéculatif (MOSF), un musée fictif qui explore la manière dont la culture imagine ce que l'avenir nous réserve. Cette institution améliore actuellement l'accessibilité de son site web, parallèlement à une refonte complète de son architecture. Compte tenu des différentes priorités concurrentes, l’affectation des ressources à ce projet constitue un défi de taille. Le designer souhaite combler les lacunes en matière d’accessibilité, tandis que l’ingénieur doit se concentrer pleinement sur la refonte, tout aussi importante. Pour atteindre ce double objectif, le chef de projet propose une approche différente : laisser aux ingénieurs le soin de s’occuper des tâches les plus complexes, et confier au designer la responsabilité de réaliser de bout en bout les retouches qualitatives rapides en utilisant Figma Make avec leur code de production. Ces derniers 20 % sont précisément ce qui distingue un site web qui fonctionne techniquement d’un site véritablement accessible ; l’équipe s’accorde donc sur cette stratégie. Suivez le parcours d’un designer qui bouleverse ce scénario, son projet évoluant du plan de travail, à la révision jusqu'à une demande d'extraction fusionnée, le tout sans créer un seul ticket.

Feedback recueilli sur le plan de travail

Avant de modifier quoi que ce soit, le designer souhaite tester l’expérience actuelle en conditions réelles. Il utilise l'agentdans Figma Design pour générer un ensemble de personas synthétiques — un nouvel utilisateur planifiant une visite, un membre régulier, une personne parcourant le site à l’aide d’un lecteur d’écran — et demande à chacun d’entre eux de naviguer sur le site afin de recueillir un feedback.

Les retours sont précis et concernent pour la plupart des détails mineurs : une mention prêtant à confusion sur la page de l’exposition, un appel à l’action passant inaperçu, un sélecteur de date difficile à appréhender d’un seul coup d’œil, ou encore une fonction de recherche qui aboutit à un écran vide lorsqu’une requête ne donne aucun résultat. Aucun de ces éléments ne nécessite de changement majeur, mais, pris dans leur ensemble, ce sont des détails qui rendent le site web plus facile à utiliser.

Le designer prend en compte ce feedback, puis soumet les modifications apportées au design à l’équipe pour validation. Ensemble, le designer, l'ingénieur, et le chef de projet passent en revue chacune d’entre elles : une libellé plus clair sur la page des visites, un appel à l’action plus visible et un sélecteur de date plus convivial pour l'utilisateur. Ils conviennent que ces modifications servent l’objectif commun : un site que chacun peut parcourir et apprécier, quelle que soit son expérience du web.

Travailler directement sur le code pour contourner le backlog

Les modifications convenues sont mineures et bien comprises ; ainsi, plutôt que de créer un ticket et d’attendre, le designer demande à l’ingénieur l’accès au code source, non pas pour se charger de la réécriture, mais pour apporter directement ces corrections spécifiques.

L'ingénieur accorde l'accès, et le designer connecte le référentiel GitHub du projet à Make. Le code de production étant désormais disponible dans Figma, le designer crée une nouvelle branche à partir du site actuel et commence par ce qui semble être la correction la plus simple de la liste : le sélecteur de date sur la page de l'exposition, que les personas de l'agent Figma ont trouvé difficile à comprendre.

Dans une maquette statique, c'est un changement qui prend cinq minutes. Cependant, en examinant le code, Make met en évidence un élément que le plan de travail ne permet pas de voir : le sélecteur de date n'est pas une exception. C'est un composant partagé — le même que celui utilisé dans le calendrier des événements et dans le processus d’inscription pour l’adhésion. Ce qui semblait n’être qu’une simple modification est en réalité un changement qui doit être effectué à trois endroits simultanément.

Un workflow basé sur des tickets aurait pu corriger le sélecteur de date uniquement sur la page de l’exposition, laissant le calendrier des événements et le processus d’adhésion dans leur ancienne version — une incohérence qui n’aurait jamais été remarquée, ou alors bien plus tard. Parce que le designer a accès au code, la dépendance partagée est désormais visible, et la correction peut être effectuée une seule fois, à l'endroit approprié.

Une fois cette tâche terminée, le designer s'attaque au reste de la liste : le libellé plus clair, l'appel à l'action plus visible, un affichage plus convivial pour les écrans vides. Chacune de ces modifications est mineure en soi, mais ensemble, elles transforment un site qui se contente de fonctionner en un site qui donne l’impression d’avoir été pensé avec soin — ces derniers 20 % qui, généralement, ne sortent jamais du backlog.

Revue avec l'ensemble de l'équipe

Une fois les modifications effectuées, le designer transmet le travail à l'équipe pour une revue finale. C’est à ce stade que l’objectif d’accessibilité se précise. Les corrections visibles ont été intégrées. Maintenant l'équipe annote le fonctionnement de chacune de ces modifications pour les technologies d’assistance, directement à l’endroit où elles se trouvent. Il s'agit notamment de l’attribut aria-label que le sélecteur de date partagé doit annoncer afin qu’il soit non seulement lisible, mais également lu à haute voix ; d'une étiquette de lecteur d’écran qui correspond à ce qui s’affiche à l’écran ; d'un ordre de focus qui atteint l’appel à l’action au lieu de l'ignorer ; et d'un état vide accompagné d’un message que le lecteur d’écran peut annoncer, afin que la réponse à une recherche sans résultat ne soit pas le silence.

Le chef de projet confirme que l'ensemble reste conforme à l'objectif d'accessibilité, l'ingénieur donne son avis sur les éléments à traiter au niveau du code, et le designer intègre les dernières retouches.

Envoi de la PR

Une fois les dernières annotations traitées, le designer transmet une demande d'extraction à la base de code directement depuis Make. L'ingénieur examine le code (qui intègre désormais l’intention de conception mise à jour, les commentaires de l’équipe et les annotations d’accessibilité, le tout associé à la même modification), l’approuve et fusionne la branche. Les corrections qui auraient passé un trimestre dans le backlog ont ainsi été déployées en une journée.

Cette méthode de travail constitue un changement simple dont les retombées s’inscrivent sur le long terme. Un ticket est clôturé et disparaît, et les décisions qu’il contenait s’évanouissent avec lui. La modification fusionnée les conserve : les commentaires, les annotations d’accessibilité, le raisonnement qui a conduit à partager le sélecteur de date. Lorsque quelqu’un réexamine le sélecteur de date six mois plus tard, le cheminement qui a mené à ce résultat figure clairement dans l’historique partagé de l’équipe.

Parcours vers la production : un type de transfert différent

Le modèle traditionnel de transfert de tâches considère le designer et l’ingénieur comme deux postes sur une chaîne de montage. Il fonctionne bien pour des fonctionnalités de grande envergure et bien définies. Mais les finitions plus soignées, les améliorations en matière d’accessibilité et les détails qui définissent l’expérience globale du produit nécessitent un autre type de transfert, dans lequel le designer travaille directement dans le code.

Cette méthode de travail n'exige pas que le designer devienne ingénieur, ou que l'ingénieur devienne designer. Elle permet à chacun d'exercer son jugement là où il compte le plus : les ingénieurs se sont concentrés sur la refonte de l’architecture, le designer a pris en charge les améliorations de bout en bout, et le chef de projet a veillé à ce que l’ensemble du projet reste axé sur l’objectif. Cette branche regroupait toutes les contributions — le design visible, les commentaires écrits et les libellés qu’un lecteur d’écran lira à haute voix — du plan de travail à une demande d'extraction fusionnée.

Dans ce workflow, les derniers 20 % n'ont pas été supprimés, mais bel et bien déployés.

Découvrez comment publier vos projets Make directement sur GitHub dans notre centre d'aide ou regardez nos dernières conférences Config sur le design dans le code et l'utilisation de l'agent de design Figma.