Einen Flow in einen klickbaren, gecodeten Prototyp verwandeln
Statische Mockups können die Frage „Wie fühlt sich das eigentlich an?" nicht beantworten. Der AI in Design Report 2026 fand heraus, dass Codegenerierung der größte Jahres-über-Jahr-Sprung war, und etwa die Hälfte der Designer gibt an, KI-generierten Code bereits in Produktion gebracht zu haben. Einen Flow zu beschreiben und dafür einen funktionierenden Einzeldatei-Prototyp zu bekommen, lässt Sie echte Interaktionen an einem Tag statt in einem Sprint testen.
Du bist Frontend-Prototyper. Baue einen einzelnen, in sich geschlossenen klickbaren Prototyp, damit ich testen kann, wie sich ein Flow anfühlt. Flow: {{flow_description}}. Design-Vorgaben (Farben, Typoskala, Abstände, Schlüsselkomponenten): {{design_constraints}}. Einzuschließende Zustände: {{states}}. Anforderungen: - Eine Datei: HTML mit Inline-CSS und minimalem Vanilla-JavaScript, keine externen Abhängigkeiten, lauffähig durch einfaches Öffnen im Browser. - Barrierefreiheit eingebaut: semantisches HTML, beschriftete Formularelemente, logische Überschriftenreihenfolge, vollständige Tastaturbedienbarkeit, sichtbare Fokuszustände und ein Textkontrast von mindestens 4,5:1. - Realistischer, aber offensichtlich fiktiver Platzhalterinhalt — niemals echte Nutzerdaten oder echte Namen. - Mache den Hauptpfad durchgängig klickbar; stub sekundäre Aktionen mit einem sichtbaren Hinweis „im Prototyp nicht umgesetzt". Vorgaben: Baue nur die Screens und Felder, die ich beschrieben habe — erfinde keine zusätzlichen Funktionen, Flows oder Texte. Das ist ein Wegwerf-Prototyp für Usability-Tests, kein Produktionscode, also Klarheit vor Cleverness. Liste nach dem Code die getroffenen Barrierefreiheits-Entscheidungen sowie alle Stellen auf, die ich vor dem Testen manuell prüfen sollte.
Tragen Sie Ihre Angaben ein — der Prompt aktualisiert sich live. Dann kopieren.
Geliefert wurde eine einzelne index.html mit dreistufigem Checkout (Warenkorb, Versand, Bestätigung), tastaturnavigierbar, mit sichtbaren Fokusringen und einer 4,5:1-Kontrastpalette passend zu Ihren Tokens. Enthält die Zustände leerer Warenkorb, Laden und Karte abgelehnt; die Aktion „Rabattcode einlösen" ist mit dem Hinweis „im Prototyp nicht umgesetzt" gestubbt. **Barrierefreiheits-Entscheidungen:** semantische Form- und Label-Elemente bei jedem Eingabefeld, eine aria-live-Region für den Fehler, Überschriften in korrekter Reihenfolge. **Vor dem Testen prüfen:** Tab-Reihenfolge im custom Dropdown, und ob der Fehlerzustand einen farbunabhängigen Hinweis trägt (er nutzt ein Icon plus Text neben Rot).
Der komplette Arbeitsablauf
- Beschreiben Sie den Flow, die Design-Vorgaben und die Zustände, die Sie testen wollen.
- Generieren Sie den Prototyp und öffnen Sie ihn im Browser.
- Führen Sie eine Barrierefreiheitsprüfung durch (Tastatur, Kontrast, Screenreader) und beheben Sie Lücken vor dem Testen.
- Testen Sie mit Nutzern und iterieren Sie den Prompt, um den Flow zu verfeinern.
- Übergeben Sie verifizierte Spezifikationen ans Engineering — schicken Sie Wegwerf-Prototyp-Code nie ohne Review in Produktion.
Worauf Sie achten sollten
KI-generierte Oberflächen scheitern regelmäßig an WCAG — schwacher Kontrast, vager Alt-Text, nicht-semantisches Markup —, und KI-Tools sind keine Barrierefreiheits-Tools. Die rechtliche Verantwortung nach ADA, Section 508 und WCAG bleibt bei Ihnen, prüfen Sie also jeden generierten Screen.
Prototyp-Code ist zum Lernen gedacht und ein Wegwerfprodukt, kein Produktions-Build; ihn ohne Engineering-Review auszuliefern, öffnet Tür und Tor für Sicherheits-, Performance- und Wartbarkeitsprobleme.
Fügen Sie niemals vertrauliche oder unveröffentlichte Designs oder echte Nutzerdaten in Consumer-KI-Tools ein — verwenden Sie in Prototypen fiktive Platzhalterinhalte.
Woher das stammt
Jeder Anwendungsfall auf dieser Website beruht auf echten Berichten, die UX-Designer aus der Praxis geteilt haben — nichts davon ist von uns erfunden.