UX‑Richtlinien von OpenAI: wann man App anzeigt und wie man den Dialog nicht „kapert“

1. Chat‑first: ChatGPT ist zuerst ein Chat und erst danach Anwendungen

In den ersten 6 Modulen haben wir alle Aspekte der App durchgearbeitet: von UI und MCP bis Debugging und Deployment. Jetzt gehen wir noch einmal alle Seiten durch, nur tiefer. Sie dachten doch nicht, dass alles so einfach wird, oder?

Und wir beginnen mit UX, genauer gesagt mit den offiziellen UI‑Requirements und UX‑Guidelines. Sie wollen doch, dass Ihre App das Review besteht, nicht wahr? Großartig, dann starten wir mit dem Spannendsten: dem wichtigsten mentalen Shift für Frontend‑Entwickler, die an SPA/Next.js gewöhnt sind: ChatGPT ist in erster Linie ein dialogisches Interface, und die App ist ein Gast in diesem Dialog. Nicht umgekehrt.

OpenAI formuliert es in den Guidelines so: Apps erweitern, was der Nutzer tun kann, ohne den Gesprächsfluss zu unterbrechen. Ein Widget ist nicht ein neuer Browser‑Tab, sondern eine behutsame Einbettung in den Chat, die dort Struktur gibt, wo reiner Text mühsam wird.

Am einfachsten merkt man es über eine Rollentrennung.

Rollen von GPT und App

Innerhalb von ChatGPT gibt es zwei „Charaktere“:

GPT bleibt der Haupterzähler. Er erklärt in Worten, was gleich passiert, warum er die App vorschlägt, was die Buttons bedeuten, und fasst das Ergebnis der Widget‑Arbeit zusammen. Die App konzentriert sich wiederum auf den visuellen Teil und Handlungen: Auswahloptionen, Filter einstellen, Schritt‑für‑Schritt‑Assistenten durchlaufen.

Eine sehr wichtige Regel, die man sich wie ein Mantra wiederholen sollte: alle wichtigen Entscheidungen müssen ausdrücklich in der Textantwort von GPT ausgesprochen werden, selbst wenn der Nutzer im UI klickt. Nutzer müssen nicht jede Zeile im Widget lesen — die Schlüsselkonsequenzen (zum Beispiel „wir haben die Bestellung aufgegeben“ oder „Sie haben diese Parameter gewählt“) sollten im Chat benannt werden.

2. Wann eine App wirklich nötig ist: Kriterien für die Anzeige

Technisch können Sie das Widget nach jeder Nachricht aufrufen. Aus UX‑Sicht ist das jedoch, als würde man bei jeder Eingabe in ein input einen Vollbild‑Dialog öffnen. Funktioniert — ja. Damit leben — nein.

OpenAI und das Apps SDK schlagen ein einfaches Prinzip vor: Eine App ist dann sinnvoll, wenn das Denken damit einfacher ist als nur mit Text.

Anfragen mit Struktur und wiederholbarem Szenario

Eine App passt gut, wenn die Nutzeranfrage schon auf Struktur hindeutet:

• „Finde 5 Geschenkideen für einen Kollegen bis $50.“
• „Vergleiche diese drei Tarifpläne.“
• „Stelle eine 3‑Tage‑Route für Tokio zusammen.“
• „Zeige meine Aufgabenliste für die Woche und hilf, Prioritäten zu setzen.“

In all diesen Fällen gibt es klare Entitäten (Geschenke, Tarife, Reisetage, Aufgaben), mit denen man arbeiten muss, sowie Schritte: auswählen, filtern, vergleichen, bestätigen. Hier sind UI mit Karten, Checkboxen und Filtern gerechtfertigt und sogar hilfreich.

Beispiele für GiftGenius

Nehmen wir unseren Lieblingshelden GiftGenius. Eine typische Anfrage:

Ich muss Geschenke für 10 Hochzeitsgäste auswählen, mit unterschiedlichen Budgets und Interessen.

Reiner Text von GPT kann 10 separate Listen aufzählen, aber das ist mühsam zu lesen. Viel angenehmer ist es:

• eine Tabelle der Gäste, Budgets und Interessen zu zeigen,
• die Möglichkeit zu geben, „günstiger/teurer“ zu filtern,
• einen Satz von Karten für jeden Gast auszugeben.

