Framer Designsystem: Styles vs. DESIGN.md

Eine Entscheidung im Designsystem kann an mehreren Stellen in Framer erscheinen. Die offizielle AI-Seite gibt an, dass das Canvas Typografie, Komponenten, Breakpoints, Abstände, Farben, Effekte und Layouts verfeinern kann. Die Seite beschreibt zudem AI-generierte Code-Komponenten und Verbindungen zu externen Agenten. Über die gesamte Plattform hinweg teilen Design, Code, Kollaboration und Publishing eine gemeinsame Arbeitsumgebung.

Diese Funktionen zeigen auf, was bearbeitet werden kann. Alleine entscheiden sie jedoch nicht, wo eine Regel ihren Ursprung haben sollte oder was Vorrang hat, wenn zwei Ebenen widersprüchlich sind. Das folgende Modell für Verantwortlichkeit und Priorität ist ein Arbeitsvertrag für Teams, kein nativer Framer-Standard.

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

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

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 Überprüfung erforderlichen Belege benennt.

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 Auflistung 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 abgegrenzter Kontext macht es einfacher zu erkennen, ob der Agent der beabsichtigten Regel gefolgt ist und ob nicht zusammenhängende Arbeiten in den Branch gelangt sind.

1. 1

   Die Quellentscheidung auswählen

   Geben Sie den relevanten Abschnitt der DESIGN.md oder eine andere erklärte Instanz an. Senden Sie nicht eine gesamte Library, wenn nur eine einzige Farbroom 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 zusammenhängende 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 zusammenhängenden 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 aussagekräftiger Beleg. Überprüfen Sie die beabsichtigte Änderung überall dort, wo 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-Brief auf die aktuelle maßgebliche Entscheidung und die beabsichtigten Framer-Consumer verweist. Falls eines davon fehlt, überarbeiten Sie das Brief, bevor Sie das Rendering beurteilen.

2. 2

   Die primäre Repräsentativseite untersuchen

   Prüfen Sie den beabsichtigten Stil 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 Stil oder dieselbe Komponente verwendet. Eine Diskrepanz offenbart oft einen losgelö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 Brief 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 Stilwerte, 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 Mismatch. „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 Coding-Agent die relevanten Regeln, Ziele, Ausnahmen und Non-Goals erhalten?
3. Shared Style Mapping: Verwendet das Zielelement den Framer-Stil, der der Source-Rolle zugeordnet ist?
4. Komponentennutzung: Verwendet die Seite die Shared Component und die beabsichtigte Variante oder eine losgelö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 dann jeden betroffenen Consumer. Schreiben Sie die Quelle nicht einfach um, nur um einen versehentlichen lokalen Wert zu legitimieren.

Das öffentliche Ambient Sage Kit eignet sich als Beispiel, da seine Source-Fakten einsehbar sind. Die veröffentlichte Seite bietet eine DESIGN.md, semantische Light- und Dark-Tokens, eine Palette aus 31 Farben und Typografie-Rollen. Plus Jakarta Sans wird für Überschriften und Fließtext verwendet, während JetBrains Mono die Mono-Rolle ausfüllt. 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-Nachweis verbessern die Rückverfolgbarkeit. Sie ersetzen keine fachliche Prüfung und beweisen nicht, dass das Ergebnis gut ist. Eine konsistente Implementierung kann dennoch eine schlechte Design-Entscheidung konsistent anwenden.

• Die Barrierefreiheitskonformität wird nicht zertifiziert, einschließlich Kontrast, Tastaturverhalten, Fokus-Behandlung, Semantik oder Unterstützung durch assistive Technologien.
• Es wird nicht bewiesen, dass jede Seite, jeder Inhaltszustand, jede Lokalisierung 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.
• Die Veröffentlichung wird dadurch nicht autorisiert. Der Branch muss weiterhin den regulären Review- und Release-Prozess des Projekts durchlaufen.

Führen 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 aus, die auf mehr als einer Framer-Seite erscheint, wie z. B. gedämpfter Navigationstext oder die Farbe einer Kartenoberfläche. 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 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 Agents, Design, Code, Kollaboration und Publishing als Teile derselben Website-Building-Plattform.
• Web Design Tools in Framer: Die erfasste Design-Übersicht beschreibt Layer-Styling, Grids, Stacks, responsive Bildschirmadaptation, integrierte Schriftarten und Breakpoint-orientierte Kollaborationsflächen.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit bietet eine DESIGN.md, semantische Light- und Dark-Tokens, Plus Jakarta Sans Typografie, JetBrains Mono und mehrere Exportformate für Entwickler.
• How to generate a DESIGN.md (and what it is): Identity Forge definiert DESIGN.md als ein schriftliches Design-Briefing, das Intention, Tokens, Typografie, Layout, Komponenten-Behandlungen, Motive und explizite Nutzungsregeln für Coding-Agents 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 Agents, Design, Code, Kollaboration und Publishing als Teile derselben Website-Building-Plattform.
• Web Design Tools in Framer: Die erfasste Design-Übersicht beschreibt Layer-Styling, Grids, Stacks, responsive Bildschirmadaptation, integrierte Schriftarten und Breakpoint-orientierte Kollaborationsflächen.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit bietet eine DESIGN.md, semantische Light- und Dark-Tokens, Plus Jakarta Sans Typografie, JetBrains Mono und mehrere Exportformate für Entwickler.
• How to generate a DESIGN.md (and what it is): Identity Forge definiert DESIGN.md als ein schriftliches Design-Briefing, das Intention, Tokens, Typografie, Layout, Komponenten-Behandlungen, Motive und explizite Nutzungsregeln für Coding-Agents 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.