Anweisungen rund um UX: Ankündigung der App, Verzicht auf die App und Verhalten im Dialog

1. Warum UX überhaupt per Anweisungen steuern

Aus Sicht von ChatGPT ist Ihre App lediglich eine Sammlung zusätzlicher Tools und Widgets. Für den Nutzer ist sie jedoch eine eigene Oberfläche, die plötzlich mitten im Gespräch erscheint. Wenn man das Verhalten des Modells nicht steuert, kann es zu zwei extremen Szenarien kommen.

In einem Fall ignoriert GPT die App und versucht, „alles mit Worten zu lösen“. Der Nutzer bittet darum, ein Geschenk auszuwählen, und das Modell gibt statt des Starts von GiftGenius einen langen Textaufsatz mit Empfehlungen „aus dem Bauch“ aus. Manchmal ist das okay, aber Sie haben die App nicht dafür geschrieben, dass sie im Regal verstaubt.

Im anderen Fall überstrapaziert GPT die App. Auf jede Kleinigkeit wie „Was kann Ihr Service?“ startet sie das Widget, rendert ein nebulöses Formular, der Nutzer erschrickt und schließt das ganze Spektakel. Aus UX‑Sicht wirkt das sehr aufdringlich.

Daher ist die Logik einfach: Das Verhalten muss explizit festgelegt werden – so wie Sie die JSON‑Schema eines Tools oder die Props einer React‑Komponente festlegen. Der System‑Prompt (und begleitende Anweisungen) ist hier Ihr „UX‑Protokoll“. Darin beschreiben Sie, wann und wie der Assistent:

• den Start der App ankündigt;
• bewusst keine App startet, sondern in Text antwortet;
• sich verhält, nachdem das Widget bereits ein Ergebnis gezeigt hat;
• die Bitte des Nutzers „ohne Apps“ respektiert.

All das hat nichts mit Marketing oder Smalltalk‑Stil zu tun. Es beeinflusst real, wie oft Ihre App aufgerufen wird und wie wohl sich der Nutzer fühlt.

Im Folgenden gehen wir Schritt für Schritt durch: wie der Assistent den Start der App ankündigen sollte, in welchen Fällen man das Widget lieber nicht anbietet, wie man sich verhält, nachdem die App gearbeitet hat, wie man explizite Bitten des Nutzers zum Dialogformat respektiert und wie man all diese Regeln sauber im System‑Prompt festhält.

2. Ankündigung der App: wie das Modell über das Widget „vorwarnt“

Wenn ChatGPT beschließt, die App zu verwenden, ändert sich die Oberfläche: Im Chat erscheint eine Widget‑Karte, manchmal im Vollbild, es erscheinen Buttons und andere UI‑Elemente. Wenn der Assistent einfach kommentarlos ein Widget zeigt, kann der Nutzer überhaupt nicht verstehen, was passiert ist und woher dieser Block kommt.

Gute Praxis ist daher, zunächst kurz in Text zu erklären, was gleich passiert, und erst danach die App zu starten. Das ist ähnlich wie wenn der Browser fragt: „Neues Fenster öffnen?“ oder eine mobile App warnt: „Gleich bitten wir um die Kameraberechtigung.“

Arten von Ankündigungen

Man kann grob drei Ankündigungsstile unterscheiden.

Der erste – sanfter Vorschlag. Der Assistent sagt etwas wie: „Ich kann für Sie die App GiftGenius öffnen, die anhand Ihrer Parameter Geschenke vorschlägt. Soll ich sie öffnen?“ und wartet auf „Ja/Nein“. Das funktioniert gut in Szenarien, in denen der Nutzer den Service erst kennenlernt oder sensibel auf einen UI‑Wechsel reagiert.

Der zweite – selbstbewusste Empfehlung. Wenn Ihre App die Hauptoberfläche des Produkts ist, können Sie schreiben: „Ich starte jetzt die App GiftGenius und zeige einige Geschenkoptionen als Karten.“ Der Assistent kann einen Widerspruch weiterhin berücksichtigen, handelt aber standardmäßig entschlossener.

Der dritte – neutrale Mitteilung. In diesem Fall teilt der Assistent einfach mit: „Ich starte die App GiftGenius zur Geschenkauswahl …“, ohne lange Erklärungen. Dieser Stil ist sinnvoll, wenn der Nutzer Ihre App bereits oft gesehen hat und ihr Erscheinen erwartet.

