Framer Designsystem: Was in Styles, Komponenten und DESIGN.md gehört

Eine Designsystem-Entscheidung kann in mehreren Teilen von Framer erscheinen. Die offizielle KI-Seite besagt, dass die Canvas Typografie, Komponenten, Breakpoints, Abstände, Farben, Effekte und Layouts verfeinern kann. Die Seite beschreibt außerdem KI-erstellte Code-Komponenten und Verbindungen zu externen Agenten. Über die gesamte Plattform hinweg teilen Design, Code, Zusammenarbeit und Publishing eine Arbeitsumgebung.

Diese Funktionen sagen Ihnen, was bearbeitet werden kann. Für sich allein entscheiden sie nicht, wo eine Regel ihren Ursprung haben sollte oder was gewinnt, wenn zwei Ebenen widersprüchliche Angaben machen. Das untenstehende Modell für Verantwortlichkeit und Priorisierung ist ein Arbeitsvertrag für Teams, kein Framer-eigener Standard.

Wählen Sie die Autorität basierend auf dem Umfang der Entscheidung. Eine Regel, die eine Änderung der Seite, des Agenten oder des Implementierungstools überdauern soll, gehört in eine portable Anleitung wie DESIGN.md. Implementieren Sie einen wiederverwendbaren Wert innerhalb des Framer-Projekts als gemeinsamen Style. Wenn eine Entscheidung eine wiederkehrende Einheit mit Struktur oder Verhalten definiert, legen Sie diese Implementierung in eine Komponente.

Ein Mapping ist keine zweite Instanz. Wenn beispielsweise in der DESIGN.md festgelegt ist, dass für gedämpften Text eine semantische Foreground-Rolle verwendet wird, kann ein Framer-Textstil diese Rolle unter einem projektspezifischen Namen implementieren. Die schriftliche Regel definiert die Bedeutung, während der Framer-Stil den lokalen, wiederverwendbaren Wert festlegt. Der Handoff-Record stellt die Verbindung zwischen beiden her.

Wenn zwei Layer widersprüchlich sind, sollte nicht einfach das akzeptiert werden, was zuletzt gerendert wurde. Verfolgen Sie die Entscheidung zurück zu ihrer erklärten Instanz, prüfen Sie, ob das nachgelagerte Mapping aktuell ist, und klassifizieren Sie jede Abweichung als genehmigte Ausnahme oder als Defekt.

1. Die maßgebliche Entscheidung und deren Geltungsbereich prüfen.
2. Das dokumentierte Mapping zum Framer-Stil, zur Komponente, zum Breakpoint oder zur Code-Komponente prüfen.
3. Prüfen, ob eine engere Ausnahme explizit erlaubt wurde.
4. Wenn die Instanz mehrdeutig ist, unterbrechen Sie die Änderung und weisen Sie diese zu, bevor weitere Oberflächen bearbeitet werden.
5. Zuerst den zuständigen Layer aktualisieren, dann die betroffenen Mappings aktualisieren und die beobachteten Belege dokumentieren.

Ein Agent benötigt mehr als nur eine Design-Anfrage. Geben Sie ihm ein kurzes Abnahmeprotokoll an, das die maßgebliche Entscheidung, die beabsichtigten Empfänger, unveränderte Oberflächen und die für die Prüfung erforderlichen Belege nennt.

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:

Der Record trennt die Absicht von der Beobachtung. Ein unter framer_styles gelistetes Ziel soll geändert werden. Die bloße Nennung ist kein Beleg dafür, dass das Mapping existiert oder dass das Ergebnis mit der Quelle übereinstimmt. Füllen Sie den Bereich für Belege erst nach der Inspektion aus.

Repräsentative Seiten sollten die tatsächliche Wiederverwendung prüfen. Wählen Sie mindestens eine Seite, auf der das Ziel prominent ist, und eine weitere, auf der es in einer anderen Komposition erscheint. Decken Sie bei Breakpoints die responsive Bedingung ab, die die Komponente am wahrscheinlichsten verändert, anstatt jede beliebige Canvas-Breite zu prüfen.

