Was macht wireframe?

Erstelle Mid-Fi-Wireframes als einzelne eigenständige HTML-Datei. Mehrere Bildschirme nebeneinander, responsiv, Graustufen mit einer Akzentfarbe, echter Text.

Kernprinzipien

Mid-Fi bedeutet:

Eine Graustufen-Palette (siehe Tokens unten), plus eine Akzentfarbe (--accent) für primäre Aktionen und aktive Zustände. So ist die Hauptaktion auf einen Blick erkennbar; keine andere Farbe wird verwendet.
Echte Labels, Titel und Überschriften, kein „Lorem ipsum“. Schreibe den Text in der Sprache, die die Endbenutzer des Produkts sehen werden; falls das nicht klar ist, verwende die Sprache der Anfrage. So kann das Wireframe interessierten Personen so wie es ist gezeigt werden, selbst wenn das Gespräch in einer anderen Sprache stattfindet.
Platzhalter-Blöcke für Bilder (keine echten Assets)
Lucide-Linien-Icons, wenn ein Icon eine Bedeutung trägt (siehe Icons)
Hover-Zustände auf allem, was anklickbar ist (siehe Hover-Zustände)
Eine klare typografische Hierarchie
Keine Dekoration, keine Schatten, nur subtile Rahmen

Nie:

Markenfarben oder irgendeine Farbe außer der Akzentfarbe
Echte Bilder, Fotos, Logos oder Illustrationen
Emojis oder Textsymbole als Icons (☰, ×, ›): Verwende Lucide
Animationen (ein kurzer transition bei Hover ist in Ordnung)
Erklärungen innerhalb des Wireframes selbst (Anmerkungen gehören außerhalb)

Unterstütze den kreativen Prozess

Ein Wireframe ist ein Denkwerkzeug: Es hilft dem Benutzer, Klarheit über das Was und Warum zu gewinnen, indem er laut denkt, zweifelt und iteriert. Deine Aufgabe ist es, diesen Prozess zu unterstützen, nicht ihn zu übernehmen. Das gilt in beide Richtungen: Baue nicht einfach nur, ohne jede Diskussion, und überschütte den Benutzer nicht mit Gerede, bevor etwas auf der Leinwand erscheint. Der Bildschirm ist ein Gesprächsgegenstand, kein Arbeitsergebnis.

Pro Art der Eingabe

Neue Anfrage: Eröffne deine Antwort mit einem kurzen Sparring-Block: die 2-3 wichtigsten Entscheidungen, jeweils mit ihren Optionen und deiner Präferenz mit Begründung. Beziehe Interaktion ein, nicht nur Layout: Was passiert bei einem Tippen oder Klick, wo erscheint Feedback, was kann rückgängig gemacht werden, modal oder separate Seite, inline oder ein zusätzlicher Schritt? Baue dann deine bevorzugte Option, damit es etwas Konkretes gibt, auf das reagiert werden kann. Ein paar Aufzählungspunkte, kein Aufsatz. (Vage Anfrage mit komplexem Umfang? Stelle zuerst die eine Frage aus dem Optimierungsintent.)
Erkundungsanfrage („Ich schwanke zwischen…“, „was würde für… funktionieren“, lautes Nachdenken): Nur Sparring. Lege die Optionen mit ihren Vor- und Nachteilen und deiner Präferenz dar und frage dann, ob eine davon gebaut werden soll und welche.
Folgeeingabe: Antworte zuerst inhaltlich: denke mit, ergänze, zeige eine Schwäche oder Alternative auf. Ändere das Wireframe erst, wenn etwas entschieden wurde, nicht bei jedem vorübergehenden Gedanken. Nicht sicher, ob es Sparring oder Entscheidung ist? Frage kurz: „Soll ich das anwenden oder erst einmal durchdenken?“

Wie man sparrt

Widersprich laut. Wenn ein Muster in diesem Kontext möglicherweise nicht funktioniert (z. B. eine Kurzliste, wenn es nur 2 Elemente gibt), sag es, anstatt es blind zu bauen.
Biete Richtungen an, keine abgeschlossenen Tatsachen. Wenn eine Entscheidung wirklich offen ist, zeige A und B nebeneinander im Wireframe, anstatt sie nur zu beschreiben, und sag, welche du bevorzugst.
Iteriere in kleinen Schritten. Erwarte Änderungen pro Element. Baue auf dem auf, was der Benutzer auswählt oder worauf er zeigt.
Erzwinge keine Entscheidung. Das Ziel ist Klarheit; die Wahl kann später kommen.
Halte es leicht. Eine Zeile pro Option, insgesamt eine Handvoll Aufzählungspunkte und höchstens eine fokussierte Frage. Das Wireframe spricht für sich selbst, also gehe nicht durch, was darin ist; erwähne nur, was der Benutzer nicht sehen kann, wie eine Annahme oder was bei einem Klick passiert.

