Google Stitch Designsystem: Drift diagnostizieren und Handoff verifizieren

Google beschreibt DESIGN.md als einen portablen Weg zum Import und Export von Designregeln. Es kann gemeinsame Entscheidungen über Farbollen, 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 Produktdokumentation, 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 Produktvertrag 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 Anweisungen von Drittanbietern 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, die DESIGN.md nennt eine andere, ein generierter Screen führt eine dritte ein und jemand korrigiert den exportierten Code manuell. Ohne ein Prioritätenprotokoll setzt sich tendenziell das zuletzt sichtbare Ergebnis durch, 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 einfach dadurch, dass Sie den Wert übernehmen, 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. „Ein einheitliches Erscheinungsbild bewahren“ ist nicht prüfbar. „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, Strich- oder Füllbehandlung, Größenregeln und Anforderungen an Textbeschriftungen.
• Farbmodus: Zulässige Modi, Standardmodus, semantische Rollen und ob ein Screen unabhängig umschalten darf.
• Typografie: Schriftfamilie nach Rolle, verfügbare Schriftschnitte, Skalierung, Zeilenhöhen-Absicht und Behandlung von Daten oder Code.
• Abstände und Layout: Containerbreiten, Gutter, 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 am besten ausgearbeiteten Screen. Wählen Sie eine repräsentative Auswahl aus, die das Hauptgerüst, 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 jedes 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 DESIGN.md-Regel. Wenn dort nur steht „konsistente Navigation verwenden“, definiert dies weder Struktur, Zustände noch Ausnahmen. Überarbeiten Sie die Regel auf der zuständigen 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. Wenn die Ausnahme nicht dokumentiert ist, halten Sie inne und lassen Sie eine Entscheidung über die Zuständigkeit treffen, 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, behalten Sie die Korrektur auf der Upstream-Ebene.

5. 5

   Eine vom Eigentümer kontrollierte Variable ändern

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

6. 6

   Eine Entscheidung 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 zu nachgelagerten Systemen ungeklärt bleiben.

Eine kontrollierte Änderung prüft, ob eine erklärte 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 im Umfang enthaltenen Screens und die Exportoberflä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. Wo Ihr Workflow es erlaubt, fügen Sie 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 erfinden. 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 nachgelagerte Korrekturen an die zuständige 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 erläutern Sie, warum es nicht Upstream übertragen werden muss.

Der Handoff des Designsystems wird dann als bestanden gewertet, 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 revise, wenn die Belege auf eine unvollständige Regel in der DESIGN.md, einen zu breit gefassten Prompt-Override oder eine schlecht definierte Ausnahme hindeuten, die vom aktuellen Owner korrigiert werden kann. Wählen Sie block, wenn Quellen ohne Owner kollidieren, kein Stitch-spezifisches Verhalten beobachtet wurde, das exportierte Artefakt eine geltende 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 durch, bevor Sie den Rest akzeptieren oder neu generieren.

• Das DESIGN.md-Format von Stitch ist jetzt Open Source und plattformübergreifend einsetzbar: Google definiert DESIGN.md als portables Format für den Import und Export von Design-Regeln zwischen Projekten und Plattformen.
• Einführung in „Vibe Design“ mit Stitch: Google beschreibt den aktuellen Stitch-Workflow als eine Kombination aus einem AI-nativen Canvas, einem Design-Agent, Unterstützung für DESIGN.md, Iterationen und Oberflächen für die Übergabe an die Entwicklung.
• 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 zu 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, jedoch stellen die Behauptungen keinen offiziellen Produktvertrag dar.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit bietet ein quellgebundenes Designbeispiel mit einer DESIGN.md, maschinenlesbaren Delivery-Artefakten, dokumentierten Typografie-Rollen und einem kompakten, produktorientierten visuellen System.
• AI UI Review Checklist: 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 Dispositionen.

• Stitch's DESIGN.md format is now open-source so you can use it across platforms: Google definiert DESIGN.md als portables Format für den Import und Export von Design-Regeln zwischen Projekten und Plattformen.
• Introducing "vibe design" with Stitch: Google beschreibt den aktuellen Stitch-Workflow als eine Kombination aus einem AI-nativen Canvas, einem Design-Agent, der Unterstützung von DESIGN.md, Iterationen sowie Oberflächen für die Übergabe an die Entwicklung.
• 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 zu 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, jedoch stellen die Behauptungen keinen offiziellen Produktvertrag dar.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit bietet ein quellgebundenes Designbeispiel mit einer 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 Dispositionen.