Umfassende Branding-Guides decken in der Regel Recherche, Positionierung, Identität, Voice und Anwendung ab. Ein Entwickler-Handoff setzt später an. Seine Aufgabe ist es, die genehmigte Brand-Strategie in Website-Entscheidungen zu übersetzen, ohne dass der Implementierer fehlende Richtlinien oder Design-Regeln erfinden muss.

Halten Sie sechs Arten von Materialien getrennt. Traditionelle Identity Assets umfassen Logos, Bildmarken, Markenfarben, Schriftarten, Fotografie, Illustrationen und verbale Richtlinien. Website-Design-Entscheidungen weisen diesen Materialien semantische Rollen, Skalen, Layouts, Modi und Nutzungsregeln zu. Produktanforderungen definieren Verhalten, Berechtigungen, Validierung, Inhalte und Recovery. Delivery-Artefakte überführen genehmigte Design-Entscheidungen in ein Repository oder Tool. Implementierte Consumer sind die Komponenten und Oberflächen, die diese Artefakte auslesen. Acceptance-Belege dokumentieren, was geprüft wurde und was ungeklärt bleibt.

Dokumentieren Sie jede Entscheidung als Kette von der Autorität bis zum Beleg. Dies deckt zwei häufige Fehler auf: den neuesten Export als Single Source of Truth zu betrachten und einen korrekten Token-Wert als Beweis dafür zu sehen, dass die Benutzeroberfläche ihn korrekt verwendet.

• Artefakt: das Asset, die Regel, die Token-Gruppe, die Datei oder die Referenz, die geprüft wird.
• Source of Truth: der genehmigte Ort und die Version, die die Autorität über die Entscheidung hat.
• Semantischer Zweck: was die Entscheidung in der Benutzeroberfläche bedeutet, nicht nur ihr visueller Wert.
• Delivery-Format: wie die Entscheidung das Projekt erreicht, z. B. als schriftliche Richtlinie, DTCG-Tokens, CSS-Variablen, ein Tailwind-Theme oder ein Registry-Eintrag.
• Beabsichtigter Consumer: die Komponente, das Template, der Agent, das Build-Tool oder die Runtime-Style-Layer, die es verwenden sollen.
• Owner: die Person oder das Team, die berechtigt ist, Unklarheiten zu beseitigen oder Änderungen zu genehmigen.
• Zulässige Änderungen: Transformationen, die der Implementierer vornehmen darf, ohne eine erneute Genehmigung einzuholen.
• Bekannte Auslassungen: erforderliche Rollen, Modi, Zustände, Breakpoints, Assets oder Regeln, die die Quelle nicht definiert.
• Acceptance-Beleg: die Oberfläche, der Zustand, der Viewport, der Modus und das beobachtbare Ergebnis, die zur Verifizierung der Implementierung verwendet werden.

artifact: ""
status: ready-to-implement | requires-decision | reference-only | outside-handoff
source_of_truth:
  location: ""
  version_or_date: ""
  approved_by: ""
semantic_purpose: ""
delivery:
  format: ""
  path_or_identifier: ""
intended_consumers:
  - ""
owner: ""
permitted_changes:
  - ""
known_omissions:
  - ""
acceptance_evidence:
  surfaces:
    - ""
  states:
    - ""
  viewports_or_containers:
    - ""
  color_modes:
    - ""
  expected_observation: ""
notes: ""

Das Statusfeld steuert die nächsten Schritte. Es verhindert, dass ein Referenzbild versehentlich Autorität erlangt, und hält undefinierte Anforderungen aus der Implementierungswarteschlange fern.

• Ready to implement: Autorität, semantischer Zweck, Consumer, zulässige Änderungen und relevante Akzeptanzbedingungen sind explizit definiert.
• Requires a decision: Der Input ist relevant, aber mindestens eine wesentliche Regel fehlt oder ist widersprüchlich. Weisen Sie einen Owner zu und blockieren Sie nur die betroffenen Arbeiten.
• Reference only: Das Element vermittelt eine Richtung oder einen Kontext, ist aber nicht präzise genug, um die Implementierung zu steuern. Moodboards und Kampagnen-Mockups gehören oft in diese Kategorie.
• Außerhalb des Website-Handoffs: Das Element gehört zu einer anderen Disziplin oder einem anderen Deliverable, wie etwa der Markenprüfung, der Kampagnenplanung, Produktberechtigungen oder dem finalen redaktionellen Copy. Dokumentieren Sie diese Grenze, damit das Fehlen des Elements nicht fälschlicherweise als Aufgabe für die Entwicklung interpretiert wird.