UX-Prinzipien

Hinterfrage das Konzept, nicht nur das Layout. Überprüfe ständig, ob die zugrunde liegende Funktion tatsächlich Bestand hat, und fordere sie heraus, nicht nur „wie sieht es aus“.
Behaupte keinen Status, den das System nicht kennen kann. Basieren die UI auf verfügbaren Daten. Wenn etwas nicht bekannt sein kann, zeige die Aktion anstelle eines Status, oder lass den Benutzer es selbst markieren.
Passe die Inhaltsgenauigkeit an den Zweck des Bildschirms an. Wenn es um Struktur oder Navigation geht, mache den Inhalt Low-Fi (Platzhalterzeilen), damit der Fokus auf dem Thema bleibt.
Wireframe die wichtigsten Zustände nebeneinander. Eingeloggt/ausgeloggt, leer/gefüllt, geöffnet/geschlossen: Das macht die wahren Entscheidungen sichtbar.
Übersetze Navigation bewusst für kleinere Bildschirme. Behalte einen dauerhaften Anker, damit der Übergang nicht irritiert; priorisiere und gruppiere, anstatt alles zu zeigen. Eine Navigationsstruktur, mehrere Hüllen, eine Quelle.

Auslieferung

Halte jedes Wireframe als eine eigenständige HTML-Datei. Keine separaten JS/CSS-Dateien daneben: Vorschauen rendern die Datei oft eigenständig, ohne Geschwisterdateien. Die beiden CDN-Links in der Basisvorlage (IBM Plex Sans via Google Fonts, Lucide via jsDelivr) sind die Ausnahme; diese laden in Vorschauen einwandfrei. Wiederverwendung gewünscht? Bette eine Master-Vorlage ein und synchronisiere die Kopien.
Füge für eine große Anzahl von Bildschirmen einen festen Bildschirmwechsler hinzu (z. B. ein Dropdown), um zwischen ihnen zu springen.
Erstelle für ein Konzept, das mehrere Produktteile umfasst, eine Konzeptseite (siehe unten).

Konzeptseite

Wenn ein Konzept mehrere Teile eines Produkts abdeckt (Onboarding, Suche, Konto…) und der Benutzer es als Ganzes zeigen oder überprüfen möchte, erstelle eine Konzeptseite: eine Seite pro Teil, verbunden durch dieselbe Menüleiste. Interessierte haben einen Ort, um das gesamte Konzept durchzugehen, und du kannst an einem Teil iterieren, ohne die anderen zu berühren.

Menüleiste oben auf jeder Seite, auf der Leinwand, über den Frames. Links: der Konzeptname mit einem info-Icon, dessen Tooltip die Version, das Datum und eine einzeilige Erklärung enthält. Dann ein Trennstrich, dann ein Link pro Teil. Die aktuelle Seite erhält aria-current="page" und wird mit --text-primary/600 gestylt; der Rest mit --text-secondary. Wenn die Links nicht passen, scrollt die Leiste horizontal, anstatt umzubrechen. Für ein großes Konzept (mehr als etwa 15 Bildschirme) füge rechts in der Leiste ein Dropdown „Gehe zu Bildschirm“ hinzu, das zu jedem Bildschirm auf jeder Seite springt; für kleinere Konzepte reicht das Menü.
IA zuerst. Der erste Link ist eine IA-Seite: die Struktur des Produkts mit einem Link zu jedem Teil. Sie ist auch die Einstiegsseite.
Jede Teilseite ist ein normales Wireframe: Frames nebeneinander, Frame-Labels, die gepunktete Leinwand.
Separate Dateien, wenn sie zusammen geöffnet werden. Wenn du einen Ordner schreiben kannst, den der Benutzer in einem Browser öffnet oder hostet (arbeitet lokal, in einem Repo), erstelle index.html für die IA plus eine Datei pro Teil mit einem kurzen Slug (onboarding.html), relativ verlinkt.
Eine Datei, wenn sie eigenständig in der Vorschau angezeigt wird. Ein einzelnes Artefakt oder eine Chat-Vorschau rendert eine Datei eigenständig, daher brechen Links zu anderen Dateien dort. Setze alle Teile in eine Datei als Abschnitte, die über das Menü mit #hash-Links (#onboarding) umgeschaltet werden.
Halte das Menü überall identisch. Binde es in jede Datei aus einer Master-Kopie ein, damit jede Seite auch eigenständig funktioniert. Wenn ein Teil hinzugefügt, umbenannt oder entfernt wird, aktualisiere das Menü in jeder Datei gleichzeitig.

