Wireframe-Skizzenvorlage
Handgezeichnete Low-Fidelity-Wireframes, die explizit wie Entwürfe aussehen – um Layout-Feedback einzuladen, „nicht auslieferbar“ zu signalisieren oder IA zu dokumentieren, ohne sich auf visuelles Design festzulegen.
⚠️ Wähle ZUERST das Grundgerüst
Der häufigste Fehler dieser Fähigkeit: Das Modell übernimmt die Pinselstriche (Wackeln, Strichelung, Handschrift), schreibt aber die falsche Dokumentstruktur – z. B. 3 isolierte App-Bildschirme, obwohl ein Multi-Screen-Flussdokument benötigt wurde, oder stopft eine Sitemap mit redaktionellen Abbildungen voll.
Bevor du eine einzige Zeile schreibst, erkläre in deiner Antwort, welches Grundgerüst du verwendest und warum. Ordne die Wörter des Benutzers einem der folgenden zu:
| Benutzer sagt | Grundgerüst | Warum |
|---|---|---|
| Zeitung / Magazin / Landing / offizielle Seite / Broschüre / Einzelseite / One-Pager / redaktionell | A. Einzelseite redaktionell | Eine lange Seite, Abschnitte stapeln sich, inhaltsdicht |
| App / Mobil / Telefon / Desktop-App / SaaS-Flow / Benutzerpfad / Anmelde-Flow / Checkout-Flow / Multi-Screen / Multi-Page / Registrierung / Login / Onboarding / Einstellungen / Tab / Formular-Flow | B. App-Multi-Screen-Flow | Mehrere Bildschirme, Navigation, Zustände, Auslöser |
| Informationsarchitektur / IA / Sitemap / Site Map / Flussdiagramm / Beziehungsgraph / Knotengraph / Datenfluss / Zustandsmaschine / Berechtigungsmatrix | C. IA / Sitemap-Diagramm | Knoten + Kanten, keine echten Bildschirme |
| unklar / Benutzer hat nichts gesagt / beides möglich | Frage den Benutzer vor der Auswahl – verwende keinen Standard | — |
Wenn der Benutzer ein Thema genannt hat, aber keinen Hinweis auf das Grundgerüst, frage nach, welches gemeint ist. Das falsche auszuwählen bedeutet, die Arbeit doppelt zu machen.
Grundgerüst A – Einzelseite redaktionell
foolscap-wireframe.html ist die Referenz für dieses Grundgerüst. Verwende es, wenn das Artefakt eine einzelne scrollbare Seite ist (Zeitung, Magazinseite, Landingpage-Wireframe, Broschüre, Einzelseiten-PRD-Illustration).
Erforderliche Abschnitte (in dieser Reihenfolge; 1–2 können weggelassen werden, aber der Rhythmus muss erhalten bleiben):
- Kopfzeile / Banner – Titel, Ausgabe/Version, Datum
- Hero-Feature – ein großer Lead-Block mit Überschrift + Einleitung + handgezeichneter Illustration-Platzhalter
- 3–5 Inhaltsabschnitte – jeder mit eigenem h2, Mix aus Textabbildungen und Skizzenillustrationen
- Sidebar / Kurzinfo / Listenblock – kurze Einträge, dichter Satz, unterbricht den Rhythmus
- CTA / Anmeldung / Footer
Dichte: Strebe die Inhalte-pro-Quadratzoll der Foolscap-Referenz an – spärliche Einzelseiten-Wireframes wirken wie ein Stummel, nicht wie ein Entwurf.
Grundgerüst B – App-Multi-Screen-Flow ⛔ HARTE MINDESTANFORDERUNGEN
foolscap-wireframe.html ist nicht die Referenz für dieses Grundgerüst – leihe dir nur die SVG-Filter, den Schriftstapel und die gestrichelte Zellen-Ästhetik. Die Dokument-Struktur muss aus der folgenden Checkliste zusammengestellt werden.
Erforderliche Abschnitte (MÜSSEN alle vorhanden sein – sonst ist die Seite unvollständig)
- Deckblatt – App-Name + Version + Rolle/Persona + 1-zeiliger Umfang („MVP / Beta / v0.3 / nur Ausgaben-Tracking, kein Investieren“)
- Sitemap / Navigationsdiagramm – visueller Baum oder Raster, das alle Bildschirme und ihre Beziehungen zeigt. Keine Liste – ein echtes Diagramm mit Kästchen + Linien.
- 6–8+ Kernbildschirme als
figure-Blöcke. Für eine Ausgaben-Tracking-App sind das mindestens: Start/Begrüßung → Startseite (Übersicht) → Eintrag hinzufügen (Betrag → Kategorie → Notiz → Speichern) → Rechnungsdetails → Monatsstatistiken → Kategorieverwaltung → Budget-Einstellungen → Profil/Einstellungen. 3 Bildschirme sind kein Wireframe-Dokument, sondern eine Skizzenprobe. - Mindestens 1 Flusspfeil-Diagramm, das den Benutzerpfad über die Bildschirme zeigt (z. B. „Startseite → „+“ tippen → Eintrag hinzufügen → Speichern → Toast → zurück zur Startseite“). Setze nicht nur einen einzelnen
↓zwischen die Bildschirme – schreibe den Auslöser auf den Pfeil. - Mindestens 1 Zustandsvariante für jeden Bildschirm, der einen Zustand hat: leer / laden / Fehler / Erfolg. Wähle die Bildschirme aus, bei denen es darauf ankommt (Listenseite → leerer Zustand; Formular → Fehlerzustand).
- Schlussbemerkungen – offene Fragen / TBD-Liste / Versionsprotokoll / zu treffende Entscheidungen für die nächsten Schritte
Anforderungen pro Bildschirm
Jeder Bildschirmblock muss haben:
- Figure-Nummer –
Abb. 02(beim Schreiben auf Chinesisch die lokalisierte Form verwenden), fortlaufend, aus Flussdiagrammen referenziert - Einzeilige Verantwortung – „Eintrag hinzufügen · wird vom „+“-Button auf der Startseite erreicht; zeigt beim Speichern einen Toast und kehrt zur Startseite zurück“
- Auslöser-Anmerkungen – welche Einstiegspunkte führen hierhin, welche Ausgänge wohin
- Randnotizen – mindestens 1 handschriftlicher Seitenkommentar pro nicht-trivialem Bildschirm (Einschränkung, Grenzfall, „TBD“, offene Frage)
Layout
- Vertikaler Stapel von Bildschirmen mit explizitem Pfeil + Auslöser-Beschriftung zwischen jedem (kein passiver
↓) - Oder horizontaler Flussstreifen mit Bildschirmen in links-nach-rechts-Reihenfolge – gut geeignet für lineare Abläufe wie Onboarding/Checkout
- Tippe Bildschirme nicht in einem Raster ohne Flussangabe an – das ist eine Bildschirmgalerie, kein Flussdokument
Inhaltsdichte-Rotlichtbereiche
- < 5 Bildschirme → lehne ab, bitte den Benutzer um weitere Abläufe oder reduziere den Umfang ehrlich
- Keine Sitemap → lehne ab, das Dokument ist ohne sie nicht lesbar
- Keine Zustandsvarianten → markiere zumindest die Leer-/Fehlerstellen, auch wenn du sie nicht zeichnest („leerer Zustand: siehe Abb. 04a / TBD“)
- Keine Randnotizen vorhanden → du hast den Pinsel, aber nicht die Sprache übernommen; gehe zurück und annotiere
Grundgerüst C – IA / Sitemap-Diagramm
Reines Strukturdokument – keine echten Bildschirme, nur Knoten-Kanten-Diagramme der Informationsarchitektur, Navigation, Datenflüsse oder Zustandsmaschinen.
Erforderliche Abschnitte:
- Titel + Legende – was die Kästchen bedeuten, was die Linientypen bedeuten (durchgezogen = direkte Navigation, gestrichelt = bedingt, doppelt = Datenbindung)
- Hauptdiagramm – der Baum/Graph selbst, zentral, groß
- Pro-Knoten-Kurzspezifikation – für nicht offensichtliche Knoten, 1–3 Zeilen, was dort lebt
- Berechtigungs-/Rollenmatrix falls zutreffend
- Offene Fragen am Ende
Wackeln + Handschrift gelten weiterhin. Kästchen-und-Linien-Layout, viel Weißraum, einzelne Akzentfarbe für die Hervorhebung des „aktuellen Pfads“ / „Standard“.
Sprache der Randnotizen (Grundgerüste B & C müssen verwenden; A optional)
Randnotizen unterscheiden ein echtes Low-Fidelity-Wireframe von einem „High-Fidelity-Entwurf, der vorgibt, Low-Fi zu sein“. Verwende diese Techniken:
| Markierung | Wann | Wie |
|---|---|---|
| Seitennotiz | Einschränkung oder Begründung | <aside class=“margin“> in handschriftlicher Schriftart, Akzentfarbe, in den Rand gezogen |
| Kreis + Pfeil | Auf ein bestimmtes Element hinweisen | SVG <circle> + <path> mit filter:url(#wobble), Akzentstrich |
| TBD / ? | Unentschiedene Entscheidung | Handschriftliches „TBD“ in Akzentfarbe, manchmal in einem wackeligen Kreis |
| Durchgestrichen | Alte Idee zur Kontextbehaltung | text-decoration:line-through + leichte Drehung transform:rotate(-1deg) |
| Unterstreichen + ! | Wichtig / muss besprochen werden | Wellenförmige SVG-Unterstreichung unter dem Begriff |
| Nummerierter Hinweis | Verweis auf eine Legendentabelle unten | Eingekreiste Ziffer in Akzentfarbe, mit <ol>-Legende am Abschnittsende |
Randnotizen-Tintenfarbe = der eine Akzent (Vorlage verwendet helles Blau). Körperfarbe bleibt monochrom.
Handgezeichnete Markierungen
Low-Fidelity-Wireframes stützen sich stark auf an Ort und Stelle gezeichnete Markierungen, nicht auf echte Symbole oder Fotos. Baue eine kleine Bibliothek am Anfang der Datei auf:
- X-Kasten – Bildplatzhalter:
<rect>+ zwei sich kreuzende<line>, alle unterfilter:url(#wobble) - Wellenlinien-Text – Textplatzhalter: 3–5
<path>horizontaler Kringel in abnehmender Breite - Strichsymbole – Navigationssymbole als 8–16 px SVG-Pfade (Haus, Plus, Diagramm, Zahnrad), 1,4 px Strich + Wackeln
- Ladespinner – wackeliger Kreis mit einer Lücke, keine Animation für statische Ergebnisse erforderlich
- Avatar-Kreis – Kreis + Initialen in handschriftlicher Schriftart
- Diagrammgerüste – wackelige Balken/Punkte/Linien, keine Achsenbeschriftungen außer der Abbildungsnummer
Importiere keine Symbol-Schriftart, Lucide, Heroicons usw. Echte Symbole kämpfen gegen das Wackeln und brechen sofort die Low-Fi-Registrierung.
Erforderliche Lektüre
Lies zuerst diese SKILL.md von Anfang bis Ende. Öffne foolscap-wireframe.html erst, wenn du ein Grundgerüst ausgewählt hast.
Dann:
- Grundgerüst A → lies foolscap vollständig, sowohl für die Struktur als auch das Pinselvokabular
- Grundgerüst B → öffne foolscap NUR zum Kopieren: die
<filter>SVG-Turbulenzwerte, das gepunktete Hintergrundmuster, die gestrichelten/wellenförmigen Trennlinienpfade, den handschriftlichen Schriftstapel. Kopiere nicht die Masthead/Hero/Langtext-Struktur – falsches Grundgerüst. - Grundgerüst C → wie B, nur Pinsel-Extraktion
Kopiere niemals die Platzhalter-Redaktionskopie, Bildunterschriften oder Klassennamen von Foolscap en bloc.
Designstrategie
Lege den Fidelity-Umfang zu Beginn fest:
- reine Struktur (nur Kästchen + Beschriftungen, kein echter Text außer Feldnamen) → maximales Wackeln, spärlichster Inhalt
- Struktur + Beispielinhalt (Platzhalter-Überschriften, echte Beschriftungen, gefälschte Zahlen wie ¥3.280) → moderates Wackeln, mehr Dichte
- Struktur + Anmerkungen (Pfeile, Randnotizen, „TBD“, Auslöser-Beschriftungen) → Wackeln + Randnotizen + Akzentfarben-Hervorhebungen
Wähle eine aus und halte sie im gesamten Dokument durch – das Mischen von Fidelities wirkt inkonsistent. Grundgerüst B will fast immer Stufe 3.
Layout-Präferenz
Bevorzuge:
- rein weißen Papierhintergrund – keine gelbe Legal-Pad-Vortäuschung
- monochrome Tinte (Schwarz + 2–3 Grautöne), höchstens ein Akzent (helles Blau oder Rot) für Randnotizen und „aktuell/Standard“-Hervorhebung
- eine handschriftliche CJK-Schriftart (Ma Shan Zheng / Long Cang) + eine handschriftliche lateinische Schriftart (Caveat / Kalam)
- Mono-Stapel (Großbuchstaben, enge Buchstabenabstände) für „Beschriftungen“ / „Abbildungsnummern“ / „Hinweise“
- gestrichelte oder wellenförmige Trennlinien zwischen Abschnitten – niemals saubere durchgezogene Linien
- konsistente Wackelintensität – nicht pro Element hoch- und runterdrehen; ein globaler Filter + vielleicht ein „stärkerer“ für winzige Formen
- nummerierte Abbildungen („Abb. 01“; beim Schreiben auf Chinesisch die lokalisierte Form verwenden) für alles, was von anderer Stelle im Dokument referenziert wird
- großzügige Seitenränder, um Platz für Randnotizen zu schaffen
Vermeide:
- echte Produktionssymbole oder polierte SVG-Illustrationen (sie kämpfen gegen den Skizzenrahmen)
- Farbfotos (verwende Skizzenplatzhalter – X-Kästen oder Wellenlinien-Text)
- Emojis
- das Mischen von Wireframe mit High-Fidelity-Komponenten auf derselben Seite
- das Aufzwingen des Wackelfilters auf jedes Element, bis die Seite laut wird – Wackeln ist eine Würze, keine Grundlage
- einen einzelnen
↓als Flussanmerkung – schreibe den Auslöser auf den Pfeil - nur 3 isolierte Bildschirme in einem App-Szenario auszuliefern – das ist eine Bildschirmprobe, kein Wireframe-Dokument
Antipatterns (Selbstprüfung vor der Auslieferung)
- App-Szenario, aber keine Sitemap → ablehnen, eine hinzufügen
- App-Szenario, aber < 5 Bildschirme → ablehnen, erweitern oder Umfang ehrlich reduzieren
- Bildschirme nur durch
↓ohne Auslöser-Beschriftung verbunden → jeden Pfeil annotieren - Keine Randnotizen / TBD / eingekreiste Markierungen vorhanden → du hast die Pinselstriche, aber nicht die Sprache übernommen; gehe zurück und annotiere
- Lucide/Heroicons/Emoji/echte Symbol-Schriftarten verwendet → durch handgezeichnete SVG-Pfade ersetzen
- Wackelintensität springt herum → auf 1–2 Filter-IDs vereinheitlichen
- Fehlende Abbildungsnummern, obwohl sie aus Flussdiagrammen referenziert werden → Nummerierung hinzufügen
- Text zu „fertig“ (vollständiger Marketingtext / endgültige Produktformulierung) → auf Platzhalter zurückfallen („Einzeilige Beschreibung von Funktion A“)
- Helles gelbes Legal-Pad-Hintergrund verwendet → zurück zu schlichtem weißem Papier wechseln
- Mehr als 1 Akzentfarbe → reduzieren
Plattform / Größe
Wird als Webseite gerendert, typischerweise als langer Screenshot für die Einbettung in PRDs / Notion / Confluence / Lark-Dokumente erfasst. Nicht für die Laufzeitinteraktion gedacht – es ist ein statisches Ergebnis, das handgezeichnet aussieht.
Für Grundgerüst B ist eine Seitenbreite von 720–960 px gut geeignet (entspricht der Lesebreite in Dokumenttools). Für Grundgerüst A, 960–1100 px (redaktionelles Format). Für Grundgerüst C, oft breiter (1200+), um Sitemaps unterzubringen.