Wichtig ist, dass Sie all diese Varianten in den System‑Prompt einbetten sollten. Das Modell erfindet keine UX‑Formulierungen aus dem Nichts, wenn Sie ihm den Rahmen vorgeben.

Mini‑Codebeispiel: Abschnitt zur Ankündigung im System‑Prompt

Stellen Sie sich vor, Ihr Next.js‑Template enthält die Datei appDefinition.ts, in der Sie den System‑Prompt für die App festlegen:

// app/appDefinition.ts
export const systemPrompt = `
# Rolle
Du bist die ChatGPT App GiftGenius und hilfst bei der Geschenkauswahl.

# Dialog und UX — Ankündigung der App
Wenn du dich entscheidest, das GiftGenius-Widget zu starten,
erkläre zuerst in ein bis zwei Sätzen,
dass sich gleich eine App mit einer Geschenkeauswahl öffnet
und wie sie dem Nutzer hilft.
`;

Das ist noch kein vollständiger Vertrag, aber selbst ein so kleiner Einschub erhöht die Vorhersagbarkeit des Verhaltens deutlich.

Wann die Ankündigung besonders wichtig ist

Je komplexer Ihr UI ist, desto wichtiger ist es, den Start vorher zu verbalisieren. Wenn das Widget nur drei Geschenkkarten zeigt, ist das ein relativ sanfter Kontextwechsel. Öffnen Sie jedoch einen mehrstufigen Assistenten mit Filtern, Budget, Kategorien usw., sollte der Nutzer verstehen, warum sich der Dialog plötzlich in eine „kleine Web‑App im Chat“ verwandelt hat.

Auch offizielle UX‑Richtlinien betonen, dass der Assistent Text und UI ausdrücklich verbinden sollte, anstatt stumm ein Widget an die Antwort anzuhängen.

3. Wann man die App bewusst nicht anbieten sollte

Der häufigste Fehler in frühen Entwicklungsphasen einer App ist der klassische Effekt „Wer nur einen Hammer hat, für den sieht alles wie ein Nagel aus“. Weil es GiftGenius als schickes Feature gibt, zieht das Modell es in jeden Dialog. Der Nutzer fragt: „Was kann Ihre App eigentlich?“, und ChatGPT schon: „Ich starte GiftGenius …“, obwohl der Mensch einfach zwei erklärende Zeilen wollte.

Um das zu vermeiden, sollten Sie im System‑Prompt Situationen beschreiben, in denen die App lieber nicht angeboten wird. Im Folgenden einige typische Szenarien.

• Erstens einführende Fragen. Wenn jemand etwas schreibt wie „Was macht GiftGenius?“ oder „Wie arbeiten Sie?“, sollten die Anweisungen zunächst eine kurze Text‑Erklärung verlangen – ohne UI‑Start. Das Widget lenkt hier nur ab.
• Zweitens zu allgemeine oder vage Anfragen. Der Nutzer schreibt „Erzähl mir etwas über Geschenke zu Neujahr“ – das ist eher eine Lernfrage als eine konkrete Auswahl. Der Assistent kann kurz allgemeine Prinzipien erklären, Rückfragen stellen und die App erst anbieten, wenn konkrete Parameter vorliegen (Budget, Empfänger, Kategorie).
• Drittens Anfragen außerhalb des App‑Domains. Wenn jemand sagt: „Hilf mir beim Schreiben eines Lebenslaufs“, Ihre App aber für Geschenke gedacht ist, ist das richtige Verhalten: ehrlich wie ein normaler ChatGPT antworten und nichts starten. Man kann dezent erwähnen, wofür die App gedacht ist, sie aber nicht aufdrängen, wenn sie offensichtlich irrelevant ist.
• Viertens explizite Ablehnung von UI. Wenn der Nutzer schreibt: „Bitte keine Apps öffnen, erklär es einfach in Text“, muss sich das Modell fügen – selbst wenn es ein ideales Szenario für die App sieht.

Tabelle: Anfrage-Typ und Verhalten des Assistenten

Wir ergänzen den System‑Prompt um Regeln zum Verzicht auf die App

Führen wir denselben systemPrompt fort und fügen einen Block dazu hinzu, wann die App nicht gestartet werden soll:

