Design Handoff

Was macht Design Handoff?

Verwandle ein fertiges Mockup in eine Spezifikation, die ein Entwickler umsetzen kann, ohne dir eine Rückfrage zu stellen – und das für alles, was tatsächlich in der Quelle sichtbar war. Und ohne dass du dir eine Antwort für etwas ausdenkst, das nicht sichtbar war.

Eingabe

Akzeptiere jede der folgenden Optionen:

• Ein oder mehrere Mockup-Bilder oder Screenshots, entweder in den Chat eingefügt oder als Dateipfad angegeben.
• Eine HTML-Datei oder eine URL zu einer Live-Seite.
• Ein optionales Token-Set: eine CSS-Datei mit benutzerdefinierten Eigenschaften, eine JSON-Token-Datei oder eine einfache Beschreibung vorhandener Design-Tokens (Palette, Schriftgrößensystem, Abstandsrampe, Radien, Schatten).

Wenn kein Token-Set angegeben wird, gib dies in der Ausgabe an und leite einen Entwurf aus dem Mockup selbst ab (siehe Schritt 3).

Ausgabe

Eine Markdown-Datei pro Bildschirm, benannt <screen-slug>-handoff.md, die der achtteiligen Struktur in references/handoff-template.md folgt. Lies diese Datei, um das genaue Gerüst zu erhalten, das du vor dem Schreiben der ersten Spezifikation kopieren musst.

Entscheide zuerst über die Anzahl der Bildschirme. Wenn zwei oder mehr Eingaben dasselbe Layout zeigen, bei dem sich nur der Zustand einer Komponente geändert hat (ein Button im Normal- und Hover-Zustand, ein Formular vor und nach einem Fehler), dann handelt es sich um EINEN Bildschirm – führe die Belege in Abschnitt 4 einer einzigen Spezifikation zusammen. Wenn die Eingaben unterschiedliche Bildschirme, Routen oder Breakpoints zeigen, schreibe eine Spezifikationsdatei pro Bildschirm. Für einen Bildschirm, der mit mehreren Breakpoints geliefert wird, schreibe eine Datei pro Bildschirm und füge in Abschnitt 2 (Layout) einen Unterabschnitt pro Breakpoint hinzu, anstatt die gesamte Datei zu duplizieren.

Die Grundregel: Erfinde niemals, was du nicht sehen kannst

Dies ist die Regel, der jeder andere Schritt dient. Wenn ein Wert, ein Zustand oder ein Verhalten im Quellmaterial nicht direkt sichtbar ist:

• Rate ihn nicht.
• Leite ihn nicht durch einen „vernünftigen Standard“ ab (dunkle eine Farbe nicht um 10% für eine Hover-Vermutung ab, nimm keine 200ms Einblendung an, weil das üblich ist).
• Schreibe OPEN QUESTION und füge sie in Abschnitt 8 ein, nummeriert und mit BLOCKING oder NON-BLOCKING gekennzeichnet.

Eine Spezifikation mit zehn offenen Fragen, weil die Quelle nur einen Zustand zeigt, erfüllt ihre Aufgabe. Eine Spezifikation mit null offenen Fragen, weil du jede Lücke mit einer plausiblen Vermutung gefüllt hast, ist an ihrer einzigen Daseinsberechtigung gescheitert.

Schritte

1. Bildschirmzusammenfassung

Erfasse die Abmessungen (aus der Bildgröße, dem HTML-Viewport oder einem angegebenen Breakpoint – markiere (geschätzt), wenn aus Proportionen statt aus Messungen abgeleitet), einen ein-Satz-Zweck und wie viele Quellbilder oder -dateien diese Spezifikation gespeist haben.

2. Layout

