Design system Framer : quoi mettre dans les styles, les composants et DESIGN.md

Une décision de design system peut apparaître dans plusieurs parties de Framer. Sa page officielle IA indique que le canvas peut affiner la typographie, les composants, les breakpoints, l'espacement, la couleur, les effets et les mises en page. La page décrit également les composants de code créés par IA et les connexions avec des agents externes. Sur l'ensemble de la plateforme, le design, le code, la collaboration et la publication partagent un seul environnement de travail.

Ces capacités indiquent ce qui peut être édité. À elles seules, elles ne déterminent pas d'où doit provenir une règle ni laquelle l'emporte lorsque deux couches divergent. Le modèle de responsabilité et de préséance ci-dessous est un contrat de travail pour les équipes, et non un standard natif de Framer.

Choisissez l'autorité en fonction de la portée de la décision. Une règle qui doit survivre à un changement de page, d'agent ou d'outil d'implémentation appartient à un guide portable tel que DESIGN.md. Implémentez une valeur réutilisable dans le projet Framer sous forme de style partagé. Lorsqu'une décision définit une unité récurrente avec une structure ou un comportement, placez cette implémentation dans un composant.

Un mapping n'est pas une seconde autorité. Par exemple, DESIGN.md peut spécifier que le texte atténué utilise un rôle de premier plan sémantique. Un style de texte Framer peut implémenter ce rôle sous un nom spécifique au projet. La règle écrite définit la signification, tandis que le style Framer définit la valeur réutilisable locale. Le document de transfert (handoff) assure la liaison entre les deux.

Lorsque deux couches divergent, ne validez pas celle qui est rendue en dernier. Remontez la décision jusqu'à son autorité déclarée, vérifiez si le mapping en aval est à jour, et classez toute déviation comme une exception approuvée ou un défaut.

1. Vérifiez la décision faisant autorité et son périmètre.
2. Vérifiez le mapping enregistré vers le style, le composant, le breakpoint ou le composant de code Framer.
3. Vérifiez si une exception plus restreinte a été explicitement autorisée.
4. Si l'autorité est ambiguë, suspendez la modification et attribuez-la avant de modifier d'autres surfaces.
5. Mettez d'abord à jour la couche propriétaire, puis mettez à jour les mappings affectés et enregistrez les preuves observées.

Un agent a besoin de plus qu'une simple demande de design. Fournissez-lui un court compte rendu d'acceptation nommant la décision faisant autorité, les consommateurs prévus, les surfaces inchangées et les preuves requises pour la révision.

change_id: nav-muted-text
objective: Align secondary navigation text with the declared muted-text role.

source:
  authority: DESIGN.md > Color roles > Muted content
  owner: Design systems owner
  decision: Secondary navigation labels use the muted foreground role.

targets:
  framer_styles:
    - Secondary / Navigation
  components:
    - Site Header
    - Footer Navigation
  representative_pages:
    - Home
    - Pricing
  breakpoints:
    - Desktop
    - Smallest supported phone width

allowed_exceptions:
  - Active navigation item uses the primary foreground role.

must_remain_unchanged:
  - Primary navigation labels
  - Button labels
  - CMS article body text
  - Header spacing and interaction behavior

agent_context:
  include:
    - Relevant DESIGN.md color-role section
    - Target text style
    - Site Header and Footer Navigation components
    - Home and Pricing pages
  exclude:
    - Unrelated pages, CMS content, and global layout changes

evidence:
  intended_change:
    - Before and after capture for each representative page and breakpoint
  unrelated_drift:
    - Comparison of named unchanged surfaces
  unresolved:
    - Record any mapping or behavior that could not be inspected

disposition: pass | revise | block
reviewer:
reviewed_at:

Le compte rendu sépare l'intention de l'observation. Une cible listée sous framer_styles est censée changer. Sa présence là n'est pas la preuve que le mapping existe ou que le résultat correspond à la source. Ne remplissez la section des preuves qu'après inspection.

Les pages représentatives doivent faire preuve d'une réelle réutilisation. Choisissez au moins une page où la cible est prédominante et une autre où elle apparaît dans une composition différente. Pour les breakpoints, couvrez la condition responsive la plus susceptible de modifier le composant au lieu de vérifier chaque largeur de canvas arbitraire.

Framer décrit le contexte du projet, les styles et assets modifiables, les connexions avec des agents externes et les modifications effectuées par l'agent. Plus de contexte n'est pas forcément synonyme de meilleure qualité. Un contexte délimité permet de voir plus facilement si l'agent a respecté la règle prévue et si des travaux non liés se sont glissés dans la branche.

1. 1

   Sélectionner la décision source

   Fournissez la section pertinente du fichier DESIGN.md ou toute autre autorité déclarée. N'envoyez pas une bibliothèque entière lorsque seul un rôle de couleur ou une règle de composant est concerné.

