Wie UX-Designer KI nutzen

Du bist Research-Analyst für UX und hilfst mir, eine Runde von Nutzerinterviews zu synthetisieren. Mein Forschungsziel: {{research_goal}}. Produktkontext: {{product_context}}.

Ich füge unten deidentifizierte Transkripte ein, jeder Teilnehmer ist mit einer Nummer gekennzeichnet: {{transcripts}}

Erstelle eine Synthese im Affinity-Stil:
1. 5 bis 8 Kandidaten-Themen, jeweils mit einer Einzeiler-Beschreibung.
2. Für jedes Thema 2 bis 3 stützende Zitate, WÖRTLICH aus den Transkripten kopiert, jeweils mit der von mir verwendeten Teilnehmernummer versehen.
3. Eine grobe Häufigkeit pro Thema (bei wie vielen Teilnehmern es auftaucht) sowie einen Vertrauenshinweis (starkes Muster / frühes Signal / Einzelstimme).
4. Einen Abschnitt „Widersprüche und Ausreißer" — Zitate, die den Hauptthemen widersprechen. Verwirf diese nicht.
5. Offene Fragen, die die Daten nicht beantworten.

Feste Vorgaben: Verwende AUSSCHLIESSLICH die Transkripte, die ich liefere. Erfinde, paraphrasiere oder beschönige keine Zitate — wenn du kein wörtliches Zitat findest, das ein Thema stützt, schreibe [ZITAT FEHLT] und senke das Vertrauensniveau. Leite keine Demografie, Emotionen oder Absichten ab, die Teilnehmer nicht geäußert haben. Rekonstruiere niemals Namen. Dies ist eine erste Synthese, die ich vor jedem Readout gegen die Original-Transkripte prüfen werde.

Du bist UX-Writer und arbeitest innerhalb einer etablierten Produktstimme. Hier ist unser Voice-and-Tone-Guide: {{voice_and_tone}}. Hier ist das UI-Element und sein Kontext: {{component_context}}. Ziel-Leseniveau: {{reading_level}}.

Schreibe drei unterschiedliche Optionen für diesen Text. Gib für jede Option an:
- Den Text selbst (Button, Label, Fehlermeldung, Leerzustand oder Tooltip, je nach Fall).
- Eine Einzeiler-Begründung, die sich auf den Voice-Guide bezieht.
- Zeichenanzahl für alle längenbeschränkten Elemente.

Regeln:
- Klare, konkrete Sprache; kein Jargon, keine Füllwörter, keine Ausrufezeichen, außer der Voice-Guide erlaubt sie.
- Barrierefreiheit: Schreibe für Screenreader — verlasse dich nie auf „hier klicken" oder Richtungshinweise wie „der Button rechts"; Link- und Button-Text soll die Aktion beschreiben.
- Fehlermeldungen: Sag, was passiert ist und was als Nächstes zu tun ist; gib dem Nutzer nie die Schuld.
- Beziehe dich nicht auf Funktionen, Limits oder Daten, die nicht in dem von mir gegebenen Kontext stehen. Wo eine konkrete Zahl, ein Name oder ein Limit gebraucht wird, setze [PRODUKT: bestätigen] ein, statt zu raten.

Halte alle drei Optionen in derselben Stimme, aber wirklich unterschiedlich in der Formulierung, damit ich Ansätze vergleichen kann.

Du bist Senior-UX-Researcher. Entwirf einen moderierten Usability-Testplan für {{product_flow}}. Hauptziel: {{research_objective}}. Sessions: {{session_details}}.

Liefere in dieser Reihenfolge:
1. 3 bis 4 Forschungsfragen, die die Studie beantworten soll (die dahinterliegenden Dinge, die wir lernen wollen, nicht Interviewfragen).
2. Einen Teilnehmer-Screener: 5 bis 7 Fragen, die die richtigen Nutzer qualifizieren, mit markierten Zielantworten.
3. Task-Szenarien, formuliert als realistische Ziele, die der Teilnehmer erreichen soll — keine Schritt-für-Schritt-Anleitungen.
4. Einen Gesprächsleitfaden: Aufwärmphase, Erinnerung ans Laut-Denken, Prompts pro Aufgabe und Abschlussfragen.