Die Klassifizierung erfolgt granular. Ein Logo-Paket kann bereit für die Platzierung sein, während die Mindestgröße bei geringen Breiten noch eine Entscheidung erfordert. Ein Farbsystem kann für den Light Mode bereit sein, während der Dark Mode noch undefiniert bleibt. Diese Aufteilung des Datensatzes ermöglicht es, die Arbeit fortzusetzen, ohne den ungelösten Teil zu verschleiern.

Rohfarben sind Zutaten. Der Website-Code benötigt Rollen wie Seitenhintergrund, Vordergrund, Card, gedämpfte Oberfläche, Rahmen, primäre Aktion, destruktive Aktion, Fokusring und Statusfarben. Jede Paarung von Vordergrund und Oberfläche benötigt eine beabsichtigte Verwendung. Wenn Light- und Dark-Modes unterstützt werden, dokumentieren Sie beide Zuweisungen und geben Sie an, ob ein Modus auf einen anderen Wert zurückgreifen darf.

Leiten Sie Fehler-, Warn-, Erfolgs-, Auswahl- oder Fokusfarben nicht von einer Markenakzentfarbe ab, es sei denn, die zuständige Instanz weist diesen Bedeutungen zu. Derselbe Hex-Wert kann als Kampagnenfarbe gültig und als Interface-Rolle falsch sein.

Dokumentieren Sie die Schriftfamilie für jede Rolle, die genehmigten Schriftschnitte, die Typografieskala, Regeln zur Zeilenhöhe, den Zeichenabstand, Fallbacks sowie die Stellen, an denen Mono- oder Display-Schriften zulässig sind. Ein bloßer Name der Schriftfamilie überlässt die Wahl der Schriftschnitte und Metriken dem Browser und dem Entwickler. Zudem sagt er nichts über Überschriften, Fließtext, Labels, Buttons, Tabellen oder numerische Daten aus.

Die Bereitstellung der Schriftarten ist eine separate Implementierungsentscheidung. Das Brand Kit kann Familien und Rollen genehmigen, während das Projekt weiterhin eine Ladestrategie, verfügbare Dateien, Fallbacks und Performance-Prüfungen benötigt. Diese technischen Entscheidungen sollten die genehmigten Rollen beibehalten, ohne vorzutäuschen, dass der visuelle Handoff jeden Trade-off bei der Bereitstellung gelöst hat.

Spezifizieren Sie die Abstandsskala, Seitenränder, Inhaltsbreiten, Sektionsrhythmus, Grid-Verhalten, Eckradien, Rahmen, Schatten und wiederkehrende Motive, die das System erkennbar machen. Benennen Sie Ausnahmen. Wenn ein Motiv dekorativ ist, geben Sie an, wo es erscheinen darf und wie es sich in begrenzten Containern verhält.

Dokumentieren Sie für Logos die genehmigten Varianten, den Schutzraum, die minimale nutzbare Größe, Hintergrundbeschränkungen sowie, ob Zuschneiden oder Umfärben zulässig ist. Für Fotografie und Illustrationen sollten Auswahl- und Bearbeitungsregeln enthalten sein, statt nur ein Ordner mit Beispielen. Alternativtexte und die inhaltliche Bedeutung hängen weiterhin vom tatsächlichen Seitenkontext ab; eine Brand-Asset-Bibliothek kann diese nicht universell bereitstellen.

Breakpoints, Container-Verhalten, Reflow, Kürzung, Navigationsänderungen, Dichte und Touch-Targets sind Website-Entscheidungen. Hover-, Fokus-, Pressed-, Selected-, Disabled-, Loading-, Success-, Empty- und Error-Zustände benötigen Anforderungen dort, wo das Produkt sie erreichen kann. Ein statisches Brand Board definiert diese Verhaltensweisen nicht.

Der Handoff kann die visuelle Gestaltung für Buttons, Inputs, Cards, Navigation, Tabellen, Diagramme und Dialoge definieren. Er definiert jedoch nicht automatisch, was diese Komponenten tun. Berechtigungen, Validierung, Bestätigung, Stornierung, Datenverarbeitung und Wiederherstellung gehören zu den Produktanforderungen. Halten Sie diese Zuständigkeit getrennt, selbst wenn beide Arten von Regeln in derselben Oberfläche erscheinen.