Framer beschreibt den Projektkontext, editierbare Styles und Assets, Verbindungen zu externen Agenten sowie von Agenten erstellte Änderungen. Mehr Kontext ist nicht automatisch besser. Ein eingegrenzter Kontext macht es einfacher zu erkennen, ob der Agent der beabsichtigten Regel gefolgt ist und ob nicht verwandte Arbeiten in den Branch gelangt sind.

1. 1

   Die Quellentscheidung auswählen

   Geben Sie den relevanten Abschnitt der DESIGN.md oder eine andere festgelegte Referenz an. Senden Sie nicht eine gesamte Bibliothek, wenn nur eine einzelne Farbrollle oder Komponentenregel relevant ist.

2. 2

   Die Framer-Empfänger benennen

   Identifizieren Sie die Shared Styles, Komponenten, Seiten, Layer und Breakpoints, von denen erwartet wird, dass sie die Entscheidung implementieren. Markieren Sie unbekannte Mappings als unbekannt, anstatt deren Namen zu erraten.

3. 3

   Die Non-Goals festlegen

   Listen Sie benachbarte Oberflächen auf, die der Agent nicht neu gestalten, umbenennen, restrukturieren oder neu stylen darf. Fügen Sie nicht verwandte Komponenten hinzu, die sich auf derselben Seite befinden.

4. 4

   Beobachtbare Abnahmekriterien definieren

   Beschreiben Sie, was ein Reviewer auf repräsentativen Seiten und kleinen Breakpoints sehen muss. Benennen Sie die nicht verwandten Oberflächen, die unverändert bleiben sollen.

5. 5

   Eine abgegrenzte Branch-Änderung öffnen

   Fordern Sie nur die benannte Änderung an. Wenn der Agent ein fehlendes Mapping oder eine mehrdeutige Instanz findet, muss er diese Lücke melden, anstatt ein neues System zu erfinden.

Ein gut aussehender Desktop-Canvas ist kein ausreichender Beleg. Überprüfen Sie die beabsichtigte Änderung an allen Stellen, an denen sie wiederverwendet wird, untersuchen Sie einen kleineren Breakpoint und prüfen Sie nicht verwandte, benannte Oberflächen auf Drift. Ziel ist die Rückverfolgbarkeit, nicht die Behauptung, dass ein einzelner Review die gesamte Seite zertifiziert.

1. 1

   Quelle und Mapping bestätigen

   Verifizieren Sie, dass das Branch-Briefing auf die aktuelle maßgebliche Entscheidung und die beabsichtigten Framer-Consumer verweist. Falls eines davon fehlt, überarbeiten Sie das Briefing, bevor Sie das Rendering beurteilen.

2. 2

   Die primäre Repräsentativseite untersuchen

   Prüfen Sie den beabsichtigten Style oder die Komponente auf der Seite, auf der die Wirkung am einfachsten zu erkennen ist. Dokumentieren Sie, was sich geändert hat, anstatt sich auf das Gedächtnis zu verlassen.

3. 3

   Einen weiteren realen Consumer untersuchen

   Öffnen Sie eine zweite Repräsentativseite oder Komposition, die denselben Style oder dieselbe Komponente verwendet. Eine Diskrepanz offenbart oft einen gelösten lokalen Wert oder eine duplizierte Komponente.

4. 4

   Die responsive Anpassung prüfen

   Untersuchen Sie den kleinsten benannten Breakpoint sowie jeden Breakpoint, an dem sich Anordnung, Sichtbarkeit oder Größe absichtlich ändern. Bestätigen Sie, dass die Basisregel weiterhin gilt, sofern das Briefing keine Anpassung erlaubt.

5. 5

   Nach nicht verwandtem Drift suchen

   Vergleichen Sie die unter must_remain_unchanged aufgeführten Oberflächen. Prüfen Sie die Style-Werte, die Komponentenstruktur, das Layout, den Inhalt und die Interaktionen, die für den Branch-Scope relevant sind.