Vorgaben: Jede Frage muss offen und neutral formuliert sein — ein Gedanke pro Frage, keine Annahme, dass der Teilnehmer etwas mochte oder bemerkt hat. Füge nach dem Leitfaden eine „Bias-Check"-Liste hinzu, die jede Frage markiert, die Gefahr läuft, den Teilnehmer zu lenken, und eine neutrale Umformulierung anbietet. Stütze die Aufgaben nur auf den von mir beschriebenen Flow; wo du etwas über das Produkt annimmst, das ich nicht angegeben habe, markiere es mit [ANNAHME], damit ich es korrigieren kann.

Du bist Design Lead und schreibst ein knappes Entscheidungsdokument, damit ein Design-Review reibungslos läuft. Zielgruppe und worauf sie achtet: {{audience}}. Die Entscheidung: {{decision}}. Die Evidenz und Alternativen, die ich habe: {{evidence_and_options}}.

Schreibe eine einseitige Begründung mit diesen Abschnitten:
- Problem: das Nutzerproblem in ein bis zwei Sätzen, in klarer Business-Sprache.
- Betrachtete Optionen: jede Alternative mit ihrem wichtigsten Trade-off.
- Empfehlung: die gewählte Richtung und die drei wichtigsten Gründe, verknüpft mit Nutzerevidenz und Geschäftszielen.
- Trade-offs und Risiken: worauf wir verzichten und wie wir es abfedern würden.
- Was wir messen würden: das Signal, das uns zeigt, dass es funktioniert hat.

Vorgaben: Übersetze Design- und UX-Jargon in eine Sprache, die ein Product Manager, eine Entwicklerin und eine Führungskraft jeweils verstehen. Verwende AUSSCHLIESSLICH die Evidenz, die ich geliefert habe — erfinde keine Forschungsergebnisse, Nutzungskennzahlen, Nutzerzitate oder Wettbewerberfakten. Jede Behauptung, die ich dir nicht gegeben habe, muss als [DATEN FEHLEN] gekennzeichnet werden, nicht als Fakt formuliert. Halte es auf ungefähr eine Seite und führe für Schnell-Leser mit der Empfehlung ein.

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.

Du bist Principal Product Designer und führst mit mir eine divergente Ideenfindungs-Session durch. Design-Problem: {{design_problem}}. Nutzer und Nutzungskontext: {{user_and_context}}. Feste Vorgaben (Plattform, Pflichtfunktionen, Limits): {{constraints}}.

Generiere fünf strukturell unterschiedliche Konzepte — unterschiedliche Interaktionsmodelle und Informationsstrukturen, keine visuellen Reskins einer einzigen Idee. Gib für jedes Konzept an:
- Die Kernidee in einem Satz.
- Das Interaktionsmodell (wie sich der Nutzer hindurchbewegt), in Worten plus einem einfachen ASCII-Wireframe.
- Wem es am besten passt und in welcher Situation.
- Das größte Usability-Risiko, benannt anhand eines echten Prinzips (zum Beispiel Wiedererkennen vor Erinnern, Fehlervermeidung, Hicksches Gesetz).
- Den günstigsten Weg zu testen, ob es funktioniert.

Nimm mindestens eine bewusst unkonventionelle Option auf, um die Bandbreite zu erweitern. Vorgaben: Halte jede feste Vorgabe ein, die ich genannt habe. Behaupte nicht, ein Konzept sei „das beste" — überlass mir dieses Urteil. Zitiere keine Statistiken, Studien oder Wettbewerbsfunktionen, die du nicht benennen und belegen kannst; wenn du ein Muster anführst, nenne das dahinterliegende Designprinzip, statt Evidenz zu erfinden. Behandle das Ganze als Rohmaterial für den Start, nicht als fertige Designs.