Das öffentliche Ambient Sage Kit zeigt, wie verschiedene Handoff-Ebenen miteinander verknüpft werden können. Es weist Plus Jakarta Sans den Rollen für Überschriften und Fließtext mit den Schriftschnitten 400, 500, 600 und 700 zu. JetBrains Mono übernimmt die Mono-Rolle in den Schriftschnitten 400, 500 und 700. Die veröffentlichte Skala ist compact-product. Das Farbsystem umfasst semantische Rollen für den Light- und Dark-Mode, während schriftliche Richtlinien ein warm-sage Canvas, eine tonale Kartenbehandlung, einen zurückhaltenden gelben Akzent und überdimensionierte numerische Werte beschreiben.

Dies ist hilfreicher als eine reine Schriftartenliste, da Schriftfamilien mit Rollen und Schriftschnitten verknüpft werden, und nützlicher als eine Palette, da semantische Zuweisungen und Nutzungsrichtlinien bereitgestellt werden. Dasselbe Kit ist über DESIGN.md, DTCG Token JSON, CSS-Variablen, Tailwind-Outputs, shadcn Registry JSON, einen Registry-Installationspfad, die Identity Forge CLI und MCP-Zugriff verfügbar.

Das Beispiel hat feste Grenzen. Es beweist nicht, dass Plus Jakarta Sans und JetBrains Mono die beste Kombination für ein anderes Produkt sind. Es legt nicht das Komponentenverhalten, die responsiven Regeln, Inhaltsanforderungen, die Barrierefreiheits-Konformität oder die Produktionsreife eines anderen Produkts fest. Diese Entscheidungen benötigen weiterhin lokale Verantwortliche und Nachweise.

Ein Bereitstellungs-Artefakt sollte eine genehmigte Entscheidung transportieren, ohne stillschweigend zur Instanz zu werden, die diese Entscheidung getroffen hat. Dokumentieren Sie, welche Quelle das Artefakt erzeugt hat, wann es generiert wurde und welcher Konsument es liest. Wenn ein Export und seine Quelle voneinander abweichen, lösen Sie das Problem an der Quelle oder im Regenerierungspfad, bevor Sie die sichtbare Komponente patchen.

• DESIGN.md enthält die Intention, Nutzungsregeln, Layout-Richtlinien, Motive, Komponentenbehandlungen und Constraints, die sich nur schwer als Token-Werte ausdrücken lassen.
• DTCG-Tokens bieten eine strukturierte Darstellung, die Tools oder Transformationen speisen kann, während Token-Namen und -Werte erhalten bleiben.
• CSS-Variablen stellen Theme-Werte direkt für Styles und Komponenten bereit. Ihr Vorhandensein beweist nicht, dass jede Komponente auf die korrekte Rolle verweist.
• Der Tailwind-Output bildet Entscheidungen in die Utility- und Theme-Konventionen des Projekts ab. Lokale Utilities können diese Zuweisung dennoch überschreiben oder umgehen.
• Ein shadcn-Registry-Element paketiert Werte für einen kompatiblen Installationspfad. Es bleibt ein Bereitstellungsmechanismus und kein Beweis dafür, dass die installierten Komponenten jede Markenregel erfüllen.
• Der CLI-Zugriff wendet Artefakte in einem Projekt an oder schreibt sie hinein. Der MCP-Zugriff ermöglicht es einem kompatiblen Agenten, Kit-Informationen zu entdecken, zu lesen oder anzuwenden. In beiden Fällen benötigt das empfangende Projekt weiterhin eine erklärte Zuständigkeit und ein Abnahmeprotokoll.

Wählen Sie Oberflächen, die verschiedene Rollen beanspruchen, anstatt jede Route oberflächlich zu prüfen. Beziehen Sie die Modi, Zustände und Containerbreiten ein, die das Produkt tatsächlich unterstützt.

• Navigation: Logo-Gestaltung, aktiver Zustand, Hierarchie, Fokus und Verhalten bei geringer Breite.
• Überschriften und Fließtext: Rollenzuweisung, zulässige Schriftschnitte, Zeilenlänge, Umbruch und vertikaler Rhythmus.
• Formulare: Labels, Inputs, Hilfetexte, Validierung, deaktivierte Steuerelemente, Fokus und Wiederherstellungszustände, sofern diese im Umfang enthalten sind.
• Buttons und Links: primäre, sekundäre, destruktive, gedrückte, deaktivierte und Fokus-Gestaltungen, wo erforderlich.
• Cards und Overlays: Oberflächenrollen, Vordergrund-Paarungen, Rahmen oder tonale Trennung, Radius, Abstände und Stapelung.
• Tabellen oder Metriken: Überschriftenhierarchie, numerische Gestaltung, Ausrichtung, Dichte, lange Werte und Empty-States.
• Statuszustände: Rollen für Erfolg, Warnung, Fehler, Auswahl und Laden, ohne Bedeutungen aus dekorativen Farben abzuleiten.
• Light- und Dark-Modes: semantische Parität, Lesbarkeit, lokale Overrides und Komponenten, die einen ursprünglichen Light-Mode-Wert beibehalten.
• Schmale Container: Zeilenumbrüche, Reflow, Clipping, Navigationsänderungen und Motive, die mit dem Inhalt konkurrieren.