6. 6

   Eine Entscheidung zuweisen

   „Pass“, wenn die beabsichtigten Mappings übereinstimmen und kein Drift im Scope verbleibt. „Revise“ bei einem korrigierbaren Fehler. „Block“, wenn die Zuständigkeit unklar ist, erforderliche Belege fehlen oder der Branch geschützte Non-Goals ändert.

Wenn eine Framer-Seite inkonsistent aussieht, erschwert ein weiterer allgemeiner Prompt oft die Interpretation der Belege. Gehen Sie die Layer in der Ownership-Reihenfolge durch und halten Sie beim ersten nicht unterstützten oder widersprüchlichen Mapping an.

1. Source-Entscheidung: Ist die beabsichtigte Rolle oder Regel explizit, aktuell und zugewiesen?
2. Gewählter Kontext: Hat der Agent die relevanten Regeln, Ziele, Ausnahmen und Non-Goals erhalten?
3. Shared Style Mapping: Verwendet das Zielelement den Framer-Style, der der Source-Rolle zugeordnet ist?
4. Komponentennutzung: Verwendet die Seite die Shared Component und die beabsichtigte Variante oder eine gelöste Kopie?
5. Breakpoint-Anpassung: Ändert ein responsive Override absichtlich den Wert oder die Struktur?
6. Generierter Code: Enthält eine Code-Komponente einen duplizierten Wert oder ein Verhalten, das im Widerspruch zur Quelle steht?
7. Override auf Seitenebene: Gibt es einen lokalen Wert, der die Shared-Implementierung überlagert?

Beheben Sie den Fehler im zuständigen Layer, nicht am ersten sichtbaren Symptom. Wenn eine Komponente den falschen Shared Style verwendet, korrigieren Sie das Komponenten-Mapping. Wenn die Source-Regel tatsächlich falsch ist, ändern Sie diese über den regulären Designsystem-Prozess des Teams und aktualisieren Sie anschließend jeden betroffenen Consumer. Schreiben Sie die Quelle nicht einfach um, nur um einen versehentlichen lokalen Wert zu legitimieren.

Das öffentliche Ambient Sage Kit dient als Beispiel, da seine Quellfakten einsehbar sind. Die veröffentlichte Seite enthält eine DESIGN.md, semantische Light- und Dark-Tokens, eine Palette aus 31 Farben sowie Typografie-Rollen. Für Überschriften und Fließtext wird Plus Jakarta Sans verwendet, während JetBrains Mono die Mono-Rolle übernimmt. Das Kit beschreibt zudem warme Sage-Oberflächen, tonale Karten und einen zurückhaltenden gelben Akzent.

Ein Handoff könnte die Hintergrund-Rolle des Kits einem Framer-Farbstil, die Body-Rolle einem Textstil mit Plus Jakarta Sans und die Tonal-Card-Vorgabe einer wiederverwendbaren Karten-Komponente zuordnen. Dies sind Beispiel-Mappings, keine Fakten über ein bestehendes Framer-Projekt. Der Projektbesitzer muss die tatsächlichen Namen wählen und die resultierenden Seiten verifizieren.

Die Verantwortlichkeitsmatrix und der Branch-Verlauf verbessern die Rückverfolgbarkeit. Sie ersetzen jedoch keine fachliche Prüfung und beweisen nicht, dass das Ergebnis gut ist. Eine konsistente Implementierung kann dennoch eine schlechte Design-Entscheidung konsistent anwenden.

• Die Barrierefreiheits-Konformität wird nicht zertifiziert, einschließlich Kontrast, Tastaturverhalten, Fokus-Behandlung, Semantik oder Unterstützung durch assistierende Technologien.
• Es wird nicht bewiesen, dass jede Seite, jeder Inhaltszustand, jede Spracheinstellung oder jeder Viewport responsive ist.
• Die Qualität des generierten Codes, das Laufzeitverhalten, die Performance, die Sicherheit oder die Wartbarkeit außerhalb der erklärten Änderung werden nicht bewertet.
• Es wird nicht bewiesen, dass ein Quell-Artefakt automatisch importiert oder mit visueller Parität reproduziert wurde.
• Dies stellt keine Freigabe zur Veröffentlichung dar. Der Branch muss weiterhin den regulären Review- und Release-Prozess des Projekts durchlaufen.