2. 2

   Nommer les consommateurs Framer

   Identifiez les styles partagés, composants, pages, calques et breakpoints censés implémenter la décision. Marquez les mappings inconnus comme inconnus au lieu de deviner leurs noms.

3. 3

   Énoncer les objectifs non visés

   Listez les surfaces proches que l'agent ne doit pas redessiner, renommer, restructurer ou restyler. Incluez les composants non liés qui partagent la page.

4. 4

   Définir l'acceptation observable

   Décrivez ce qu'un réviseur doit voir sur les pages représentatives et les petits breakpoints. Nommez les surfaces non liées qui doivent rester inchangées.

5. 5

   Ouvrir une modification de branche délimitée

   Ne demandez que la modification nommée. Si l'agent trouve un mapping manquant ou une autorité ambiguë, exigez qu'il signale l'écart au lieu d'inventer un nouveau système.

Un rendu visuel satisfaisant sur le canevas desktop ne constitue pas une preuve suffisante. Examinez la modification prévue partout où elle est réutilisée, inspectez un breakpoint plus petit et vérifiez l'absence de dérive sur des surfaces non liées. L'objectif est la traçabilité, et non de prétendre qu'une seule revue certifie l'ensemble du site.

1. 1

   Confirmer la source et le mapping

   Vérifiez que le brief de la branche pointe vers la décision faisant autorité et vers les consommateurs Framer visés. Si l'un ou l'autre manque, révisez le brief avant de juger le rendu.

2. 2

   Inspecter la page représentative principale

   Vérifiez le style ou le composant prévu sur la page où son effet est le plus visible. Notez ce qui a changé au lieu de vous fier à votre mémoire.

3. 3

   Inspecter un autre consommateur réel

   Ouvrez une seconde page ou composition représentative utilisant le même style ou composant. Un décalage révèle souvent une valeur locale détachée ou un composant dupliqué.

4. 4

   Vérifier l'adaptation responsive

   Inspectez le breakpoint nommé le plus petit ainsi que tout breakpoint où l'agencement, la visibilité ou la taille changent intentionnellement. Confirmez que la règle de base s'applique toujours, sauf si le brief autorise une adaptation.

5. 5

   Rechercher des dérives non liées

   Comparez les surfaces listées sous must_remain_unchanged. Vérifiez les valeurs de style, la structure des composants, la mise en page, le contenu et les interactions pertinentes pour le périmètre de la branche.

6. 6

   Attribuer une décision

   Validez (Pass) lorsque les mappings prévus correspondent et qu'aucune dérive n'est présente dans le périmètre. Demandez une révision pour un décalage corrigeable. Bloquez (Block) lorsque l'autorité est ambiguë, que les preuves requises sont indisponibles ou que la branche modifie des éléments hors périmètre protégés.

Lorsqu'une page Framer semble incohérente, l'utilisation d'un prompt trop large rend souvent les preuves plus difficiles à interpréter. Parcourez les couches selon l'ordre de propriété et arrêtez-vous au premier mapping non supporté ou contradictoire.

1. Décision source : le rôle ou la règle prévus sont-ils explicites, actuels et définis ?
2. Contexte sélectionné : l'agent a-t-il reçu la règle, les cibles, les exceptions et les non-objectifs pertinents ?
3. Mapping de style partagé : l'élément cible utilise-t-il le style Framer mappé au rôle source ?
4. Utilisation du composant : la page utilise-t-elle le composant partagé et la variante prévue, ou une copie détachée ?
5. Adaptation du breakpoint : un override responsive modifie-t-il intentionnellement la valeur ou la structure ?
6. Code généré : un composant de code contient-il une valeur ou un comportement dupliqué qui entre en conflit avec la source ?
7. Override au niveau de la page : existe-t-il une valeur locale masquant l'implémentation partagée ?

Corrigez la couche propriétaire, et non le premier symptôme visible. Si un composant utilise le mauvais style partagé, corrigez le mapping du composant. Si la règle source est réellement erronée, modifiez-la via le processus habituel du design system de l'équipe, puis mettez à jour chaque consommateur affecté. Ne réécrivez pas la source simplement pour légitimer une valeur locale accidentelle.

Le kit public Ambient Sage sert d'exemple car ses données sources sont inspectables. Sa page publiée propose un fichier DESIGN.md, des design tokens sémantiques pour les modes clair et sombre, une palette de 31 couleurs et des rôles typographiques. Plus Jakarta Sans est utilisé pour les titres et le corps de texte, tandis que JetBrains Mono assure le rôle mono. Le kit décrit également des surfaces sage chaud, des cartes tonales et un accent jaune discret.

