Composants et variantes Figma : éviter les copies qui divergent

Pour éviter les copies divergentes dans Figma, définissez un composant de référence et les variations qui correspondent à de vrais usages. Commencez par un élément récurrent. Un système trop général, construit avant de connaître les besoins, peut devenir plus difficile à maintenir que les écrans qu'il devait simplifier.

Identifier ce qui est réellement commun

Rassemblez les occurrences d'un bouton, d'une carte ou d'un champ. Comparez leurs contenus, leurs dimensions et leurs états. Une ressemblance visuelle ne suffit pas si les comportements sont différents. À l'inverse, une couleur accidentellement différente peut signaler une copie à corriger.

Le guide des composants Figma décrit le principe de référence et d'instances. Utilisez cette structure pour conserver des règles partagées, puis documentez les différences autorisées au lieu de les laisser apparaître au fil des duplications.

Choisir des variantes compréhensibles

Nommez les propriétés selon le besoin : état, taille ou rôle, lorsque cette distinction est utile au projet. La documentation des variantes explique leur organisation. Évitez des noms comme « version finale 4 » qui ne disent rien à la personne qui réutilise le composant.

Ne multipliez pas les combinaisons uniquement parce que l'outil le permet. Identifiez les états réellement attendus et ceux qui seraient contradictoires. Une carte ne doit pas offrir une variation dont personne ne sait expliquer la fonction.

Exemple fictif : un bouton de réservation

Imaginons un bouton utilisé sur plusieurs fiches d'atelier. Le besoin comprend une action disponible, un traitement en cours et une action indisponible. Décrivez pour chaque état le texte, la présentation et le comportement attendu dans l'application.

Placez des instances dans trois écrans de test avec des libellés différents. Modifiez un espacement dans la référence, puis observez les instances. Repérez les exceptions qui ne suivent plus la règle et demandez si elles sont intentionnelles. Le test ne consiste pas à supprimer toute exception, mais à rendre leur raison explicite.

Ce cas fictif décrit une organisation de maquette. Un état « indisponible » dessiné dans Figma ne garantit pas que le bouton développé sera correctement annoncé ou empêchera réellement une action interdite.

Préparer les évolutions sans casser les écrans

Éprouvez les contenus longs avec l'exercice Auto Layout. Une référence unique peut propager une bonne correction comme une mauvaise contrainte. Vérifiez les écrans représentatifs avant de généraliser un changement.

Distinguez aussi l'organisation dans un fichier de la publication d'une bibliothèque partagée. Les droits, le mode de diffusion et les options du compte doivent être vérifiés au moment de la livraison. Ne supposez pas qu'une personne extérieure dispose des mêmes accès que le concepteur.

Lors de l'export des assets, identifiez les éléments à livrer comme fichiers et ceux qui doivent être construits en code. Une capture de tous les boutons ne remplace pas la description de leurs états et de leurs interactions.

Questions fréquentes

Faut-il transformer chaque élément en composant ?

Non. Priorisez les éléments réutilisés ou ceux dont la cohérence doit être contrôlée. Une abstraction sans usage réel ajoute des choix et des noms à maintenir.

Une instance modifiée est-elle forcément une erreur ?

Non. Elle peut répondre à une exception légitime. La question est de savoir si cette différence est voulue, documentée et compatible avec les prochaines modifications de la référence.

Les variantes prouvent-elles l'accessibilité du composant ?

Non. Elles peuvent préparer les états visuels. Les noms, relations, commandes et annonces doivent être vérifiés dans le composant développé avec les moyens appropriés.