Wireframes

Was macht Wireframes?

Überblick

Ein UI-Vorschlag ist ein Bild, kein Prosa-Textblock. Zeichne jede Änderung als einfaches Wireframe: das Jetzt neben dem Vorgeschlagen, graue Balken für alles, was gleich bleibt, echte Labels nur auf den diskutierten Elementen und einen Satz Begründung. Es bildet das echte Aussehen der App nicht ab: keine Markenfarben, keine echten Schriftarten, keine Pixelgenauigkeit. Der Nutzer sieht die Änderung auf einen Blick, und das Zeichnen kostet wenige Tokens.

Wann nicht verwenden: Die Änderung ist rein visueller Stil (Farbe, Kontrast, Schriftarten, Abstände) – dann beschreibe sie oder zeige echtes CSS. Oder der Nutzer hat bereits entschieden und dich gebeten, es zu bauen – dann baue es. Oder es ändert sich nichts an Layout, Bedienelementen oder Ablauf.

Die Ausgabe

Eine einzelne, eigenständige HTML-Datei, erstellt nach diesem Schema:

1. Pfad: docs/mockups/YYYY-MM-DD-<thema>.html im Projekt, damit Mockups zusammen mit dem Code bleiben und committet werden können. Wenn das Projekt Mockups bereits in einem anderen mockups/-Ordner ablegt, verwende diesen stattdessen.
2. Head: Kopiere alles von <!doctype html> bis </style></head><body> aus kit.html wortwörtlich. Ändere nur <title>. Verwende ausschließlich Kit-Klassen. Inline style ist nur für Größe und Abstände (width, height, margin, Position eines .menu) erlaubt, niemals für Farbe.
3. <h1> und eine einzeilige .lede.
4. Ein Abschnitt pro Änderung: <h2>N · Ergebnis in den Worten des Nutzers</h2>, dann ein Layout:

Situation	Layout	Labels
Etwas existiert und soll sich ändern	.pair: Jetzt, dann Vorgeschlagen	.lbl.b „Jetzt: was falsch läuft“ · .lbl.g „Vorgeschlagen: was sich ändert“
Die Lösung ist nicht entschieden	.opts: 2–3 Optionen, mit einem kleinen .solo Jetzt darüber, wenn die Sache existiert	.lbl.o „A · Name (empfohlen)“; .why „+ Vorteil · − Nachteil“
Es existiert noch nichts	.solo: Nur Vorgeschlagen	.lbl.g; nummerierte .n Callouts, erklärt in .why
Ein Element über mehrere Zustände oder Breiten	.strip: ein Frame pro Zustand	.lbl „Leer“, „Ladevorgang“, „Fehler“, „Telefon“…; höchstens ein .why unter dem Strip

5. Jede Seite eines .pair und jede Option erhält ein Label (maximal 10 Wörter), ihr Frame oder ihre Frames sowie einen .why-Satz. Verwende zwei Frames auf einer Seite, wenn die Änderung eine Sequenz ist (Menü, dann der Toast danach).

Lies kit.html einmal: Unter dem CSS befindet sich ein Arbeitsbeispiel für jedes Layout und ein Index aller Klassen.

Zeichenregeln

• Nur echten Text, wo die Entscheidung liegt: das geänderte Bedienelement, seine unmittelbaren Nachbarn und den App-Namen oder Breadcrumb zur Orientierung. Alles andere ist .box (Textzeile, width setzen), .img (Bild oder Diagramm) oder eine .row aus grauen Balken.
• Das eine geänderte Bedienelement markieren: .bad (rot gestrichelt) am Problem im Jetzt, .good (durchgehend grün) an der Änderung im Vorgeschlagenen und an dem, was jede Option auszeichnet. Nichts in einem .strip markieren. Umrande das Bedienelement, niemals eine vollbreite Leiste oder einen ganzen Frame, da Frames Umrandungen an ihren Rändern abschneiden.
• Etwas fehlt: zeichne einen leeren gestrichelten Slot an die Stelle, wo es hingehört (<span class="in bad">keine Suche hier</span>), keine Umrandung an einem benachbarten Element.
• Etwa 800px Breite: jede .pair-Spalte ist etwa 380px breit, also halte eine .bar auf etwa 5 Einträge.
• Art der App: Web oder Desktop → .f; schmale Bildschirme oder natives mobil → .phone; Terminal-UI → .f.mono.pad mit echten Textzeilen und grauen Balken für unveränderte Ausgabe.
• Offene Fragen kommen in das .why der jeweiligen Seite, als Frage formuliert.
• Budget: höchstens etwa 15 KB pro Datei. Ein Abschnitt über etwa 1,5 KB zeichnet Inhalte, über die niemand entscheidet – tausche diesen Inhalt gegen graue Balken.

Prüfen vor dem Zeigen

Wenn ein Browser-Tool, das Screenshots machen kann, verfügbar ist, öffne die Datei und schau sie dir an. In der Claude Desktop-App bedeutet das mcp__Claude_Browser__preview_start mit url: file://<absoluter Pfad>, dann mcp__Claude_Browser__computer mit Aktion screenshot. Wenn der Browser die lokale Datei ablehnt, behandle die Seite als ungesehen (siehe unten). Überprüfe, ob jede Umrandung auf dem beabsichtigten Element sitzt, nichts abgeschnitten oder umgebrochen ist und Overlays nicht verdecken, was sie erklären. Korrigiere und schau dann erneut.

Ohne Screenshot-Tool (CLI, Headless, Subagent) lies das Markup noch einmal anhand dieser Prüfungen durch und gib in der Übergabe an, dass die Seite nicht angesehen wurde.

Übergeben

Schreibe im Chat nur:

• die Datei als Markdown-Link relativ zum Projekt-Root;
• eine Zeile pro Abschnitt: Nummer, Titel und Status („fertig“, „wähle A/B/C“ oder die offene Frage);
• die Entscheidungen, die du brauchst: ein Satz pro Entscheidung, deine Wahl und der einzige Hauptgrund.

Die Zeichnungen und ihre .why-Zeilen tragen die Details und die Abwägungen, also beschreibe sie nicht noch einmal. Warte auf die Auswahl des Nutzers, bevor du baust. Ohne einen Nutzer, den du fragen kannst (Subagent, Headless), gib dieselben drei Dinge zurück und stoppe.

Häufige Fehler

Fehler	Stattdessen
Jedes Element labeln	Nur das labeln, was die Entscheidung betrifft
Neugestaltung, die der App entspricht	Kit-CSS wortwörtlich; graue Balken
Ein Absatz pro Zeichnung im Chat	Link, eine Zeile pro Abschnitt, Entscheidungen