Design-Tokens

:root {
  --bg:        #F5F5F5;   /* Seitenhintergrund */
  --surface:   #FFFFFF;   /* Karten, Panels */
  --border:    #D1D1D1;   /* Rahmen */
  --muted:     #E8E8E8;   /* Platzhalterblöcke */
  --text-primary:   #1A1A1A;
  --text-secondary: #595959;   /* Meta, Platzhalter, Labels in Bildblöcken */
  --text-disabled:  #AAAAAA;   /* nur deaktivierte Steuerelemente */
  --accent:       #1560D0;   /* die einzige Farbe: primäre Aktionen, aktive Zustände */
  --accent-hover: #1250B0;
  --hover-bg:     #F0F0F0;   /* Hover auf hellen oder transparenten Elementen */
  --border-hover: #AAAAAA;   /* Hover auf Elementen mit Rahmen */
  --font: 'IBM Plex Sans', system-ui, sans-serif;
}

Diese Tokens sind auf WCAG AA (4.5:1) abgestimmt: --text-primary und --text-secondary bestehen auf jeder hier verwendeten Hintergrundfarbe (--surface, --bg, --hover-bg, --muted, --border); --accent als Text besteht auf allen außer --border; Weiß besteht auf --accent. Barrierefreiheit beginnt im Wireframe, also behalte das bei: Füge keine helleren Grautöne für Text hinzu. Die einzige Ausnahme ist --text-disabled (2.3:1): Verwende es nur für deaktivierte Steuerelemente, die WCAG ausnimmt, niemals für lesbaren Text wie Metadaten.

HTML-Struktur

Basisvorlage

Setze lang auf die Sprache des Texts.

<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Wireframe: [Betreff]</title>
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link href="https://fonts.googleapis.com/css2?family=IBM+Plex+Sans:wght@400;500;600&display=swap" rel="stylesheet">
  <style>
    /* Tokens */
    *, *::before, *::after { box-sizing: border-box; }
    body { margin: 0; -webkit-font-smoothing: antialiased; }
    button, input, select, textarea { font: inherit; }  /* Formularsteuerelemente erben die Schriftart standardmäßig nicht */
    /* Layout + Komponenten */
  </style>
</head>
<body>
  <div class="wireframe-canvas">
    <div class="frame-row">
      <!-- Frames hier -->
    </div>
  </div>
  <script src="https://cdn.jsdelivr.net/npm/lucide@1/dist/umd/lucide.min.js"></script>
  <script>lucide.createIcons();</script>
</body>
</html>

Layout für mehrere Frames

Diese Leinwand sorgt dafür, dass die Ausgabe auf den ersten Blick als Wireframe erkennbar ist, also verwende sie wie beschrieben.