export const systemPrompt = `
# Rolle
Du bist die ChatGPT App GiftGenius und hilfst bei der Geschenkauswahl.

# Wann das Widget NICHT starten
Wenn der Nutzer nur fragt, was der Service kann,
oder eine allgemeine theoretische Frage zu Geschenken stellt,
antworte zuerst in Textform und starte die App nicht.

Wenn die Anfrage nichts mit Geschenkauswahl zu tun hat,
antworte wie ein normaler ChatGPT und schlage GiftGenius nicht vor.

Wenn der Nutzer ausdrücklich bittet, keine Apps zu verwenden,
respektiere das unbedingt und arbeite nur im Chat.
`;

Solcher Text führt zu konkreten Entscheidungen des Modells in Grenzfällen, in denen es sonst das UI „zu sehr bevorzugen“ könnte. Wir haben festgelegt, wann die App nicht nötig ist. Nun ist die Gegenseite wichtig: Was der Assistent tun soll, wenn das Widget bereits gearbeitet hat und der Nutzer das Ergebnis sieht.

4. Verhalten nach der Nutzung der App: follow‑up und Abschluss des Szenarios

Im Modul zum Widget haben Sie bereits gesehen, wie follow‑up‑Nachrichten helfen, den Dialog fortzusetzen, nachdem das UI gearbeitet hat. Das Widget zeigt Karten, und darunter schreibt der Assistent etwa: „Ich habe folgende Geschenkoptionen für einen Kollegen bis 50 $ gefunden. Soll ich günstigere zeigen oder die Kategorie ändern?“ und bietet Buttons mit beliebten Aktionen an.

Jetzt ist unsere Aufgabe, dieses Verhalten in den Anweisungen zu verankern, statt auf die „Intuition“ des Modells zu vertrauen.

Was der Assistent nach dem Widget tun sollte

Im Idealfall passieren mehrere Dinge.

• Zuerst fasst der Assistent das Ergebnis der Arbeit der App kurz in Worten zusammen. Selbst wenn das Widget zehn Karten gezeigt hat, ist es hilfreich zu schreiben: „Ich habe 4 Geschenkoptionen für einen Kollegen im Budget bis 50 $ zusammengestellt. Darunter sind eine Tasse mit individuellem Druck, eine Zimmerpflanze, ein Set guten Kaffees und ein stilvolles Notizbuch.“
• Danach schlägt er die nächsten Schritte vor. Hier helfen vorab durchdachte follow‑up‑Formulierungen: „Möchten Sie günstigere Optionen sehen?“, „Sollen wir nach Interessen eingrenzen?“, „Nur die anzeigen, die in Ihrer Region verfügbar sind?“ Genau diese Phrasen können Sie im Widget in sendFollowUpMessage verwenden und dem Modell im System‑Prompt empfehlen.
• Und schließlich, wenn der Nutzer das Szenario explizit beendet („Danke, das reicht“), „schließt“ der Assistent das Thema behutsam: Er erkennt an, dass die Aufgabe gelöst ist, und bietet Hilfe bei etwas anderem an.

Flussdiagramm: Frage → Widget → follow‑up

Zur Veranschaulichung kann man sich das Verhalten des Assistenten als einfachen Zustandsautomaten vorstellen.

flowchart TD
    U[Der Nutzer formuliert eine Aufgabe] --> G[GPT entscheidet: App starten?]
    G -->|Ja| A[Ankündigt den Start der App]
    A --> W[Das GiftGenius-Widget wählt Optionen aus]
    W --> S[Der Assistent fasst das Ergebnis zusammen]
    S --> F[Der Assistent bietet Follow-up-Optionen an]
    F -->|Der Nutzer wählt eine Aktion| G
    G -->|Nein, App nicht starten| T[Textantwort ohne UI]
    F -->|"Der Nutzer sagt \"Danke\""| E[Der Assistent schließt das Szenario ab und bietet weitere Hilfe an]

Diesen Ablauf beschreiben wir faktisch in Worten im System‑Prompt.

Codebeispiel: follow‑up aus dem Widget

Auf der UI‑Seite können Sie bereits follow‑up‑Nachrichten senden. Der Vollständigkeit halber hier ein einfaches Beispiel für eine Komponente, die nach einem Klick das Modell bittet, „das Budget zu erweitern“:

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Zeig Optionen mit etwas höherem Budget"
        );
    };

    return <button onClick={onClick}>Ich möchte teurere Optionen</button>;
}