Gehe den Bildschirm in Lesereihenfolge durch (oben nach unten, links nach rechts innerhalb einer Zeile) und liste jede Region auf: Name, Position oder Größe, Innenabstand und den Abstand zur nächsten Region. Verwende die Einheiten, die die Quelle unterstützt – exakte Pixel aus HTML/CSS oder (geschätzte) Proportionen aus einem statischen Bild. Wenn zwei Quellen desselben Bildschirms widersprüchliche Abstände zeigen (z. B. zwei Screenshots mit leicht unterschiedlichem Padding), markiere den Konflikt explizit in diesem Abschnitt. Mittelwerte nicht und wähle nicht stillschweigend einen Wert aus.

3. Token-Zuordnung

Liste jede einzelne Farbe, Schriftart, jeden Abstandswert, jede Eckenrundung und jeden Schatten auf, die auf dem Bildschirm erscheinen, genau einmal, mit vier Spalten: Eigenschaft, beobachteter Wert, zugeordnetes Token, Status.

• Wenn ein Token-Set bereitgestellt wurde, ordne jeden beobachteten Wert dem nächstgelegenen vorhandenen Token zu. Verwende eine kleine Toleranz (einige Pixel für Abstände, einen nahen visuellen Nachbarn für Farben) – wenn nichts innerhalb dieser Toleranz passt, ist der Wert neu.
• Werte ohne Treffer erhalten NEU-TOKEN: <vorgeschlagener-name> in der Spalte „zugeordnetes Token“, wobei die Namenskonvention der vorhandenen Tokens befolgt wird, wenn eine sichtbar ist (z. B. color-<rolle>, space-<n>, radius-<groesse>), oder ein einfacher rollenbasierter Kebab-Case-Name, wenn keine vorhandene Konvention befolgt werden kann.
• Wenn überhaupt kein Token-Set bereitgestellt wurde, ist jede Zeile NEU-TOKEN – erstelle einen vollständigen vorgeschlagenen Satz und sage in der Spezifikation deutlich, dass nichts davon gegen ein reales System bestätigt ist.

4. Komponenteninventar

Für jedes einzelne interaktive Element (Buttons, Eingabefelder, Karten, Navigationspunkte, Toggles usw.) liste genau diese acht kanonischen Zustände auf: Standard, Hover, Fokus, Aktiv, Deaktiviert, Laden, Leer, Fehler.

Markiere für jeden Zustand eines der folgenden:

• Eine konkrete Spezifikationszeile (Füllung, Label, Rand, Symbol), nur wenn dieser Zustand tatsächlich in der Quelle sichtbar ist.
• nicht zutreffend mit einer einteiligen Begründung (ein statisches Label hat keinen Hover-Zustand; eine Einzelelementliste hat keinen leeren Zustand).
• OFFENE FRAGE #n, wenn der Zustand für diese Komponente plausibel, aber nicht gezeigt wird.

Wenn die Quelle nur einen Standardzustand für einen gesamten Bildschirm zeigt, sage dies deutlich am Anfang dieses Abschnitts („Quelle zeigt nur Standardzustand – die Zustandstabelle unten besteht größtenteils absichtlich aus offenen Fragen“), anstatt die Tabelle mit erfundenen Hover- und Fokusfarben aufzufüllen.

5. Verhaltenshinweise

Übergänge, Scrollverhalten (klebrige Kopfzeilen, unendliches Scrollen, Parallax-Effekte) und Validierungszeitpunkt (bei Verlassen des Feldes, beim Absenden, bei Tastatureingabe) – aber nur, was die Quelle direkt zeigt oder in einer Anmerkung angibt. Ein Pfeilsymbol impliziert Navigation; es impliziert keinen Übergangsstil. Markiere alles Spekulative als offene Frage, anstatt es als Tatsache zu beschreiben.

6. Barrierefreiheitsanmerkungen

