UX Flow & Wireframer

Sag das, um den Skill zu aktivieren

---
name: ux-flow-wireframer
description: Entwirft User-Flows und Low-Fidelity-Wireframes als Text-Layouts und Mermaid-Diagramme, bevor visuelles Design oder Code entsteht.
---

Dieser Skill macht aus einer Feature-Idee einen durchdachten User-Flow mit Low-Fidelity-Wireframes, bevor die Designphase beginnt.

## Wann dieser Skill aktiviert wird
- Ein Signup-, Onboarding-, Checkout- oder Anfrage-Flow soll vor dem visuellen Design durchdacht werden.
- Jemand bittet um Wireframes, Screen-Skizzen oder ein Flussdiagramm für einen Funnel oder ein Feature.
- Ein bestehender Flow soll auf Sackgassen oder unnötige Schritte geprüft werden.

## Workflow
1. Kläre drei Eckdaten: Nutzer (Vorwissen, Gerät, Kontext), das eine Ziel des Flows, Erfolgskriterium. Fehlt etwas, stelle maximal 3 Rückfragen.
2. Liste alle Einstiegspunkte (Ad, Suche, E-Mail, interner Link) und definiere genau einen Endzustand als Erfolg.
3. Skizziere den Happy Path als nummerierte Liste: pro Schritt Screen-Name, Nutzerabsicht, eine primäre Aktion. Streiche Schritte ohne Information oder Entscheidung.
4. Ergänze pro Entscheidungspunkt die Abzweigungen: Validierungsfehler, Abbruch, Zurück, leerer Zustand. Jeder Fehlerpfad braucht einen Rückweg in den Flow.
5. Zeichne den Flow als Mermaid-Flowchart (flowchart TD): Rechtecke für Screens, Rauten für Entscheidungen, Pfeil-Labels für Nutzeraktionen.
6. Baue pro Screen ein Text-Wireframe als ASCII-Box: Header, Inhaltsblöcke in Lesereihenfolge, primärer CTA, sekundäre Aktionen. Echte Beispieltexte, kein Lorem ipsum.
7. Notiere pro Screen die Zustände leer, laden, Fehler, Erfolg, je eine Zeile, wo relevant.
8. Prüfe den Gesamtflow: Schritte bis zum Ziel zählen und jede Pflichtangabe hinterfragen (geht sie auch später?).
9. Liste offene Produktentscheidungen separat auf, statt sie still selbst zu treffen.

## Output-Format
Ein Markdown-Dokument mit: 1) Flow-Ziel und Annahmen, 2) Mermaid-Flowchart, 3) Schritt-Tabelle (Nr, Screen, Nutzerabsicht, primäre Aktion, Fehlerfälle), 4) ASCII-Wireframes pro Screen mit Anmerkungen, 5) offene Fragen.

## Qualitätsregeln
- Jeder Screen hat genau einen primären CTA, formuliert als Verb ("Demo anfragen", nicht "Senden").
- Kein Pfad endet in einer Sackgasse, auch Fehler- und Abbruchpfade führen weiter.
- Formulare fragen nur ab, was der nächste Schritt zwingend braucht.
- Wireframes enthalten echte Beispieltexte in der Zielsprache, keine Füller wie "Text hier".
- Mermaid-Diagramm und Schritt-Tabelle nutzen identische Screen-Namen.
- Annahmen und offene Entscheidungen sind explizit markiert, nichts ist still erfunden.

Skill teilen