Faire évoluer les composants du système de design

Cette skill ancre le travail de Component Library dans deux pages de gouvernance Bitwarden : Creating new design patterns et Modifying an existing Design System component. Lisez les pages canoniques via get_confluence_page avant de proposer quelque chose de réel — elles évoluent plus vite que cette skill, et elles renvoient à des fichiers Figma template et des processus d'engineering référencés ci-dessous. Les conventions Figma (ordre des propriétés, nommage) se trouvent dans references/figma-conventions.md.

Les deux chemins

Il y a deux flux de gouvernance. Ils partagent un début mais divergent.

• Créer un nouveau pattern. Un pattern qui n'existe pas encore. Le chemin se divise à « s'agit-il d'un Core Component, ou d'une Recipe/Snowflake ? » en fonction des cas d'usage et de la complexité.
• Modifier un composant existant. Un pattern qui existe déjà. Passe toujours par l'équipe UI Foundation car les instances dans le produit sont affectées.

La skill parcourt les deux. Confirmez lequel s'applique avant de recommander des étapes — ils ont des points de contrôle différents.

Étape 1 : Chercher d'abord, puis proposer

Avant l'un ou l'autre chemin, vérifiez si le pattern existe déjà. Le plus courant faux positif de « nous avons besoin d'un nouveau composant » est « ce composant existe déjà dans la library et le designer ne l'avait pas trouvé ».

Utilisez search_design_system et get_libraries de using-figma. Si une correspondance proche est trouvée, la question devient de savoir s'il faut l'utiliser tel quel, le modifier (chemin B), ou proposer une nouvelle variante en dessous. Si aucune correspondance, continuez.

Étape 2 : Identifier le besoin avec l'équipe

Pour les deux chemins, l'équipe design s'aligne d'abord — avant que l'engineering soit impliquée. D'après les pages Confluence :

• Le designer identifie le besoin et crée un brouillon du nouveau pattern ou du pattern modifié dans un fichier de feature.
• Le designer partage avec l'équipe design — itération collective ou brouillon indépendant suivi d'une critique d'équipe, selon les délais.
• L'équipe design examine selon trois ou quatre questions, selon le chemin :

Pour un nouveau pattern :

• Quels patterns existants ont été envisagés ? Pourquoi ne fonctionnent-ils pas ?
• Quelle valeur le nouveau pattern apporte-t-il ?
• Suit-il les directives existantes de design / marque ?
• Quels sont les autres cas d'usage ? Peut-il être utilisé à plusieurs endroits ?

Pour une modification :

• Améliore-t-il l'attrait visuel ?
• Élargit-il les cas d'usage du composant ?
• Est-il en ligne avec les autres patterns UI ?
• Comment affectera-t-il les instances du composant dans le produit ?
• Quels autres composants ou patterns pourraient être affectés ?

L'équipe s'aligne sur la progression avant que la proposition n'aille plus loin. Il y a un template Figma pour la discussion de nouveau pattern lié depuis la page Creating-new-design-patterns ; présentez-le quand le proposant n'a pas sa propre structure de discussion.

Étape 3 (nouveaux patterns uniquement) : Core vs. Recipe/Snowflake

Cette décision est prise avec l'équipe UI Foundation — jamais unilatéralement par le designer proposant.

• Candidat Core Component Library. Nombreux cas d'usage, ou trop complexe pour qu'une seule équipe de feature le maintienne. Devient un composant library de première classe appartenant à UI Foundation.
• Recipe / Snowflake. Peu de cas d'usage, ou spécifique à une surface de feature. Appartient à l'équipe de feature qui l'a construit. Toujours ajouté à la library Figma pour que les autres designers puissent le trouver.

Planifiez la conversation avec UI Foundation. Passez en revue les cas d'usage. Déférez à leur appel sur la propriété. La page Confluence référence le côté engineering à Creating a New Component — lisez cette page quand le chemin Core est pris.

Étape 4 : Le construire dans la library Figma

Le côté Figma du processus est opiniâtre. Les conventions — ordre des propriétés, nommage, états requis, pattern de documentation — se trouvent dans references/figma-conventions.md. Les mouvements de haut niveau :

