Préparer un Design Handoff

Cette compétence est la gate de fin de phase Design. L'engineering s'appuie sur un ensemble cohérent de signaux pour savoir qu'un design est prêt à être repris. Un handoff incomplet crée des questions en aval et ralentit l'epic vers le développement.

Le handoff est deux choses, pas une seule

Un handoff est terminé quand les deux sont en place :

1. Le fichier Figma à l'état Ready-for-Dev. Designs finaux groupés sur une seule page, avec des sections nommées pour correspondre aux engineering stories qui les consommeront. Sections marquées « Ready for Dev » dans Figma. Chaînes visibles à l'utilisateur (toasts, messages d'erreur, vérifications de formulaire, contenu d'emails) annotées sur les frames. Prototype annoté disponible.
2. L'état Jira aligné. Fichier Figma lié dans le champ « Design » de l'Epic, sections marquées Ready for Dev dans Figma, et l'EM fait passer l'Epic à Ready for Dev. La chorégraphie complète est dans navigating-design-jira-process.

Si l'un manque, le handoff n'est pas terminé.

Checklist de préparation (avant de déclarer le handoff)

• L'initiative produit ou la page PRD existe et est à jour.
• L'Epic engineering existe dans Jira et le designer lui est ou a été assigné.
• Les designs ont passé des critiques à 30%, 60% et 90% et la review 90% a été traitée.
• Les tests avec de vrais utilisateurs ont eu lieu le cas échéant (c'est pour ça que 90% existe).
• La page final-designs du fichier Figma est curée — pas de pages de brouillon, pas de frames inutilisés en surface Ready-for-Dev.
• Toutes les chaînes visibles à l'utilisateur sont annotées dans Figma à côté des frames auxquelles elles s'appliquent.

Si un élément manque, signale-le avant de déclarer le handoff prêt — le handoff n'est pas le moment de découvrir que la review 90% n'a jamais eu lieu.

Vérification de la disponibilité Figma

Avant de marquer les sections Ready for Dev, confirme :

• Sections alignées aux stories. Chaque section nommée correspond à une seule engineering story. Évite les sections qui couvrent plusieurs stories ou les stories qui couvrent plusieurs sections.
• Les tokens sont liés à la bibliothèque. Pas de valeurs hex brutes là où une variable de design-system existe. Compose using-figma avec get_variable_defs pour vérifier.
• Chaînes annotées. Chaque chaîne visible à l'utilisateur — labels de boutons, messages d'erreur, toasts, états vides, texte d'aide — est présente dans les frames ou annotations Figma.
• Cas limites couverts. Les états vides, erreur, succès partiel, hors ligne, et gated premium existent sur les frames pertinentes (ou sont explicitement hors périmètre et notés).

Composer avec d'autres compétences

• using-figma. Utilise get_metadata pour confirmer que les sections Ready-for-Dev existent avec les noms attendus ; utilise get_variable_defs pour confirmer que les tokens sont liés à la bibliothèque plutôt que des valeurs brutes ; utilise search_design_system si un composant du design est étrangement proche d'un qui existe déjà.
• navigating-design-jira-process. Les mouvements Jira qui accompagnent le handoff — lier Figma au champ « Design » de l'Epic, marquer Ready for Dev dans Figma, l'EM fait passer l'Epic — sont là.
• content-style-guide. Passe chaque chaîne annotée par le style guide avant de déclarer le handoff. Les toasts, erreurs et texte de vérification de formulaire sont le lieu à plus fort impact pour attraper les problèmes de style de contenu avant qu'engineering ne les localise.

Omissions courantes à attraper

• Fichier Figma sans marques Ready-for-Dev. L'engineering ne peut pas trouver ce qui est final. C'est l'étape la plus souvent sautée.
• Sections non alignées aux stories. Chaque story devrait correspondre à une section Figma dont le contenu est uniquement cette story. Une inadéquation crée de l'ambiguïté au moment de la review.
• Annotations de chaînes manquantes. L'engineering demandera les chaînes dès qu'il reprendra l'Epic. Annote-les dans Figma à côté des frames avant de déclarer le handoff — ne reporte pas à engineering d'inventer le contenu.
• États limites absents. Vide, erreur, succès partiel, hors ligne, premium-gated. S'ils sont hors périmètre, dis-le explicitement sur les frames ou dans les commentaires dev-support.

Format de sortie

Quand on te demande d'aider à préparer un handoff :

1. Checklist de préparation — ce qui est en place, ce qui manque.
2. Vérification de la disponibilité Figma — alignement section-to-story, liaison des tokens, annotations de chaînes, états limites.
3. Mouvements Jira — les transitions de statut spécifiques et les liens Figma à appliquer (lier le champ « Design » de l'Epic, marquer les sections Ready for Dev, l'EM fait passer l'Epic). Renvoie à navigating-design-jira-process pour la chorégraphie canonique.

Termine toujours par le go/no-go explicite : ce handoff est-il vraiment prêt ?