Un handoff pourrait mapper le rôle d'arrière-plan du kit à un style de couleur Framer, son rôle de corps de texte à un style de texte utilisant Plus Jakarta Sans, et ses directives de tonalité de carte à un composant de carte réutilisable. Ce sont des exemples de mappages, et non des faits concernant un projet Framer existant. Le propriétaire du projet doit choisir les noms réels et vérifier les pages résultantes.

La carte des responsabilités et l'historique de la branche améliorent la traçabilité. Ils ne remplacent pas une revue spécialisée et ne prouvent pas que le résultat est optimal. Une implémentation cohérente peut tout de même appliquer systématiquement une mauvaise décision de design.

• Cela ne certifie pas la conformité à l'accessibilité, y compris le contraste, le comportement du clavier, la gestion du focus, la sémantique ou le support des technologies d'assistance.
• Cela ne prouve pas que chaque page, état de contenu, locale ou viewport est responsive.
• Cela n'évalue pas la qualité du code généré, le comportement au runtime, la performance, la sécurité ou la maintenabilité en dehors du changement déclaré.
• Cela ne prouve pas qu'un artefact source a été importé automatiquement ou reproduit avec une parité visuelle.
• Cela n'autorise pas la publication. La branche doit toujours suivre le processus normal de revue et de mise en production du projet.

Maintenez des pistes de preuves distinctes lorsque le risque l'exige. La conformité au design system vérifie si l'implémentation suit sa source déclarée. L'accessibilité, la résilience, le comportement et l'aptitude à la production nécessitent leurs propres vérifications.

Choisissez une décision existante qui apparaît sur plus d'une page Framer, comme le texte de navigation atténué ou la couleur de surface d'une carte. Déclarez sa source faisant autorité, enregistrez le mappage exact du style ou du composant Framer, nommez deux pages représentatives et un petit breakpoint, puis testez un changement de branche délimité. N'étendez le système que lorsque l'enregistrement est suffisamment clair pour qu'un autre réviseur puisse le reproduire.

• AI Website Builder for Designers & Teams | Framer : Framer documente les pages modifiables créées par IA et la possibilité d'affiner les mises en page, la typographie, les composants, les breakpoints, l'espacement, les couleurs, les effets et les composants de code au sein du projet.
• Framer: AI website builder for professional sites : Framer présente les agents, le design, le code, la collaboration et la publication comme faisant partie d'une même plateforme de création de sites web.
• Web Design Tools in Framer : L'aperçu du design décrit le stylisage des calques, les grilles, les stacks, l'adaptation responsive des écrans, les polices intégrées et les surfaces de collaboration orientées breakpoints.
• Kit de design Ambient Sage : le kit public Ambient Sage fournit un fichier DESIGN.md, des design tokens sémantiques pour les modes clair et sombre, la typographie Plus Jakarta Sans, JetBrains Mono, ainsi que plusieurs formats d'exportation pour les développeurs.
• Comment générer un DESIGN.md (et à quoi il sert) : Identity Forge définit le DESIGN.md comme un brief de design écrit couvrant l'intention, les design tokens, la typographie, la mise en page, le traitement des composants, les motifs et les règles d'utilisation explicites pour les agents de code.
• AI UI review checklist: test generated interfaces before you ship : Le guide de revue sépare les preuves de tâche, de design system, de résilience et d'accessibilité, et recommande de tester des états représentatifs et des changements contrôlés avant la mise en production.

• AI Website Builder for Designers & Teams | Framer: Framer documente les pages modifiables créées par IA et la possibilité d'affiner les mises en page, la typographie, les composants, les breakpoints, l'espacement, les couleurs, les effets et les composants de code au sein du projet.
• Framer: AI website builder for professional sites: Framer présente les agents, le design, le code, la collaboration et la publication comme faisant partie d'une même plateforme de création de sites web.
• Web Design Tools in Framer: L'aperçu du design décrit le stylisage des calques, les grilles, les stacks, l'adaptation responsive des écrans, les polices intégrées et les surfaces de collaboration orientées breakpoints.
• Ambient Sage Design Kit: Le kit public Ambient Sage fournit un fichier DESIGN.md, des design tokens sémantiques pour les modes clair et sombre, la typographie Plus Jakarta Sans, JetBrains Mono, ainsi que plusieurs formats d'exportation pour les développeurs.
• How to generate a DESIGN.md (and what it is): Identity Forge définit le fichier DESIGN.md comme un brief de design écrit détaillant l'intention, les design tokens, la typographie, la mise en page, le traitement des composants, les motifs et les règles d'utilisation explicites pour les agents de code.
• AI UI review checklist: test generated interfaces before you ship: Le guide de revue sépare les preuves de tâche, de design system, de résilience et d'accessibilité, et recommande de tester des états représentatifs et des changements contrôlés avant la mise en production.