Jetzt fügen wir dem System‑Prompt Text hinzu, der dem Modell Hinweise gibt, wie solche follow‑up‑Nachrichten zu verarbeiten sind.

// Fortsetzung von systemPrompt
const followUps = `
# Verhalten nach dem Start der App
Nachdem das Widget die Geschenkeliste gezeigt hat,
beschreibe das Ergebnis kurz in Textform.

Schlage anschließend 1–3 verständliche nächste Schritte vor
(z. B.: günstigere anzeigen, Budget ändern, Kategorie wechseln).
Wenn das Widget eine Follow-up-Nachricht sendet,
nutze sie als Hinweis für den nächsten Schritt.
`;

Technisch ist das einfach ein String. Aus UX‑Sicht ist es die Grundlage für ein vorhersehbares Szenario.

5. Respekt für die Absichten des Nutzers

Alles, was wir oben besprochen haben, sind Ihre Produkt‑Erwartungen an das Verhalten der App. UX‑Anweisungen funktionieren schlecht, wenn das Modell den Nutzer nicht „hören“ kann. Selbst die perfekt gestaltete App sollte zurückstehen, wenn jemand ausdrücklich bittet, das Interaktionsformat nicht zu ändern.

Es gibt einige typische Situationen.

• Wenn der Nutzer ausdrücklich sagt, dass er keine Apps starten möchte („Kein UI, erklär mir einfach, was ich kaufen soll“), sollte der Assistent das als strikte Einschränkung verstehen und nicht versuchen, sie zu umgehen. Man kann höflich sagen: „Okay, ich antworte nur in Text“, und das dann auch einhalten.
• Wenn der Nutzer befürchtet, dass etwas automatisch gestartet wird, ist es hilfreich, ihm ein Gefühl der Kontrolle zu geben. Zum Beispiel: „Ich kann die App zur Geschenkauswahl öffnen, aber wenn Sie möchten, können wir die Optionen auch einfach im Chat besprechen. Was ist Ihnen lieber?“ Hier geben Sie ausdrücklich eine Wahl.
• Wenn der Nutzer schreibt „Ich bin am Handy, starte keine komplexen Formulare“, ist das ebenfalls Teil des Kontexts. Der Assistent sollte das berücksichtigen und sich z. B. auf eine kurze Ideensammlung und Rückfragen beschränken.

Respekt in den Vertrag einbetten

All das lässt sich kompakt im System‑Prompt festhalten:

export const respectBlock = `
# Priorität der Nutzerintentionen
Berücksichtige stets die ausdrücklichen Wünsche des Nutzers
zum Kommunikationsformat.

Wenn er bittet, keine Apps oder Widgets zu starten,
schlage GiftGenius nicht vor und starte es nicht,
selbst wenn es helfen würde, die Aufgabe zu lösen.
Unterstütze stattdessen in Textform.
`;

So legen Sie klar fest, „wer das Sagen hat“ im Dialog. Spoiler: Es ist nicht Ihr Stolz auf ein schönes UI, sondern der Mensch auf der anderen Seite des Bildschirms.

6. Wie man UX‑Anweisungen im System‑Prompt und in der Dokumentation strukturiert

Wir haben bereits viele Verhaltensregeln skizziert – von der Ankündigung der App bis zu follow‑up‑Nachrichten und der Achtung des Dialogformats. Jetzt ist nicht nur was wir dem Modell sagen wichtig, sondern auch wie das im System‑Prompt und in der Doku formuliert ist.

Der System‑Prompt in einer realen App wächst schnell. Wenn man ihn als fortlaufenden literarischen Text schreibt, findet sich nach einer Woche niemand mehr zurecht. Behandeln Sie ihn daher wie eine technische Spezifikation oder ein README: strukturieren Sie ihn.

Gute Praxis ist, den Prompt in mehrere logische Abschnitte mit Überschriften zu gliedern. Zum Beispiel „Rolle und Verantwortungsbereich“, „Wann die App verwenden“, „Wann die App nicht verwenden“, „Dialog und UX“, „Sicherheit und Einschränkungen“. Innerhalb jedes Abschnitts in einfachen, eindeutigen Sätzen schreiben.