Hier ist die App praktisch Pflicht: zu viele Entitäten und Parameter, um das nur per Text zu halten.

Im Unterschied dazu:

Was schenke ich meinem Bruder für 5000 ₽?

Das ist eine einstufige, kleine Frage. GPT kann mit 3–5 Ideen im Text antworten, und nur wenn der Nutzer bittet „zeig Optionen, wo ich nach Hobby und Alter filtern kann“, kann man sanft zur App übergehen.

Mini‑Heuristik

Es ist hilfreich, eine einfache Tabelle im Kopf zu behalten:

Ausführlich über Inline und Fullscreen sprechen wir in den nächsten Vorlesungen, aber schon jetzt ist klar: Die App ist ein Werkzeug für strukturierte, mehrstufige Aufgaben — nicht für jedes „mir ist traurig, was soll ich tun?“.

3. Wann die App stört: Modus „reden“ und Nachdenken

Wir haben gesehen, wann die App das Leben wirklich erleichtert und dem Dialog Struktur gibt. Es gibt aber auch die Kehrseite: Situationen, in denen jegliches UI nur stört.

So viel Gerede über „lassen Sie uns UI zeichnen“ führt oft zu einem Reflex: „oh, der Nutzer hat etwas gefragt — Zeit, das Widget zu starten“. Das ist der Moment, in dem Sie im Store‑Review einen UX‑Abzug kassieren können.

Es gibt eine ganze Klasse von Anfragen, in denen die App meist schadet:

1. Der Nutzer ist im „einfach reden“-Modus. Das sind philosophische Überlegungen, persönliche Fragen, Karriere‑Dilemmata, therapeutische Gespräche. In solchen Szenarien erwartet der Nutzer eine Textunterhaltung, Rückfragen, manchmal Empathie. Karten und Filter einzublenden fühlt sich hier wie ein Spam‑Banner an.
2. Einstiegsfragen zum Service. Wenn jemand schreibt „Erzähl, was GiftGenius kann“, will er einen Überblick, nicht sofort UI. Hier erklärt GPT besser zunächst kurz den Zweck der App, bringt eventuell Beispielanfragen und bietet erst dann behutsam an, das Widget auszuprobieren.
3. Allgemeine theoretische Fragen. „Wie wählt man Geschenke für Introvertierte?“ oder „Wie funktioniert ein Loyalty‑System in Shops?“ — das ist ein lehrender, kein transaktionaler Kontext. GPT kann eine gute Textantwort geben und am Ende unaufdringlich hinzufügen: „Wenn Sie möchten, kann ich GiftGenius öffnen und ein paar konkrete Optionen heraussuchen.“

Überall dort, wo UI keinen neuen Mehrwert bringt, sondern nur Text dupliziert, sollte man im Chat bleiben. Das ist der Respekt vor den Nutzerintentionen, von dem UX‑Gurus so gern schreiben.

4. Wie man die App anbietet: auto‑launch versus „bescheidene Übergabe“

Selbst wenn Sie sicher sind, dass eine App sinnvoll ist, bleibt die Frage „wie starten“. Grobe Variante: Das Widget öffnet sich überraschend im Fullscreen ohne Vorwarnung. Normale Variante: GPT erklärt zuerst in Worten, was passieren wird, und fragt nach Zustimmung oder informiert zumindest.

In den UX‑Dokumentationen zu ChatGPT Apps werden zwei Muster hervorgehoben: auto‑launch und suggestion (humble handoff).

Auto‑launch: wenn der Nutzer es ausdrücklich verlangt

Auto‑launch ist angebracht, wenn der Nutzer eine klare Intention geäußert hat:

Starte GiftGenius.
Öffne die Einstellungen von GiftGenius.
Zeig meinen Geschenke‑Warenkorb in GiftGenius.

Die Regeln sind hier einfach:

1. GPT schreibt kurz etwas wie „Ich öffne GiftGenius …“.
2. Das Modell ruft sofort das Tool/Widget auf.

Der Dialog kann so aussehen:

Nutzer: Starte GiftGenius, ich möchte ein Geschenk für einen Freund aussuchen.
GPT: Ich öffne den GiftGenius‑Assistenten zur Geschenkauswahl.
[Das GiftGenius‑Widget erscheint Inline oder im Fullscreen]

