Google Stitch Designsystem-Handoff

Google beschreibt DESIGN.md als einen portablen Weg zum Import und Export von Designregeln. Es kann gemeinsame Entscheidungen über Farbrollen, Typografie, Spacing, Layout-Prinzipien, die Behandlung von Komponenten und visuelle Constraints enthalten. Diese Portabilität ist entscheidend: Die Regeln können zwischen Projekten und Plattformen wandern, anstatt nur in einer einzigen Konversation zu existieren.

Die Datei hat eine engere Aufgabe: Sie legt Regeln fest. Sie beweist nicht, dass jeder generierte Screen diesen gefolgt ist, dass ein Prompt sie nicht überschrieben hat oder dass der exportierte Code sie beibehalten hat. Ebenso zertifiziert sie weder die Vollständigkeit von Aufgaben, Barrierefreiheit, responsives Verhalten, die Qualität des generierten Codes noch die Produktionsreife. Diese erfordern separate Prüfungen.

Stitch entwickelt sich schnell, und Suchergebnisse vermischen Produktdokumentationen, Tutorials und Nutzerberichte. Kennzeichnen Sie jede Workflow-Behauptung nach ihrer Belegklasse. So wird verhindert, dass ein selbstbewusst geschriebenes Tutorial oder ein isolierter Fehlerbericht versehentlich zum Produktversprechen wird.

Verwenden Sie für jede für den Handoff relevante Funktion zunächst die aktuelle First-Party-Dokumentation, um die Verfügbarkeit festzustellen, und Ihre eigenen aufgezeichneten Beobachtungen, um das Verhalten zu definieren. Behandeln Sie Drittanbieter-Anleitungen als vorläufig, bis Sie diese reproduziert haben. Community-Berichte sind Testideen, keine Prognosen.

Konsistenz wird kostspielig, wenn mehrere Artefakte gleichzeitig autoritativ wirken. Eine Referenzseite schlägt eine Typografie-Skala vor, DESIGN.md nennt eine andere, ein generierter Screen führt eine dritte ein und jemand korrigiert den exportierten Code manuell. Ohne ein Protokoll über die Priorität gewinnt tendenziell das zuletzt sichtbare Ergebnis, selbst wenn dies nicht korrekt ist.

Erfassen Sie für jeden ungelösten Konflikt die konkurrierenden Werte, die zuständige Ebene, die entscheidende Person und die benötigten Belege. Lösen Sie den Konflikt nicht, indem Sie einfach den Wert kopieren, der in der neuesten Generation erschienen ist.

Bevor Sie Stitch anweisen, weitere Screens zu generieren, halten Sie die Entscheidungen schriftlich fest, die stabil bleiben müssen. Verwenden Sie beobachtbare Sprache. „Konsistent halten“ ist nicht testbar. „Die gleiche primäre Navigationsstruktur auf den Screens für Konto, Abrechnung und Analysen verwenden“ hingegen schon.

• Navigation: Struktur, Platzierung, ausgewählter Zustand, Einklappverhalten und zulässige Variationen.
• Icons: Quellstil, Stroke- oder Fill-Behandlung, Größenregeln und Anforderungen an Textlabels.
• Farbmodus: Zulässige Modi, Standardmodus, semantische Rollen und ob ein Screen unabhängig umschalten darf.
• Typografie: Schriftfamilie nach Rolle, verfügbare Schriftschnitte, Skalierung, Zeilenhöhe und Behandlung von Daten oder Code.
• Abstände und Layout: Containerbreiten, Gutters, Sektionsrhythmus, Grid-Verhalten und Dichte.
• Komponenten: Gemeinsame Behandlungen für Buttons, Inputs, Cards, Tabellen, Feedback und Fokus.
• Ausnahmen: Der exakte Screen, Zustand, Grund, Genehmiger und das Limit jeder Abweichung.

Prüfen Sie nicht nur den perfekt ausgearbeiteten Screen. Wählen Sie eine repräsentative Auswahl, die das Haupt-Shell, einen datenintensiven Screen, ein Formular, einen destruktiven Zustand oder Fehlerzustand sowie jeden Screen mit einer genehmigten Ausnahme enthält. Wenn Mobile oder Dark Mode im Umfang enthalten sind, nehmen Sie diese Zustände explizit auf.