Noch besser ist es, den System‑Prompt in eine separate Datei neben dem Code auszulagern, statt ihn als Stringliteral mitten in eine Komponente zu pressen. So lässt er sich leichter reviewen, Änderungen vergleichen und mit Produkt‑ oder Rechtsteams besprechen.

Beispiel für die Organisation des System‑Prompts im Code

Eine Möglichkeit ist, Prompt‑Teile in separaten Strings zu halten und zu einem Ganzen zusammenzusetzen:

// app/prompt/role.ts
export const roleSection = `
# Rolle
Du bist die ChatGPT App GiftGenius.
Du hilfst dem Nutzer, Geschenke passend zur Aufgabe und zum Budget auszuwählen.
`;

// app/prompt/ux.ts
export const uxSection = `
# Dialog und UX
Bevor du das GiftGenius-Widget startest,
erkläre kurz, dass sich gleich eine App mit Geschenkkarten öffnet.
Starte die App nicht bei allgemeinen oder theoretischen Fragen,
wenn der Nutzer nicht ausdrücklich um eine Auswahl bittet.
Fasse nach der Arbeit des Widgets das Ergebnis in Textform zusammen
und schlage 1–3 nächste Schritte vor.
`;

// app/appDefinition.ts
import { roleSection } from "./prompt/role";
import { uxSection } from "./prompt/ux";

export const systemPrompt = `
${roleSection}
${uxSection}
`;

Eine solche Aufteilung hilft, über Anweisungen wie über separate Module nachzudenken: UX‑Teil, Sicherheit, Arbeit mit Tools usw. Das ist besonders nützlich, wenn Sie neue Funktionen hinzufügen und das Verhalten mit mehreren Teams abstimmen müssen.

Außerdem lohnt es sich, die Dokumentation zur App (internes README, Confluence, Notion) mit diesen Abschnitten zu synchronisieren. Dort können Sie in Alltagssprache erklären, warum Sie die App genau so ankündigen und warum Sie sie für Probefragen nicht starten. Fixieren Sie separat, wie die follow‑up‑Formulierungen aussehen sollen. So werden neue Teammitglieder nicht versuchen, den Prompt zu „reparieren“, ohne zu verstehen, was Sie vorhatten.

7. Praxis: Wir schreiben den UX‑Teil für unseren GiftGenius neu

Fassen wir alles zu einem einigermaßen vollständigen Beispiel für einen System‑Prompt zusammen. Angenommen, wir hatten einen sehr knappen System‑Prompt:

export const systemPrompt = `
Du bist die App GiftGenius.
Wähle Geschenke für den Nutzer aus.
`;

Dieser Text sagt nichts darüber aus, wann die App zu starten ist, wie sie anzukündigen ist und was nach dem Widget zu tun ist. Fügen wir Schritt für Schritt UX‑Anweisungen hinzu.

Zuerst grenzen wir Verantwortungsbereich und Arbeitsformat klar ab:

const role = `
# Rolle
Du bist die ChatGPT App GiftGenius.
Deine Aufgabe ist es, dem Nutzer 3–7 relevante Geschenke
für ein vorgegebenes Budget, einen Empfänger und einen Anlass vorzuschlagen.
Du kannst das GiftGenius-Widget für die visuelle Auswahl verwenden.
`;

Dann beschreiben wir, wie der Start anzukündigen ist:

const announce = `
# Ankündigung der App
Wenn du meinst, dass das GiftGenius-Widget besser hilft,
erkläre zuerst in ein bis zwei Sätzen,
dass sich gleich eine App mit Geschenkkarten öffnet
und dass der Nutzer sie ansehen und filtern kann.
Starte die App erst danach.
`;

Fügen wir Regeln hinzu, wann die App nicht zu starten ist:

const noApp = `
# Wann die App nicht verwendet wird
Wenn der Nutzer nur fragt, was der Service kann,
oder allgemeine theoretische Informationen zu Geschenken möchte,
antworte in Textform und starte GiftGenius nicht.

Wenn die Anfrage nichts mit Geschenken zu tun hat (z. B. Lebenslauf oder Code),
antworte wie ein normaler ChatGPT und biete die App nicht an.

Wenn der Nutzer darum bittet, keine Apps zu verwenden,
betrachte das als verbindliche Einschränkung.
`;

Und schließen wir mit dem Verhalten nach der Widget‑Nutzung ab:

