Navigation du processus Jira Produit et Design

Cette skill ancre les mouvements Jira dans la pratique actuelle de l'équipe design pour s'intégrer au workflow Jira de l'engineering. L'objectif : maintenir les décisions de design visibles aux côtés du travail d'engineering — sans gérer un tracker design parallèle. Les designs sont attachés directement aux tickets d'engineering auxquels ils appartiennent, et tout ce qui est substantiel (itérations de critique 30/60/90, copywriting, annotations) vit dans Figma.

Une note sur les noms de statut ci-dessous. Les libellés de statut Jira apparaissent ici avec la même casse que Jira les utilise — IN DESIGN, IN PROGRESS, DONE, DESIGN NEEDED, Ready for Dev. Copiez-les verbatim lors de la transition des tickets.

La règle structurelle

Les designs sont attachés directement aux tickets. Le fichier Figma vit dans le champ "Design" de l'Epic d'engineering (ou, pour les stories d'engineering ponctuelles, dans le champ "Design" de la story). Il n'y a pas de projet design parallèle, pas de Kanban design parallèle, et pas de tâches design par stage.

C'est l'insight de l'équipe design-Jira en une phrase. Tout le reste est une chorégraphie autour de cette règle.

Flux piloté par Epic

Configuration initiale

• Un PM crée au moins un Epic pour accompagner chaque document Product Initiative sur lequel il travaille.
• Le PM assigne l'Epic au designer désigné.

In Design

• Le designer (ou PM) déplace l'Epic vers IN DESIGN.
• Le designer exécute la cadence de critique 30/60/90 dans Figma — pas de tâches Jira séparées par stage. Les itérations de stage, les matériaux attachés (présentations aux stakeholders, recherche), et les retours transversaux vivent tous dans le fichier Figma aux côtés du travail.

Design Done

• Dans Figma, groupez les designs finaux sur une seule page avec des Sections nommées pour chaque surface au niveau story.
• Le designer lie le fichier Figma dans le champ "Design" de l'Epic.
• Le designer marque les sections Figma comme "Ready for Dev".
• L'EM déplace l'Epic vers Ready for Dev pour signaler que l'engineering peut reprendre le travail. (Certaines équipes ont une automatisation qui gère cela ; traitez-le comme la responsabilité de l'EM pour le moment.)

Décomposition technique d'Engineering

• Quand l'engineering crée des stories lors de la décomposition technique, le designer + PM + l'engineer faisant la décomposition examinent ensemble les stories.
• Pour chaque story, assurez-vous que la bonne section Figma est liée et que le contenu de la section concerne uniquement cette story. Correspondance un-à-un.

In Progress (et support dev)

• Le PM ou l'EM déplace l'Epic vers IN PROGRESS quand le développement commence.
• Le PM/EM crée une tâche de support dev intitulée [project name] - dev support, l'assigne au designer du projet, et la lie comme "relates to" à toutes les stories d'engineering ayant besoin de support design. (Cette convention persiste pour le moment même que d'autres travaux de tâches design séparées ont été retirés.)
• La tâche permet au designer de savoir quand son projet entre en développement et représente le support divers nécessaire tout au long.
• Quand la dernière tâche d'engineering est terminée, la tâche de support dev est aussi marquée DONE.

Stories d'engineering ponctuelles

Certaines stories ne sont pas liées à un epic — courant à l'équipe UI Foundation. Le flux est plus court :

• Une story d'engineering est créée en dehors d'un epic ; le PM ou l'EM réalise qu'un support design est nécessaire. (Ou : un designer travaillant sur une amélioration de composant pour UIF crée la story lui-même.)
• Le PM ou l'EM déplace la story vers DESIGN NEEDED et l'assigne au designer de l'équipe de feature.
• Le designer fait le travail de design dans Figma. Aucune tâche design séparée n'est créée.
• Quand le design est complet, le designer :
  1. Lie le fichier Figma au champ "Design" de la story.
  2. Se désassigne de la story.
  3. Ajoute un commentaire au ticket notant que le design est prêt à être repris.

Les trois étapes de clôture — lier, désassigner, commenter — sont explicites. En sauter une laisse la story coincée dans la queue de quelqu'un ou visible-mais-non-découvrable.

Composition avec d'autres skills

• preparing-design-handoff. Les transitions à la fin de In Design (Figma lié, sections marquées Ready for Dev, EM déplace Epic) sont le côté pré-handoff du processus de handoff. La skill de handoff est la gate / checklist ; cette skill est le cycle de vie canonique.
• evolving-design-system-components. Le travail de Component Library génère des issues Jira sur le board Component Library. Elles suivent la même règle (designs attachés aux tickets), mais les recipes appartenant à l'équipe de feature génèrent des stories dans le projet de l'équipe de feature plutôt que dans le projet Component Library. Surface la différence explicitement au designer.

Erreurs courantes à attraper

• Oublier de marquer les sections Figma "Ready for Dev". L'engineering ne peut pas trouver ce qui est final. C'est une partie de Design Done, pas optionnel.
• Sections non alignées aux stories. Quand l'engineering crée des stories, chaque story doit mapper à une section Figma dont le contenu est uniquement cette story. Un désalignement crée de l'ambiguïté au moment de la review.
• Story d'engineering ponctuelle laissée inachevée du côté design. Les trois étapes de clôture doivent se produire — lier Figma au champ "Design" de la story, se désassigner, commenter que le design est prêt. Manquer l'une d'elles laisse le ticket dans un état ambigü.
• PM créant la tâche de support dev trop tard ou pas du tout. Quand le support dev n'est pas visible sur l'Epic, les demandes de support dev arrivent au designer sans avertissement. Surface ce gap lors de la review de l'état Jira d'un projet.

Format de sortie

Quand on vous demande de mettre en place ou de déplacer du travail dans le processus Jira :

1. Forme du projet — s'agit-il d'un projet piloté par epic ou d'une story d'engineering ponctuelle ?
2. État actuel — quelles entités Jira existent (Epic, story, tâche de support dev) et leurs statuts actuels.
3. Mouvements à faire — les transitions de statut spécifiques et les liens Figma à appliquer, nommés par responsabilité (designer, PM, EM).
4. Liens Figma — quoi attacher où (champ "Design" Epic, champ "Design" story).
5. Watch-outs — les erreurs courantes ci-dessus qui s'appliquent à ce projet spécifique.