Der Autostart ohne weitere Rückfragen ist gerechtfertigt, weil der Nutzer selbst um das „Öffnen“ gebeten hat.

Suggestion (humble handoff): wenn die Intention nicht eindeutig ist

In vielen Fällen kennt der Nutzer Ihre App überhaupt nicht. Er schreibt:

Ich brauche eine Idee für ein Geburtstagsgeschenk für einen Kollegen, das Budget ist klein.

Das richtige Muster ist hier:

1. GPT analysiert die Anfrage und erkennt, dass die App helfen kann.
2. GPT stellt 1–2 Rückfragen oder schlägt die App direkt im Text vor.
3. Erst nach Zustimmung oder einem klaren Hinweis startet es das Widget.

Beispiel:

Nutzer: Ich brauche eine Idee für ein Geburtstagsgeschenk für einen Kollegen, das Budget ist klein.
GPT: Ich kann mit Ideen direkt helfen oder die App GiftGenius öffnen, wo wir Optionen nach Budget und Interessen auswählen. Möchten Sie nur Tipps oder die App ausprobieren?
Nutzer: Lass uns die App probieren.
GPT: Ich öffne GiftGenius, um Geschenkoptionen auszuwählen.
[Das Widget erscheint]

Dieser Ansatz betont: die Initiative liegt weiterhin beim Nutzer, und die App ist eine Option, kein aufgedrängtes Banner. Das passt gut zum Prinzip „Respect user’s intent“ aus den UX‑Guidelines.

Mini‑Beispiel „Intent‑Klassifizierer“ in TypeScript

Stellen wir uns vor, dass Sie auf Ihrer Backend‑Seite die Nutzeranfrage bereits grob klassifizieren (nicht zu verwechseln mit GPT selbst, das ist Hilfslogik):

// Vereinfachter Typ der Nutzerintentionen
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Welchen Trigger für die App wir verwenden wollen
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // „Starte GiftGenius“
  if (intent === 'ask_gift_advice') return 'suggest'; // nicht eindeutige Anfrage
  return 'avoid';                                // normaler Chat, ohne App
}

Diese Logik ruft das Widget nicht selbst auf — sie ist eher eine Möglichkeit, Ihren UX‑Ansatz zu formalisieren. Danach übersetzen Sie diese Regeln in den system‑prompt und in die Beschreibungen der App, damit sich das Modell entsprechend verhält.

5. Wie man den Dialog nicht „kapert“: gute und schlechte Muster

OpenAI formuliert in der Dokumentation und in UX‑Artikeln für ChatGPT Apps ziemlich klar, was man nicht tun sollte: den Dialog nicht „stehlen“. Also den Chat nicht in einen Kanal zur Promotion Ihres Interfaces verwandeln.

Anti‑Patterns

Das schmerzhafteste ist das „Überraschungs‑Widget“. Der Nutzer führt ein tiefes Gespräch und plötzlich nimmt ein Fullscreen‑App die ganze Fläche ein, ohne dass er darum gebeten hat. Der Kontext geht verloren, das Gefühl von Kontrolle ebenso.

Ein weiteres häufiges Problem ist, die App als Werbung zu verwenden. Zum Beispiel fragt der Nutzer eine theoretische Frage, und das Modell antwortet: „Ich öffne zuerst unser Super‑Widget, dort steht alles“, und zeigt ein UI, dessen Hälfte Marketingtexte sind. Die offiziellen Guidelines nennen solche Szenarien ausdrücklich „poor use cases“.

Das dritte Anti‑Pattern sind häufige, unnötige Wechsel zwischen UI und Text. Wenn man bei jeder kleinen Rückfrage die App öffnet und schließt, erinnert der Dialog an eine flackernde Lichterkette. Nutzer, besonders mobil, sind schnell ermüdet.

Gute Praktiken

In allen Szenarien, in denen Sie die App doch öffnen, halten Sie sich an drei einfache Regeln.

Erstens: ankündigen. Lassen Sie GPT klar sagen, dass es die App öffnet und warum. Zum Beispiel: „Ich öffne jetzt den GiftGenius‑Assistenten, um Optionen in Kartenform zu zeigen.“ Das sind 1–2 Zeilen, aber sie verändern das Gefühl des Wechsels vollständig.