• Rollen von Orientierungspunkten, die aus der visuellen Struktur abgeleitet wurden (Kopfzeile, Navigation, Hauptbereich, Liste, Button, Dialogfeld).
• Zugängliche Namen, die aus sichtbarem Text oder, bei symbolbasierten Steuerelementen, aus der Bedeutung des Symbols vorgeschlagen werden.
• Eine vorgeschlagene Fokusreihenfolge, die der Lesereihenfolge und der visuellen Hierarchie entspricht, nummeriert.
• Kontrastverhältnisse für jedes Vordergrund-/Hintergrund-Textpaar, das in der Token-Zuordnung erscheint, geprüft gegen WCAG 2.2 SC 1.4.3 (4,5:1 für normalen Text, 3:1 für großen Text) und SC 1.4.11 für nicht-textuelle UI-Komponenten. Wenn der exakte Hex-Wert nicht aus der Quelle extrahiert werden kann, gib an, dass das Verhältnis geschätzt ist, und kennzeichne es als offene Frage, wenn es nahe am Schwellenwert liegt.

7. Asset-Liste

Jedes Bild, Symbol oder jede Illustration, die exportiert werden muss: empfohlenes Format (SVG für Symbole und Illustrationen, PNG oder WebP für Fotos) und Größe(n) – @1x/@2x/@3x für Raster-Assets, einzelne Datei für Vektorgrafiken.

8. Offene Fragen

Sammle jede OFFENE FRAGE, die in den Abschnitten 2 bis 6 aufgeworfen wurde, in einer nummerierten Liste. Kennzeichne jede:

• BLOCKING – die Implementierung kann ohne eine Antwort nicht korrekt fortgesetzt werden.
• NON-BLOCKING – die Implementierung kann mit einem angegebenen vernünftigen Standardwert fortgesetzt werden, muss aber vor dem Release erneut überprüft werden.

Nummeriere kontinuierlich über die gesamte Spezifikation hinweg (die in den Abschnitten 2–6 inline referenzierten Nummern müssen mit dieser Liste übereinstimmen).

Grenzfälle

• Nur ein Zustand für den gesamten Bildschirm gezeigt. Erwartetes Ergebnis, kein Fehler – das Komponenteninventar wird größtenteils OFFENE FRAGE enthalten. Sage dies explizit, anstatt Hover-/Fokus-/Aktiv-Zustände zu erfinden, um die Tabelle vollständig aussehen zu lassen.
• Kein Token-Set bereitgestellt. Leite einen vollständigen Entwurf eines Token-Sets aus dem Mockup ab und markiere jede einzelne Zeile als NEU-TOKEN (vorgeschlagen). Präsentiere niemals einen abgeleiteten Wert, als ob er mit einem vorhandenen System übereinstimmen würde, das dir nicht gegeben wurde.
• Widersprüchliche Abstände oder Farben zwischen zwei Referenzen desselben Bildschirms. Markiere den Konflikt im relevanten Abschnitt mit beiden genannten Werten. Bilde keinen Mittelwert und wähle nicht einen aus, ohne zu sagen, dass du einen ausgewählt hast und warum.
• Screenshot mit niedriger Auflösung oder beschnitten. Markiere betroffene Werte als (geschätzt). Wenn der unsichere Wert eine Implementierungsentscheidung ändern würde (eine Token-Zuordnung, ein Kontrastverhältnis nahe dem WCAG-Schwellenwert), füge ihn stattdessen als offene Frage hinzu, anstatt ihn als Tatsache zu nennen.
• HTML-Eingabe mit sowohl Inline-Styles als auch CSS-Klassen auf demselben Element. Bevorzuge den berechneten/gerenderten Stil gegenüber einem rohen Inline-Attribut, wenn diese in Konflikt stehen; notiere den Konflikt in Abschnitt 3, wenn er ein zugeordnetes Token betrifft.
• Eine Komponente, die nur einmal vorkommt und kein klares interaktives Angebot hat (z. B. ein statisches Abzeichen). Überspringe Abschnitt 4 für sie vollständig, anstatt acht Zeilen mit nicht zutreffend auszufüllen.

Nach dem Schreiben

Gib am Ende deiner Antwort deutlich an: wie viele Spezifikationsdateien du geschrieben hast, wie viele offene Fragen insgesamt und wie viele davon BLOCKING sind. Diese Zählung ist das eigentliche Signal dafür, ob dieser Bildschirm bereit zur Umsetzung ist.