Design system Framer : styles vs 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 l'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 vous indiquent ce qui peut être édité. À elles seules, elles ne décident pas de l'origine d'une règle ni de laquelle prime 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étient le sens, tandis que le style Framer détient la valeur réutilisable locale. Le registre de transfert (handoff) les relie.

Lorsque deux couches divergent, n'acceptez pas simplement celle qui s'affiche en dernier. Remontez la décision jusqu'à son autorité déclarée, vérifiez si le mapping en aval est à jour et classifiez tout écart comme une exception approuvée ou un défaut.

1. Vérifier la décision faisant autorité et son périmètre.
2. Vérifier le mapping enregistré vers le style Framer, le composant, le breakpoint ou le composant de code.
3. Vérifier si une exception plus restreinte a été explicitement autorisée.
4. Si l'autorité est ambiguë, interrompez la modification et assignez-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 registre d'acceptation qui nomme la décision faisant autorité, les consommateurs visés, les surfaces inchangées et les preuves requises pour la revue.

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 registre sépare l'intention de l'observation. Une cible listée sous framer_styles est censée changer. Sa présence ici 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 mettre en œuvre une réutilisation réelle. Choisissez au moins une page où la cible est proéminente 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 plutôt que de vérifier chaque largeur de canevas arbitraire.

Framer décrit le contexte du projet, les styles et assets éditables, les connexions avec des agents externes et les modifications apportées par les agents. Plus de contexte n'est pas automatiquement préférable. Un contexte délimité permet de voir plus facilement si l'agent a suivi 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

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

2. 2

   Nommer les consommateurs Framer

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

3. 3

   Définir les non-objectifs

   Lister les surfaces adjacentes que l'agent ne doit ni redessiner, ni renommer, ni restructurer, ni restyliser. Incluez les composants non liés qui partagent la même page.

4. 4

   Définir l'acceptation observable

   Décrire 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

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

Un canevas desktop esthétique ne constitue pas une preuve solide. 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 des deux 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 une dérive non liée

   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 exclus (non-goals).

Lorsqu'une page Framer semble incohérente, l'utilisation d'un prompt trop large rend souvent les preuves plus difficiles à interpréter. Parcourez les calques 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évue est-il explicite, actuel et défini ?
2. Contexte sélectionné : l'agent a-t-il reçu la règle, les cibles, les exceptions et les non-goals 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 le calque 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 faits sources sont inspectables. Sa page publiée fournit un DESIGN.md, des design tokens sémantiques (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 remplit 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 cartographie des responsabilités et l'historique des branches 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 la préparation à 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 relecteur 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.
• Ambient Sage Design Kit : Le kit public Ambient Sage fournit un fichier DESIGN.md, des design tokens sémantiques (clair et sombre), la typographie Plus Jakarta Sans, JetBrains Mono et plusieurs formats d'exportation pour les développeurs.
• How to generate a DESIGN.md (and what it is) : Identity Forge définit 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 des 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 (clair et sombre), la typographie Plus Jakarta Sans, JetBrains Mono et plusieurs formats d'exportation pour les développeurs.
• How to generate a DESIGN.md (and what it is): Identity Forge définit 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 des 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.