const afterWidget = `
# Verhalten nach dem Widget
Nachdem das Widget Geschenkoptionen gezeigt hat,
beschreibe das Ergebnis kurz mit eigenen Worten.
Schlage dem Nutzer 1–3 nächste Schritte vor
(z. B.: Budget ändern, nach Interessen filtern,
nur günstigere Optionen anzeigen).

Wenn das Widget eine Follow-up-Nachricht gesendet hat,
nutze sie als Hauptsignal für den nächsten Schritt.
`;

Der finale System‑Prompt kann so aussehen:

export const systemPrompt = `
${role}
${announce}
${noApp}
${afterWidget}
`;

Das wirkt bereits wie eine Verhaltensspezifikation und nicht wie ein „Wunsch ans Universum“. In den nächsten Modulen ergänzen Sie diesen Vertrag um Anweisungen zu Sicherheit, Halluzinationen, Kommerz und anderen Freuden des Entwickleralltags – aber der UX‑Teil liegt bereits als Fundament.

8. Typische Fehler bei der Einrichtung von UX‑Anweisungen

Fehler Nr. 1: „Die App ist immer besser als Text“.
Manche Entwickler sind so stolz auf ihr Widget, dass sie vom Modell verlangen, es bei jeder Gelegenheit aufzurufen. Am Ende bekommt der Nutzer die App auch dort, wo er einfach nur fragen wollte „Was ist das überhaupt?“. Das Modell wird aufdringlich, und die Leute fangen an, die App zu ignorieren. Der richtige Ansatz ist, explizit Szenarien festzuhalten, in denen die App nicht nötig ist, und diese Fälle zu respektieren.

Fehler Nr. 2: fehlende explizite Ankündigung vor dem Start der App.
Wenn der Assistent stumm ein Widget startet, versteht der Nutzer nicht, woher der UI‑Block kommt und was er damit tun soll. OpenAI‑Richtlinien und praktische Erfahrung zeigen: ein bis zwei Sätze „Ich öffne gleich eine App, die X macht“ verbessern den UX stark und reduzieren Verwirrung.

Fehler Nr. 3: zu aggressives erneutes Anbieten der App.
Manchmal bietet die App nach jeder Antwort erneut das Widget an: „Möchten Sie die App noch einmal öffnen? Und jetzt? Und jetzt?“ Das wird schnell zu Spam. Besser in den Anweisungen festhalten, dass nach der ersten Nutzung der App der Kontext entscheidend ist: erneut nur anbieten, wenn der Nutzer die Parameter der Aufgabe klar ändert oder selbst um „mehr anzeigen“ bittet.

Fehler Nr. 4: Ignorieren einer ausdrücklichen Ablehnung von Apps.
Formulierungen wie „bitte ohne Apps“ oder „vom Handy aus sind Formulare unpraktisch“ sollten als strikte Einschränkungen verstanden werden. Wenn das Modell weiterhin die App aufdrängt, verliert der Nutzer das Vertrauen – in den Assistenten und in Ihr Produkt. Im System‑Prompt lässt sich das mit zwei bis drei Sätzen leicht fixieren, doch viele vergessen es.

Fehler Nr. 5: fehlendes Kurzfazit und follow‑up‑Nachrichten nach dem Widget.
Manchmal zeigt das Widget brav Optionen, und der Assistent schweigt danach. Der Nutzer sieht das UI, weiß aber nicht, wie es weitergeht. Kein Text, keine Frage, keine Buttons mit beliebten Aktionen. Ein solcher Ablauf wirkt unvollständig und bricht die Dialogkohärenz. Schreiben Sie in die Anweisungen, dass nach dem Widget immer ein kurzes Textfazit und 1–3 klare nächste Schritte folgen sollen.

Fehler Nr. 6: Vermischung von Produkt‑UX und „allgemeinem ChatGPT‑Stil“ in einem Absatz.
Manchmal wird der System‑Prompt zum langen literarischen Text: „Sei freundlich, nutze Emojis, scherze gelegentlich, wenn passend. Und ja, starte vielleicht irgendwann die App.“ In einem solchen Text sind reale UX‑Regeln schwer zu erkennen. Besser separate Abschnitte mit klaren Überschriften ausweisen: „Rolle“, „Dialog und UX“, „Wann die App verwenden“, „Wann die App nicht verwenden“. Das hilft sowohl dem Modell als auch den Menschen, die nach Ihnen mit diesem Prompt arbeiten.