Wenn zwei Screens divergieren, suchen Sie den ersten Punkt, an dem die Belege voneinander abweichen. Eine sofortige Neugenerierung aller Screens kann die Ursache verschleiern und neue Änderungen einführen.

1. 1

   Prüfen, ob die maßgebliche Regel vollständig ist

   Suchen Sie die relevante Regel in DESIGN.md. Wenn dort nur steht „konsistente Navigation verwenden“, werden Struktur, Zustände oder Ausnahmen nicht definiert. Überarbeiten Sie die Regel auf der verantwortlichen Ebene, bevor Sie die Screens korrigieren.

2. 2

   Prompts und akzeptierte Vorschläge vergleichen

   Dokumentieren Sie den ursprünglichen Prompt, Folgeanweisungen sowie alle automatischen oder manuellen Vorschläge. Eine screen-spezifische Anweisung könnte die gemeinsame Regel überschrieben haben. Entfernen oder präzisieren Sie diese Überschreibung und versuchen Sie es nur für den betroffenen Fall erneut.

3. 3

   Auf eine genehmigte Ausnahme prüfen

   Ein legitimer Unterschied ist kein Drift, wenn Screen, Zustand, Grund und Umfang genehmigt wurden. Falls die Ausnahme nicht dokumentiert ist, halten Sie inne und holen Sie eine Entscheidung zur Zuständigkeit ein, anstatt sie im Nachhinein zu normalisieren.

4. 4

   Das erste divergierende Artefakt lokalisieren

   Vergleichen Sie repräsentative Stitch-Screens, bevor Sie den nachgelagerten Code prüfen. Wenn die Screens übereinstimmen, aber der Export abweicht, leiten Sie den Befund an die Export- oder Implementierungsgrenze weiter. Wenn die Screens bereits divergieren, muss die Korrektur upstream erfolgen.

5. 5

   Eine vom Owner kontrollierte Variable ändern

   Wenden Sie eine eng gefasste Regeländerung an, wie etwa den Standard-Farbmodus oder die Behandlung der Navigationsauswahl. Fassen Sie Typografie, Abstände und Komponenten-Revisionen nicht im selben Test zusammen.

6. 6

   Eine Entscheidung (Disposition) zuweisen

   „Pass“, wenn die beabsichtigte Änderung wie erwartet erscheint und kein wesentlicher, nicht zusammenhängender Drift vorliegt. „Revise“, wenn die maßgebliche Regel oder der Prompt unvollständig ist. „Block“, wenn Zuständigkeit, Belege oder die Parität im Downstream ungeklärt bleiben.

Eine kontrollierte Änderung prüft, ob eine definierte Regel die Stellen erreicht, die sie erreichen soll. Dies ist spezifischer als eine allgemeine visuelle Prüfung. Wählen Sie eine Regel mit einem beobachtbaren Ergebnis, benennen Sie die relevanten Screens und die Export-Oberfläche und erfassen Sie sowohl die beabsichtigten als auch die unbeabsichtigten Effekte.

Controlled change

Project:
Observed date:
Reviewer:

Governing layer:
Rule identifier:
Current rule:
Proposed rule:
Reason for change:
Owner and approver:

Representative screens:
- Screen / state:
  Expected change:
  Actual observation:
  Evidence reference:
- Screen / state:
  Expected change:
  Actual observation:
  Evidence reference:

Approved exceptions:
- Screen / state:
  Exception and reason:
  Expected to remain unchanged: yes / no

Exported artifact:
Artifact and version:
Expected change:
Actual observation:
Evidence reference:

Unrelated drift:
- Navigation:
- Icons:
- Color mode:
- Typography:
- Spacing and layout:
- Component treatment:

Unresolved conflicts:
Owner:
Next evidence required:

Disposition: pass / revise / block
Disposition reason:

„Kein nicht zusammenhängender Drift beobachtet“ ist nur für die benannten Screens und Artefakte gültig. Es bedeutet nicht, dass das gesamte Projekt konsistent ist. Fügen Sie dort, wo es Ihr Workflow erlaubt, Referenzen zu Screenshots, Screen-Versionen, Prompt-Texten, DESIGN.md-Revisionen sowie exportierten Commits oder Archiven bei.