Zweitens: erklären, was im UI zu tun ist. Nicht alle Nutzer sind an ein neues Interface gewöhnt. GPT kann hinzufügen: „Unten sehen Sie Geschenkkarten, Sie können blättern und bei jeder Option auf ‚Details‘ klicken.“ Wenn es im Widget etwas Ungewohntes gibt (z. B. „Mehr N anzeigen“ oder ungewöhnliche Filter), ist es besser, das in Worten zu sagen.

Drittens: das Ergebnis im Text zusammenfassen. Nachdem die App etwas getan hat (ausgewählt, berechnet, gesendet), sollte GPT kurz berichten: „Ich habe 3 Geschenkoptionen gefunden. Die ersten beiden liegen im Budget bis $50, die dritte ist etwas teurer, hat aber eine schnelle Lieferung. Möchten Sie die Auswahl eingrenzen?“ Das ist besonders auf Mobilgeräten und in Voice‑Szenarien wichtig: Man schaut vielleicht nicht auf das UI, hört aber die textuelle Zusammenfassung.

6. Rolle des system‑prompt und der Beschreibungen der App bei der UX‑Steuerung

Bisher haben Sie gesehen, wie der system‑prompt die „Persönlichkeit“ der App definiert und wie das Modell Tools nutzt. Jetzt fügen wir UX‑Regeln hinzu: wann man die App anbietet, wie man sie ankündigt und wann man auf sie verzichtet.

Was im system‑prompt festhalten

Für GiftGenius kann der system‑prompt einen Abschnitt „Dialog und UX“ enthalten. In Dokumentation und Artikeln wird empfohlen, das strukturiert, als separate Regeln, zu beschreiben.

Beispielfragment (Pseudocode, aber sehr nah an der Realität):

### Dialog und UX

1. Wenn der Nutzer Bedingungen für die Geschenkauswahl nennt (für wen, Budget, Anlass),
   stelle zunächst 1–2 Rückfragen im Text.
2. Biete nach den Rückfragen an, die App GiftGenius zu öffnen:
   "Ich kann den GiftGenius-Assistenten öffnen, um Geschenkoptionen zu zeigen. Öffnen?"
3. Wenn der Nutzer ausdrücklich "Starte GiftGenius" oder "zeig die Geschenkliste" verlangt,
   antworte "Ich öffne GiftGenius..." und rufe die App sofort ohne weitere Fragen auf.
4. Wenn der Nutzer Theorie oder allgemeine Ratschläge verlangt (z. B. "wie wählt man Geschenke"),
   antworte im Text und öffne die App nicht, bis er selbst darum bittet.
5. Wenn der Nutzer sagt "öffne die App nicht" oder "bitte nur Text",
   biete die App in diesem Dialog später nicht mehr an.
6. Fasse nach der Arbeit der App das Ergebnis immer kurz im Text zusammen.

Hier sind alle unsere UX‑Prinzipien komprimiert: chat‑first, Respekt vor der Ablehnung des Nutzers, Unterschied zwischen Auto‑Launch und Suggest, obligatorische Textzusammenfassung.

Wie TypeScript‑Configs helfen können

In realen Projekten ist es praktisch, einen Teil dieser Regeln in strukturierter Form vorzuhalten (damit man den Text später nicht in Prompts zusammensuchen muss). Man kann zum Beispiel eine einfache Config anlegen:

// Hypothetischer Typ für App-UX-Trigger-Regeln
type AppUxRule = {
  intent: 'gift_selection' | 'theory' | 'open_app';
  trigger: 'auto' | 'suggest' | 'avoid';
  askConfirmation?: boolean;
};

export const giftGeniusUxRules: AppUxRule[] = [
  { intent: 'open_app', trigger: 'auto' },
  { intent: 'gift_selection', trigger: 'suggest', askConfirmation: true },
  { intent: 'theory', trigger: 'avoid' },
];

Diese Config wird vom Modell selbst nicht gelesen — sie dient Ihnen als Entwickler, um Produkt/Design‑Absprachen an einem Ort zu sammeln und dann sauber in den system‑prompt, die Beschreibungen der App und die Dokumentation zu übertragen.

7. Beispiel: wie GPT GiftGenius ankündigt und die Unterhaltung nicht übernimmt