• Ouvrez le fichier Figma Tailwind Component Library.
• Créez une nouvelle branche nommée d'après le composant / pattern.
• Ajoutez le nouveau pattern UI (ou modifié) comme Figma Component, sur une page dédiée aux nouveaux composants ou sur la page du composant existant pour les modifications.
• Pour les composants interactifs, assurez au minimum : default, hover, focus, active (le cas échéant), disabled (le cas échéant).
• Nommez les propriétés Figma selon les CL API design docs et les patterns de propriété Figma existants. L'ordre des propriétés importe — voir references/figma-conventions.md.
• Créez une frame de documentation de composant à côté du composant avec les notes d'usage, de comportement, de variantes, et d'accessibilité. La convention est de copier et adapter la documentation d'un composant existant plutôt que de construire à partir de zéro.
• Pour les modifications, laissez un commentaire Figma sur chaque composant modifié notant ce qui a changé.

Étape 5 : Points de contrôle

• Nouveaux patterns. Envoyez la branche à l'équipe Design pour révision.
• Modifications. Envoyez la branche à l'équipe Design ET révisez lors d'une synchronisation d'équipe. Au moins 2 autres designers doivent approuver avant fusion.
• Révisez les changements avec l'équipe d'engineering UI Foundation lors d'une synchronisation d'équipe.
• Créez un issue Jira sur le tableau Component Library s'il n'a pas déjà été créé. Priorisez avec l'équipe d'engineering UI Foundation à la prochaine synchronisation.

Étape 6 : Synchronisation de fusion — Figma vs. code

La défaut est attendre de fusionner la branche Figma jusqu'à ce que l'engineering ait mis à jour le code pour que les designers ne voient pas l'UI dans Figma qui n'existe pas encore dans le produit. Mais il y a des exceptions :

• Les designers ont besoin des changements maintenant. Ajoutez un badge d'avertissement à la documentation du composant dans Figma notant l'état de l'engineering, fusionnez la branche Figma, et envoyez une mise à jour aux équipes d'engineering dans #team-eng-ui-foundation.
• La maintenance de branche est trop lourde. La même exception s'applique — fusionnez avec un avertissement et annoncez.

Adhérez à l'ordre discipliné par défaut. Utilisez l'exception avec parcimonie.

Composing avec d'autres skills

• using-figma. search_design_system et get_libraries pour la recherche pré-proposition ; get_metadata et get_variable_defs pour inspecter les composants existants ; les outils Code Connect (get_code_connect_map, add_code_connect_map, get_context_for_code_connect) pour la liaison design-to-code lors de la promotion d'un pattern vers un Core Component.
• facilitating-design-critique. L'étape d'alignement de l'équipe design à l'étape 2 est une session de critique, pas un message ponctuel. Quand le proposant a besoin d'aide pour la structurer, dispatchez dans la skill de facilitation de critique.
• navigating-design-jira-process. Le tableau Component Library Jira vit dans le flux Jira Product et Design plus large. Quand la proposition génère du travail d'engineering, dispatchez dans la skill Jira-process pour les bons mouvements d'état.

Pièges courants

• Sauter la recherche pré-proposition. search_design_system d'abord. Toujours.
• Appel Core/Recipe unilatéral du designer. La conversation UI Foundation est requise pour cette décision. Ne pré-décidez pas.
• Noms de propriétés qui ne correspondent pas aux conventions CL API. Le nommage incohérent casse la utilisabilité de la library entre l'équipe. Lisez le document de design CL API plutôt que d'improviser.
• Sauter le badge d'avertissement sur les fusions précoces. Quand le chemin d'exception est pris, le badge d'avertissement dans Figma plus le message #team-eng-ui-foundation est requis, pas optionnel.
• Fusionner les changements Figma en avant de l'engineering sans communication. Les designers en aval voient l'UI qui n'existe pas dans le produit et construisent dessus.

Format de sortie

Quand on vous demande d'aider à proposer un pattern ou de modifier un composant :

1. Chemin — nouveau pattern ou modification.
2. Résultats de recherche — ce qui existe déjà dans la library qui est adjacent ou chevauche.
3. Plan d'alignement de l'équipe design — ce qu'il faut apporter à la critique, quelles questions l'équipe devrait peser.
4. Appel Core vs. Recipe (nouveaux patterns uniquement) — le cadrage de la conversation UI Foundation.
5. Plan Figma — nom de branche, placement de page, états requis, ordre des propriétés, frame de docs.
6. Chemin de révision — approbations de designer requises, révision UI Foundation, issue Jira du Component Library.
7. Synchronisation de fusion — défaut ou exception, avec les étapes de badge d'avertissement et de communication si exception.