Ein Screenshot kann eine Diskrepanz aufzeigen, identifiziert aber selten den Verantwortlichen. Verfolgen Sie eine genehmigte Entscheidung durch die gesamte Kette. Eine kontrollierte Änderung macht veraltete oder umgangene Ebenen sichtbar.

1. 1

   Eine genehmigte Entscheidung mit geringem Risiko wählen

   Verwenden Sie ein reversibles Token oder ein Typografie-Mapping mit einer klaren Quelle und einem repräsentativen Consumer. Dokumentieren Sie die aktuelle Quellversion und die erwarteten Surfaces.

2. 2

   Den maßgeblichen Datensatz bestätigen

   Überprüfen Sie den semantischen Zweck, die erlaubten Modi, den Verantwortlichen sowie den erwarteten Wert oder die Regel. Wenn die Zuständigkeit unklar ist, brechen Sie den Test ab und klären Sie diese Unklarheit zuerst.

3. 3

   Das ausgewählte Delivery-Artefakt regenerieren oder aktualisieren

   Nutzen Sie den regulären Delivery-Pfad. Dokumentieren Sie die Artefaktversion oder die resultierende Änderung, damit ein veralteter Export von einer fehlerhaften Implementierung unterschieden werden kann.

4. 4

   Den beabsichtigten Consumer prüfen

   Bestätigen Sie, dass die relevante Komponente oder Style-Ebene die semantische Rolle ausliest. Suchen Sie nach Raw-Values, Aliasen, kopierten Konstanten, Framework-Defaults und lokalen Overrides.

5. 5

   Repräsentative Surfaces prüfen

   Prüfen Sie den anwendbaren Zustand, Viewport, Container und Farbmodus. Dokumentieren Sie sowohl die erwartete Änderung als auch jede Surface, die sich nicht geändert hat.

6. 6

   Jede Diskrepanz nach Ebenen klassifizieren

   Eine falsche Quellentscheidung geht zurück an den Design-Verantwortlichen. Ein veralteter Export geht zurück an den Delivery-Prozess. Ein fehlerhaftes Mapping gehört zur Consumer-Integration. Ein lokaler Override gehört zur Implementierung. Eine Änderung an anderer Stelle kann ein nicht zusammenhängender Drift sein und sollte ohne Belege nicht in den Brand-Fix einbezogen werden.

7. 7

   Den kontrollierten Wert wiederherstellen oder genehmigen

   Kehren Sie zum genehmigten Wert zurück, es sei denn, der Test selbst war ein autorisiertes Update. Bewahren Sie in jedem Fall die Belegdokumentation auf.

Schließen Sie den Intake mit einer expliziten Entscheidung ab. Die Genehmigung sollte sich auf die durch Belege gestützten Entscheidungen und Surfaces beschränken und nicht als allgemeine Behauptung formuliert werden, dass die Marke oder die Website vollständig sei.

decision: approve | revise | block
scope:
  decisions: []
  consumers: []
  surfaces: []
  modes: []
  viewports_or_containers: []
resolved_evidence:
  - decision: ""
    source_of_truth: ""
    delivery_artifact: ""
    observed_result: ""
unresolved:
  - issue: ""
    classification: missing-decision | stale-artifact | consumer-mapping | local-override | unrelated-drift
    owner: ""
    required_evidence: ""
    next_action: ""
    blocks: ""
permitted_implementation_step: ""
reviewed_by: ""
reviewed_on: ""

Der nächste Implementierungsschritt sollte direkt aus diesem Datensatz folgen. Wenden Sie das genehmigte Artefakt an, wenn die Kette vollständig ist. Fordern Sie eine benannte Entscheidung an, wenn die Zuständigkeit fehlt. Korrigieren Sie die identifizierte Delivery- oder Consumer-Ebene, wenn die Quelle bereits korrekt ist. Dies verhindert, dass Entwickler eine ungeklärte Markenfrage in eine dauerhafte lokale Konvention verwandeln.