Bringen wir alles mit unserer App zusammen. Stellen wir uns vor, ein Nutzer schreibt zum ersten Mal in den Chat:

Ich suche ein Geschenk für einen Kollegen, ungefähr bis 3000 ₽, er mag Brettspiele.

Eine gute Antwort des Modells (unter Berücksichtigung unseres system‑prompt) könnte so aussehen:

Verstanden! Lassen Sie uns ein paar Details klären und dann Ideen auswählen.

Sagen Sie mir ungefähr sein Alter und ob es eher ein formelles Geschenk ist oder von einem engen Freund?

(Nach Ihrer Antwort kann ich den GiftGenius-Assistenten öffnen, wo wir Optionen in Kartenform ansehen.)

Nach der Klärung schreibt GPT:

Super, ich habe genug Informationen.

Ich öffne jetzt die App GiftGenius — darin zeige ich Ihnen einige Geschenkoptionen in Kartenform; Sie können Details ansehen und die Auswahl nach Budget und Spieltyp eingrenzen.

Und erst danach — der Start der App. Keine „Überraschung“, alles ist in Worten erklärt.

Kleine React‑Komponente für die „App‑Ankündigung“ im Widget

Aus Code‑Sicht wird das Widget normalerweise einfach gerendert, wenn es aufgerufen wurde. Aber Sie können in sein UI die Philosophie „Kontext nicht übernehmen“ einbauen — selbst wenn es schon geöffnet ist.

Zum Beispiel kann der erste Bildschirm von GiftGenius sehr einfach sein:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Geschenkeauswahl mit GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        Ich zeige einige Optionen in Kartenform. Sie können
        Favoriten auswählen, und ChatGPT erklärt Vor- und Nachteile.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        Sie können jederzeit zum normalen Chat zurückkehren und die Unterhaltung fortsetzen.
      </p>
    </section>
  );
}

Diese Komponente tut technisch nichts „Mächtiges“, ist aber aus UX‑Sicht wichtig: Sie erinnert daran, dass der Chat weiterhin da ist und die Rolle von GPT zentral bleibt.

Von diesem Intro‑Bildschirm aus wechseln Sie später zu Geschenk‑Karten, Assistenten usw. — das ist jedoch Thema der nächsten Vorlesungen.

8. Praxis und Übungen

Oben haben wir eine Reihe von Prinzipien gesammelt — chat‑first, Respekt vor der Nutzerintention, Unterschied zwischen Auto‑Launch und dem Vorschlagen einer App. Um den Ansatz „wann und wie man eine App anzeigt“ zu festigen, ist es hilfreich, reale Anfragen zu durchdenken und klar zu trennen, wo die App nötig ist und wo nicht. Für die Hausübung kann man zwei kleine Aufgaben machen.

Nehmen Sie zunächst GiftGenius und denken Sie sich 5–7 Nutzeranfragen aus. Beantworten Sie sich für jede ehrlich:

• sollte man hier direkt anbieten, die App zu öffnen;
• sollte man die App nur als Option erwähnen;
• oder ist es besser, die Antwort überhaupt nicht mit der App zu verknüpfen.

Zum Beispiel:

1. „Schenk meiner Frau etwas zur Jahrestagsfeier, Budget bis $1000“ — wahrscheinlich zuerst ein paar Rückfragen im Text, dann der Vorschlag, die App zu öffnen.
2. „Wie verpackt man ein Geschenk originell?“ — rein theoretische Frage, kommt ohne App aus.
3. „Starte GiftGenius, ich will Geschenke für das ganze Team aussuchen“ — direkter Auto‑Launch.

Die zweite Übung — der Text zur Ankündigung des Starts der App. Versuchen Sie, 1–2 kurze Sätze zu schreiben, mit denen GPT dem Nutzer den Übergang in die App erklärt. Vergleichen Sie unterschiedliche Tonalitäten: formeller („Ich öffne die App GiftGenius …“) und freundlicher („Lassen Sie uns den GiftGenius‑Assistenten ausprobieren — so lassen sich Optionen leichter vergleichen“).

So lernen Sie, nicht nur wie ein Entwickler, sondern auch wie ein Autor von Dialogen zu denken.

9. Typische Fehler beim UX „wann man die App zeigt“