Führen Sie separate Belegketten, wenn das Risiko dies erfordert. Die Konformität zum Designsystem prüft, ob die Implementierung ihrer erklärten Quelle folgt. Barrierefreiheit, Resilienz, Verhalten und Produktionsreife erfordern eigene Prüfungen.

Wählen Sie eine bestehende Entscheidung, die auf mehr als einer Framer-Seite erscheint, wie z. B. gedämpften Navigationstext oder die Hintergrundfarbe einer Karte. Legen Sie die maßgebliche Quelle fest, dokumentieren Sie das exakte Framer-Style- oder Komponenten-Mapping, benennen Sie zwei repräsentative Seiten sowie einen kleinen Breakpoint und testen Sie dann eine abgegrenzte Branch-Änderung. Erweitern Sie das System erst, wenn die Dokumentation klar genug ist, damit ein anderer Reviewer sie reproduzieren kann.

• AI Website Builder für Designer & Teams | Framer: Framer dokumentiert KI-erstellte, editierbare Seiten und die Möglichkeit, Layouts, Typografie, Komponenten, Breakpoints, Abstände, Farben, Effekte und Code-Komponenten innerhalb des Projekts zu verfeinern.
• Framer: AI website builder for professional sites: Framer präsentiert Agenten, Design, Code, Kollaboration und Publishing als Teile derselben Website-Building-Plattform.
• Web Design Tools in Framer: Die Design-Übersicht beschreibt Layer-Styling, Grids, Stacks, responsive Bildschirmadaption, integrierte Schriftarten und Breakpoint-orientierte Kollaborationsflächen.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit enthält eine DESIGN.md, semantische Light- und Dark-Tokens, die Typografie Plus Jakarta Sans, JetBrains Mono sowie verschiedene Exportformate für Entwickler.
• So erstellen Sie eine DESIGN.md (und was sie ist): Identity Forge definiert die DESIGN.md als schriftliches Design-Briefing, das Intention, Design-Tokens, Typografie, Layout, die Gestaltung von Komponenten, Motive sowie explizite Nutzungsregeln für Coding-Agenten abdeckt.
• AI UI review checklist: test generated interfaces before you ship: Der Review-Leitfaden trennt Belege für Aufgaben, Designsystem, Resilienz und Barrierefreiheit und empfiehlt das Testen repräsentativer Zustände und kontrollierter Änderungen vor dem Release.

• AI Website Builder for Designers & Teams | Framer: Framer dokumentiert KI-erstellte, editierbare Seiten und die Möglichkeit, Layouts, Typografie, Komponenten, Breakpoints, Abstände, Farben, Effekte und Code-Komponenten innerhalb des Projekts zu verfeinern.
• Framer: AI website builder for professional sites: Framer präsentiert Agenten, Design, Code, Kollaboration und Publishing als Teile derselben Website-Building-Plattform.
• Web Design Tools in Framer: Die Design-Übersicht beschreibt Layer-Styling, Grids, Stacks, responsive Bildschirmadaption, integrierte Schriftarten und Breakpoint-orientierte Kollaborationsflächen.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit enthält eine DESIGN.md, semantische Light- und Dark-Tokens, die Typografie Plus Jakarta Sans, JetBrains Mono sowie verschiedene Exportformate für Entwickler.
• How to generate a DESIGN.md (and what it is): Identity Forge definiert DESIGN.md als schriftliches Design-Briefing, das Absicht, Tokens, Typografie, Layout, die Gestaltung von Komponenten, Motive sowie explizite Nutzungsregeln für Coding-Agenten abdeckt.
• AI UI review checklist: test generated interfaces before you ship: Der Review-Leitfaden trennt Belege für Aufgaben, Designsystem, Resilienz und Barrierefreiheit und empfiehlt das Testen repräsentativer Zustände und kontrollierter Änderungen vor dem Release.