Dieses Aufnahmeprotokoll zeigt, wie eine begrenzte Quelle in den Prozess integriert wird, ohne Stitch-Ergebnisse zu fingieren. Ambient Sage ist ein kostenloses, veröffentlichtes Identity Forge Kit. Die dokumentierte Typografie verwendet Plus Jakarta Sans für Fließtext und Überschriften in den Schnitten 400, 500, 600 und 700 sowie JetBrains Mono für die Mono-Rolle in den Schnitten 400, 500 und 700. Die veröffentlichte Skalierung ist compact-product.

Artifact intake: Ambient Sage

Source state
- Public kit page: documented
- Kit access: free and published
- Typography roles: documented
- Body and heading family: Plus Jakarta Sans
- Body and heading weights: 400, 500, 600, 700
- Mono family: JetBrains Mono
- Mono weights: 400, 500, 700
- Typography scale: compact-product
- DESIGN.md: available
- Semantic light and dark tokens: available
- Delivery formats: shadcn, Tailwind, CSS, and DTCG

Stitch evidence state
- DESIGN.md imported into Stitch: not tested
- Import warnings or transformations: not tested
- Generated-screen adherence: not tested
- Navigation consistency: not tested
- Icon consistency: not tested
- Light and dark mode behavior: not tested
- Typography and spacing parity: not tested
- Exported-artifact parity: not tested
- Controlled-change result: not tested

Handoff disposition
- Status: block pending evidence
- Reason: the source artifact is documented, but no Stitch-specific behavior or source-to-export parity has been observed
- Next action: import through the currently documented Stitch workflow, capture any transformation, then run one controlled change across representative screens and the chosen export

Übergeben Sie die maßgebliche DESIGN.md, maschinenlesbare Tokens oder Implementierungsartefakte, das Ausnahmenregister, das Protokoll der kontrollierten Änderungen und den exportierten Code gemeinsam. Versehen Sie jedes Element mit einer Version oder einer stabilen Belegreferenz. Der Entwickler muss in der Lage sein, einen sichtbaren Wert auf eine semantische Rolle oder eine schriftliche Regel zurückzuführen und zu sehen, welche Unterschiede genehmigt wurden.

• Benennen Sie die für die Generierung verwendete DESIGN.md-Revision und das Token-Artefakt.
• Listen Sie repräsentative Screens und deren dokumentierte Zustände auf.
• Fügen Sie exakte genehmigte Ausnahmen und ungelöste Konflikte hinzu.
• Dokumentieren Sie die Exportmethode und die resultierende Artefaktversion.
• Trennen Sie verifizierte Parität von Bereichen, die nicht getestet wurden.
• Leiten Sie Downstream-Korrekturen an die verantwortliche Regel zurück, wenn sie gemeinsame Designentscheidungen darstellen.

Wenn ein Entwickler eine gemeinsame Farbe, einen Abstandswert oder eine Komponentenbehandlung nur im exportierten Code ändert, behandeln Sie dies als Downstream-Drift, bis die maßgebliche Quelle die Änderung akzeptiert. Wenn es sich um ein Implementierungsdetail ohne Auswirkungen auf das Designsystem handelt, belassen Sie es im Code und begründen Sie, warum es nicht upstream übertragen werden muss.

Der Designsystem-Handoff gilt als bestanden, wenn die maßgebliche Regel und der Verantwortliche klar definiert sind, repräsentative Screens das erwartete Ergebnis zeigen, genehmigte Ausnahmen begrenzt bleiben, das exportierte Artefakt die geprüfte Änderung beibehält und kein wesentlicher, nicht zusammenhängender Drift im Scope auftritt.

Wählen Sie „Überarbeiten“ (revise), wenn die Belege auf eine unvollständige DESIGN.md-Regel, einen zu weit gefassten Prompt-Override oder eine schlecht definierte Ausnahme hindeuten, die der aktuelle Verantwortliche korrigieren kann. Wählen Sie „Blockieren“ (block), wenn Quellen ohne Verantwortlichen kollidieren, kein Stitch-spezifisches Verhalten beobachtet wurde, das exportierte Artefakt eine maßgebliche Regel verletzt oder die Beleglage zu schwach ist, um die Entscheidung zu reproduzieren.