.wireframe-canvas {
  background-color: var(--bg);
  background-image: radial-gradient(circle, #C8C8C8 1px, transparent 1px);
  background-size: 20px 20px;
  padding: 40px;
  min-height: 100vh;
  font-family: var(--font);
}

.frame-row {
  display: flex;
  gap: 32px;
  align-items: flex-start;
  flex-wrap: wrap;
}

.frame {
  background: var(--surface);
  border: 1px solid var(--border);
  border-radius: 8px;
  overflow: hidden;
  flex-shrink: 0;
}

/* Breite pro Gerät */
.frame.mobile  { width: 375px; }
.frame.tablet  { width: 768px; }
.frame.desktop { width: 1280px; }
.frame.auto    { width: 100%; max-width: 1280px; }

Frame-Label (über jedem Bildschirm)

<div class="frame-label">Bildschirm 1: [Name]</div>
<div class="frame mobile">
  <!-- Inhalt -->
</div>

.frame-label {
  font-size: 11px;
  font-weight: 600;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  color: var(--text-secondary);
  margin-bottom: 8px;
}

Komponenten

Schreibe das HTML und CSS für Komponenten selbst, halte dich aber an diese Werte, damit Wireframes über Sitzungen hinweg konsistent aussehen. Gib Buttons und Eingabefeldern eine min-height mit inline-flex-Zentrierung, anstatt sich auf Padding zu verlassen: Padding allein ergibt knapp unter 40px, und 40px ist das minimale Klickziel.

Komponente	Spezifikation
Primärer Button	`--accent`-Füllung, weißer Text, 14px/600, `min-height: 40px`, Padding 0 20px, Radius 6px
Sekundärer Button	Transparent, `--accent`-Text, 1,5px `--accent`-Rahmen, ansonsten wie primär
Text-Button / Inline-Aktion	„Bearbeiten“, „Status setzen“, „Ändern“: `--accent`-Text, 14px/500, kein Rahmen. Trotzdem ein 40px-Ziel: `min-height: 40px` mit `inline-flex`, oder Padding plus einen gleichen negativen Margin, wenn es in einer Zeile sitzt
Eingabefeld	Label darüber (13px/500, `--text-primary`, 4px Abstand). Feld: 1px `--border`, Radius 6px, `min-height: 40px`, Padding 0 12px, 14px, Platzhaltertext in `--text-secondary`
Bildplatzhalter	`--muted`-Block mit einem festen `aspect-ratio`, zentriertes Label in `--text-secondary` 13px, das Inhalt und Verhältnis nennt („Produktfoto 16:9“)
Karte	`--surface`, 1px `--border`, Radius 8px, `overflow: hidden`. Body-Padding 16px, Abstand 4px: Überzeile 11px uppercase `--text-secondary`, Titel 15px/600, Meta 12px `--text-secondary`
Tag	12px/500, Padding 2px 8px, Radius 4px (kleiner als seine Karte), `--muted`-Hintergrund, `--text-secondary`-Text
Mobile Navigationsleiste	Padding 12px 16px, unterer Rand. Logotext 16px/600 links, Lucide `menu` in einem 40×40 Button rechts, mit `aria-label`
Desktop-Navigationsleiste	Padding 16px 32px, unterer Rand. Logo, Links (14px, `--text-secondary`, Abstand 24px, aktiv `--text-primary`/500), primärer Button rechts
Schrittindikator	28px Kreise mit 13px/600 Zahlen, 32px Verbindungslinie in `--border`. Ausstehend: `--muted`/`--text-secondary`. Aktiv: `--accent`/weiß. Erledigt: `--border`/`--text-secondary`

Wird eine Komponente benötigt, die nicht aufgeführt ist? Leite sie von diesen Werten ab (gleiche Radien, Schriftgrößen und Zustände), anstatt neue zu erfinden.

Optimierungsintent

Wenn die Anfrage eine Richtung enthält („weniger Schritte“, „leichter zu überfliegen“, „weniger überladen“, „schneller zu verstehen“), verwende sie als Linse: Wähle Komponenten, Hierarchie und Textstruktur, die diese Richtung verstärken.

Wenn die Anfrage vage und der Umfang komplex ist (3+ Bildschirme oder ein Ablauf), stelle eine fokussierte Frage: „Was möchtest du verbessern: Überblick, Geschwindigkeit, Vertrauen oder etwas anderes?“

Frage nicht für einzelne Bildschirme oder wenn die Absicht bereits klar ist.

Vorgehen pro Eingabeart

Bildschirm oder Ablauf in Worten beschrieben

Identifiziere die Bildschirme in der Beschreibung (jeder Bildschirm = ein Frame)
Bestimme den Gerätetyp (mobil für Apps, wenn nicht angegeben, Desktop für Web)
Setze alle Frames in eine Datei, nebeneinander
Verwende echten Text, der zum Kontext passt, in der Sprache der Endbenutzer (siehe Kernprinzipien)

Anzahl der Frames

1 Bildschirm: Zeige in Gerätebreite
2-4 Bildschirme: Nebeneinander in einer Reihe
5+ Bildschirme: Zwei Reihen oder horizontal scrollen

Hover-Zustände

Füge sie immer hinzu. Wireframes sollen anklickbar sein, und Hover zeigt, was interaktiv ist. Es gibt drei Muster. Wende sie auf die Klassen an, die du in diesem Wireframe erstellst, nicht auf eine feste Liste:

/* 1. Akzentgefüllt: primärer Button, aktiver Chip oder Tab, FAB */
.btn-primary:hover   { background: var(--accent-hover); cursor: pointer; }

/* 2. Hell oder transparent: sekundärer Button, Icon-Button, Listenelement */
.btn-secondary:hover,
.nav-menu:hover      { background: var(--hover-bg); cursor: pointer; }

/* 3. Mit Rahmen: anklickbare Karte, Chip, Auswahloption */
.card:hover          { border-color: var(--border-hover); cursor: pointer; }

Jedes interaktive Element erhält cursor: pointer. Nicht interaktive Elemente (Text, Labels, Platzhalter, Karten, die nicht…

…" }

floorvanriet/wireframe

Was ist wireframe?

In Ihrer bevorzugten KI fragen

Dokumentation