• How To Build a Brand From Scratch (2026): Shopify präsentiert das Brand Kit und den Styleguide innerhalb eines umfassenderen Prozesses, der auch Zielgruppenforschung, Voice, Naming, Story, Logo-Erstellung, Anwendung und Messung abdeckt.
• What is a Brand? Definition and Examples: Ramotion beschreibt Brand-Komponenten über die visuelle Identität, verbale Identität, Interaktionserlebnisse, Werte und Positionierung hinweg und zeigt auf, dass eine Marke über ein Logo hinausgeht.
• What is Branding? Understanding Its Importance: HubSpot behandelt Markenstrategie, visuelle Assets, Voice und die Anwendung auf Websites und anderen Kanälen als Teil eines umfassenderen Branding-Prozesses.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit dokumentiert Plus Jakarta Sans für Überschriften und Fließtext, JetBrains Mono für die Mono-Rolle, semantische Light- und Dark-Tokens, schriftliche Richtlinien sowie verschiedene Delivery-Formate für Entwickler.
• So erstellen Sie eine DESIGN.md (und was sie ist): Identity Forge beschreibt die DESIGN.md als schriftliches Design-Briefing, das die Intention, Farb- und Typographiesysteme, Layout- und Spacing-Regeln, die Gestaltung von Komponenten, Motive sowie explizite Nutzungsbeschränkungen enthält.
• Semantische Farb-Tokens erklärt: Identity Forge erläutert, dass semantische Tokens Farben nach ihrem Zweck benennen – wie beispielsweise Background, Foreground, Primary, Border und Ring – anstatt nach ihrem reinen Farbton.
• AI UI Review-Checkliste: Generierte Interfaces vor dem Release testen: Der Review-Guide trennt Produktanforderungen, Design-Autorität, Delivery-Artefakte, Implementierungsnachweise und Accessibility-Nachweise und empfiehlt, kontrollierte Änderungen bis zu der Ebene zurückzuverfolgen, die für eine Diskrepanz verantwortlich ist.
• Shadcn Designsystem-Generatoren: Benötigen Sie ein Theme, ein System oder einen Agent-Handoff?: Identity Forge unterscheidet zwischen einem visuellen Theme, einem umfassenderen Designsystem und einem Agent-Handoff und empfiehlt die Prüfung von Token-Bedeutungen, Modus-Parität, Typografie, Layout-Richtlinien, Installationswegen und bekannten Lücken.

• How To Build a Brand From Scratch (2026): Shopify präsentiert das Brand Kit und den Styleguide innerhalb eines umfassenderen Prozesses, der auch Zielgruppenforschung, Voice, Naming, Story, Logo-Erstellung, Anwendung und Messung abdeckt.
• What is a Brand? Definition and Examples: Ramotion beschreibt Brand-Komponenten über die visuelle Identität, verbale Identität, Interaktionserlebnisse, Werte und Positionierung hinweg und zeigt auf, dass eine Marke über ein Logo hinausgeht.
• What is Branding? Understanding Its Importance: HubSpot behandelt Markenstrategie, visuelle Assets, Voice und die Anwendung auf Websites und anderen Kanälen als Teil eines umfassenderen Branding-Prozesses.
• Ambient Sage Design Kit: Das öffentliche Ambient Sage Kit dokumentiert Plus Jakarta Sans für Überschriften und Fließtext, JetBrains Mono für die Mono-Rolle, semantische Light- und Dark-Tokens, schriftliche Richtlinien sowie verschiedene Delivery-Formate für Entwickler.
• How to generate a DESIGN.md (and what it is): Identity Forge beschreibt DESIGN.md als ein schriftliches Design-Briefing, das die Intention, Farb- und Typographiesysteme, Layout- und Abstandsregeln, die Gestaltung von Komponenten, Motive sowie explizite Nutzungsbeschränkungen enthält.
• Semantic color tokens explained: Identity Forge erläutert, dass semantische Tokens Farben nach ihrem Zweck benennen – wie beispielsweise Background, Foreground, Primary, Border und Ring – anstatt nach ihrem reinen Farbton.
• AI UI review checklist: test generated interfaces before you ship: Der Review-Guide trennt Produktanforderungen, Design-Autorität, Delivery-Artefakte, Implementierungsnachweise und Accessibility-Nachweise und empfiehlt, kontrollierte Änderungen bis zu der Ebene zurückzuverfolgen, die für eine Diskrepanz verantwortlich ist.
• Shadcn design system generators: do you need a theme, a system, or an agent handoff?: Identity Forge unterscheidet zwischen einem visuellen Theme, einem umfassenderen Designsystem und einem Agent-Handoff und empfiehlt die Prüfung von Token-Bedeutungen, Modus-Parität, Typografie, Layout-Richtlinien, Installationswegen und bekannten Lücken.