Füllen Sie bei einem neuen Projekt den vierstufigen Autoritätsnachweis aus, bevor Sie einen weiteren Screen generieren. Wählen Sie bei einem bestehenden Projekt eine sichtbare Inkonsistenz aus, leiten Sie diese an die zuständige Ebene weiter und führen Sie das Arbeitsblatt für kontrollierte Änderungen aus, bevor Sie den Rest akzeptieren oder neu generieren.

• Das DESIGN.md-Format von Stitch ist jetzt Open-Source und plattformübergreifend einsetzbar: Google dokumentiert DESIGN.md als portables Format für den Import und Export von Designregeln zwischen Projekten und Plattformen.
• Einführung von „Vibe Design“ mit Stitch: Google beschreibt den aktuellen Stitch-Workflow als Kombination aus einem AI-nativen Canvas, einem Design-Agenten, DESIGN.md-Unterstützung, Iteration und Delivery-Oberflächen für Entwickler.
• Von der Idee zur App: Einführung von Stitch, einem neuen Weg für das UI-Design: Der Launch-Artikel von Google dokumentiert die Generierung aus Text oder Bildern, interaktive Verfeinerung, den Transfer nach Figma und den Export von Frontend-Code.
• Designsystem oder Design-Richtlinie in einem Stitch-Projekt: In einem Community-Thread werden inkonsistente Icons, Navigation und Farbmodi über generierte Screens hinweg berichtet. Eine Antwort von Google empfiehlt explizitere Prompts und den Schutz ausgewählter Elemente.
• Wie man Google Stitch nutzt, um in wenigen Minuten ein Website-Designsystem zu erstellen: Dieses Tutorial eines Drittanbieters beschreibt die URL-Extraktion, die Generierung mehrseitiger Prototypen, Iteration und Export; die darin aufgestellten Behauptungen stellen jedoch keinen offiziellen Produktvertrag dar.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit bietet ein quellgebundenes Designbeispiel mit DESIGN.md, maschinenlesbaren Delivery-Artefakten, dokumentierten Typografie-Rollen und einem kompakten, produktorientierten visuellen System.
• AI UI Review-Checkliste: Generierte Interfaces testen vor dem Release: Die veröffentlichte Review-Checkliste von Identity Forge trennt die Konformität zum Designsystem von der allgemeinen Einsatzbereitschaft und nutzt repräsentative Zustände, kontrollierte Änderungen, Belegnachweise und explizite Entscheidungen.

• Stitch's DESIGN.md format is now open-source so you can use it across platforms: Google dokumentiert DESIGN.md als portables Format für den Import und Export von Designregeln zwischen Projekten und Plattformen.
• Introducing "vibe design" with Stitch: Google beschreibt den aktuellen Stitch-Workflow als Kombination aus einem AI-nativen Canvas, einem Design-Agenten, DESIGN.md-Unterstützung, Iteration und Delivery-Oberflächen für Entwickler.
• From idea to app: Introducing Stitch, a new way to design UIs: Der Launch-Artikel von Google dokumentiert die Generierung aus Text oder Bildern, interaktive Verfeinerung, den Transfer nach Figma und den Export von Frontend-Code.
• Design system or design guideline on Stitch project: In einem Community-Thread werden inkonsistente Icons, Navigation und Farbmodi über generierte Screens hinweg berichtet. Eine Antwort von Google empfiehlt explizitere Prompts und den Schutz ausgewählter Elemente.
• How to Use Google Stitch to Build a Website Design System in Minutes: Dieses Tutorial eines Drittanbieters beschreibt die URL-Extraktion, die Generierung mehrseitiger Prototypen, Iteration und Export; die darin aufgestellten Behauptungen stellen jedoch keinen offiziellen Produktvertrag dar.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit bietet ein quellgebundenes Designbeispiel mit DESIGN.md, maschinenlesbaren Delivery-Artefakten, dokumentierten Typografie-Rollen und einem kompakten, produktorientierten visuellen System.
• AI UI review checklist: test generated interfaces before you ship: Die veröffentlichte Review-Checkliste von Identity Forge trennt die Konformität zum Designsystem von der allgemeinen Einsatzbereitschaft und nutzt repräsentative Zustände, kontrollierte Änderungen, Belegnachweise und explizite Entscheidungen.