Fehler Nr. 1: Die App bei jeder Themennennung anzeigen.
Ein häufiges Extrem: Wenn die App sich um Geschenke dreht, triggert jedes Wort „Geschenk“ im Dialog sofort das Widget. Der Nutzer fragt „wie vermeide ich einen Fehlgriff beim Geschenk für meinen Chef“, und statt eines lebendigen Ratschlags bekommt er ein UI mit Karten. Das wirkt wie Werbung und ignoriert die wahre Nutzerintention — im klaren Widerspruch zu den offiziellen UX‑Guidelines und zum Prinzip „Respect user’s intent“.

Fehler Nr. 2: Fullscreen ohne Vorwarnung.
Ein „Überraschungs‑Widget“, das plötzlich den ganzen Bildschirm einnimmt, ist ein sicherer Weg, den Eindruck zu ruinieren. Besonders schlecht mitten in einer längeren Unterhaltung, wenn der Nutzer nicht mit einem harten Wechsel vom Text ins UI gerechnet hat. Nach den OpenAI‑Guidelines sind solche Szenarien schlechte Praxis; man sollte den Übergang immer ankündigen und nach Möglichkeit um Zustimmung bitten.

Fehler Nr. 3: UI statt Antwort.
Manche App‑Autoren denken: „Warum im Text antworten, wir haben doch ein schönes Interface!“ Am Ende sagt GPT fast nichts, und die „Antworten“ stecken im Widget. Nutzer, besonders in Voice‑ oder Mobile‑Modi, könnten wichtige Details übersehen. Der richtige Ansatz: UI ergänzt die Antwort, ersetzt sie nicht — die App zeigt Details und Optionen, GPT erklärt, was sie bedeuten.

Fehler Nr. 4: Ablehnung des Nutzers gegenüber der App ignorieren.
Wenn jemand explizit sagt „öffne die App nicht“ oder „bitte nur Text“, sollte die App das als strikte Regel bis zum Ende des Dialogs respektieren. Alle zwei Nachrichten erneut die App vorzuschlagen, ist wie ein aufdringliches „Bewerten Sie unseren Service“-Popup. Solche Dinge verschlechtern den UX und können das Store‑Review beeinflussen. Im system‑prompt sollte die Achtung vor der Ablehnung ausdrücklich verankert sein.

Fehler Nr. 5: Kein Unterschied zwischen Auto‑Launch und „Vorschlag“.
Wenn der Entwickler explizite und implizite Intentionen nicht unterscheidet, startet er entweder nie die App, selbst wenn der Nutzer direkt darum bittet, oder er startet sie immer, selbst wenn der Nutzer nur sagt „vielleicht probiere ich eure App irgendwann“. Daraus entsteht das automatische Öffnen „nur weil das Wort ähnlich klingt“. Die Formalisierung der Trigger (auto / suggest / avoid) und durchdachte Logik im system‑prompt helfen, diese Verwirrung zu vermeiden.

Fehler Nr. 6: Vollständiges Fehlen von UX‑Regeln im system‑prompt.
Manchmal existieren alle UX‑Entscheidungen nur „im Kopf des Teams“, und der system‑prompt beschränkt sich auf „Du bist der GiftGenius‑Assistent, hilf bei Geschenken“. Das Ergebnis: Mal schlägt das Modell die App vor, mal vergisst es sie, mal öffnet es sie im falschen Moment. Schriftlich fixierte, strukturierte UX‑Regeln im system‑prompt und in der Doku sind genauso wichtig wie die JSON‑Schemas der Tools.

Fehler Nr. 7: Versuch, „UX später dranzuschrauben“.
Ein verbreiteter Ansatz ist „erstmal alles zum Laufen bringen“ und irgendwann später über UX nachdenken. Bei ChatGPT Apps führt das dazu, dass Sie sich bereits auf bestimmte Tool‑Aufrufmuster festgelegt haben, und das Ändern des system‑prompt und des GPT‑Verhaltens wird schwieriger. Besser ist es, zumindest grundlegende UX‑Guidelines sofort zu verankern: chat‑first, Respekt vor Ablehnung, klare Kriterien für die Anzeige der App und keine „Überraschungs‑Widgets“. Dann baut sich alles Weitere (Inline‑Muster, Fullscreen, Voice) auf einem soliden Fundament auf.