OpenAI UX guidelines: when to show App and how not to “take over” the conversation

1. Chat‑first: ChatGPT is a chat first, and apps second

Over the first 6 modules we covered all aspects of an app: from UI and MCP to debugging and deployment. Now we’ll take another pass through all of it, only deeper. You didn’t think it would be that simple, did you?

We’ll start with UX — specifically, the official UI requirements and UX guidelines. You want your app to pass review, right? Great, then let’s begin with the most important mindset shift for a frontend developer used to SPA/Next.js: ChatGPT is primarily a conversational interface, and the App is a guest inside that conversation. Not the other way around.

OpenAI states it like this: apps extend what the user can do without breaking the flow of conversation. A widget is not a new browser tab, but a careful insertion into chat that provides structure when plain text starts to struggle.

It’s easiest to remember via a split of roles.

Roles of GPT and the App

Inside ChatGPT there are two “characters”:

GPT remains the main narrator. It explains in words what’s going to happen, why it suggests the App, what buttons mean, and summarizes the widget’s result. The App, in turn, focuses on visual structure and actions: choosing options, setting filters, stepping through a wizard.

A very important rule you’ll want to repeat like a mantra: all important decisions must be stated explicitly in GPT’s text response, even if the user clicks in the UI. The user doesn’t have to read every line in the widget interface — key consequences (for example, “we placed the order” or “you chose these parameters”) must be voiced in the chat.

2. When an App is truly needed: display criteria

Technically, you could show a widget after every message. But from a UX perspective — that’s like opening a full-screen dialog on every keystroke in an input. Does it work? Yes. Is it pleasant to live with? No.

OpenAI and the Apps SDK suggest a simple principle: an App is appropriate when it makes thinking easier than plain text alone.

Requests with structure and a repeatable flow

An App shines when the user request already implies structure:

• “Pick 5 gift ideas for a colleague under $50.”
• “Compare these three pricing plans.”
• “Make a 3‑day itinerary for Tokyo.”
• “Show my tasks for the week and help prioritize them.”

In all these cases there are clear entities (gifts, plans, itinerary days, tasks) that need manipulation, and steps: select, filter, compare, confirm. Here, a UI with cards, checkboxes, and filters is justified — it can even be a lifesaver.

Examples for GiftGenius

Let’s take our favorite hero, GiftGenius. A typical request:

We need to pick gifts for 10 wedding guests with different budgets and interests.

GPT could list 10 separate lists in pure text, but reading that would be painful. Much nicer to:

• show a table of guests, budgets, and interests,
• allow filtering “cheaper/more expensive,”
• render a set of cards for each guest.

Here the App is almost mandatory: there are too many entities and parameters to keep it all in text.

In contrast:

What should I give my brother for 5,000 ₽?

This is a small, single-step question. GPT can reply with 3–5 ideas in text, and only if the user asks “show options where I can filter by hobby and age,” you can smoothly switch to the App.

A quick heuristic

It helps to keep a simple table in mind:

We’ll dig into inline vs fullscreen in future lectures, but it’s already clear: an App is a tool for structured, multi-step tasks — not for every “I’m feeling down, what should I do?”

3. When an App gets in the way: “let’s talk” mode and reflection

We’ve seen when an App genuinely simplifies life and helps structure the dialogue. But there’s another side: sometimes any UI only gets in the way.

So much talk about “let’s draw UI” often creates a reflex: “oh, the user asked something — time to launch a widget.” That’s exactly where you can get a negative UX mark in the Store review.

There’s a whole class of requests where an App is usually harmful:

1. The user is in “let’s talk” mode. Philosophical reflections, personal questions, career dilemmas, therapeutic conversations. In such scenarios the user expects a text conversation, clarifying questions, sometimes empathy. Dropping cards and filters here will feel like a spam banner.
2. Introductory questions about the service. If someone writes “Tell me what GiftGenius can do,” they want an overview, not UI right away. Here GPT should first briefly explain the purpose of the App, perhaps provide example requests, and only then gently suggest trying the widget.
3. General theoretical questions. “How do you choose gifts for introverts?” or “How does a loyalty system work in stores?” — this is an educational, not a transactional scenario. GPT can give a good text answer and, at the end, unobtrusively add: “If you want, I can open GiftGenius and pick a few concrete options.”

Anywhere the UI doesn’t add new value and merely duplicates text, it’s better to stay in chat. That’s the respect for user intent UX gurus write about.

4. How to propose the App: auto‑launch versus “humble handoff”

Even if you’re sure the App is appropriate, the question “how to launch it” remains. A rough approach: the widget suddenly opens fullscreen without warning. A normal approach: GPT first explains in words what will happen and asks for consent or at least notifies.

In the ChatGPT Apps UX docs there are two patterns: auto‑launch and suggestion (humble handoff).

Auto‑launch: when the user asked explicitly

Auto‑launch is appropriate when the user gives an explicit intent:

Launch GiftGenius.
Open GiftGenius settings.
Show my gift cart in GiftGenius.

Rules are simple here:

1. GPT briefly writes something like “Opening GiftGenius…”.
2. The model immediately calls the tool/widget.

The conversation might look like this:

User: Launch GiftGenius, I want to pick a gift for a friend.
GPT: Opening the GiftGenius assistant for gift selection.
[The GiftGenius widget appears inline or fullscreen]

Auto‑launch without extra clarifications is justified because the user explicitly asked to “open.”

Suggestion (humble handoff): when intent is implicit

In many cases the user doesn’t know about your app at all. They write:

I need to come up with something for a colleague’s birthday, small budget.

The proper pattern is:

1. GPT analyzes the request and understands that the App can help.
2. GPT asks 1–2 clarifying questions or immediately offers the App in text.
3. Only after consent or an explicit hint — it launches the widget.

Example:

User: I need to come up with something for a colleague’s birthday, small budget.
GPT: I can suggest ideas myself or open the GiftGenius app, where we’ll pick options by budget and interests. Do you prefer simple tips or to try the app?
User: Let’s try the app.
GPT: Opening GiftGenius to pick gift options.
[Widget appears]

This approach emphasizes: the initiative is still with the user, and the App is an option, not a forced banner. It aligns well with the “Respect user’s intent” principle from the UX guidelines.

Mini example: “intent classifier” in TypeScript

Imagine that on your backend you already roughly classify the user’s request (not to be confused with GPT itself — this is auxiliary logic):

// Simplified user intent type
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Which trigger we want to use for the App
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "launch GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // implicit request
  return 'avoid';                                // regular chat, no App
}

This logic doesn’t launch the widget by itself — it’s a way to formalize your UX approach. You then translate these rules into the system‑prompt and App descriptions so the model behaves accordingly.

5. How not to “take over” the conversation: good and bad patterns

OpenAI’s documentation and UX design articles for ChatGPT Apps clearly state what not to do: do not “steal” the conversation. In other words, don’t turn the chat into a channel for promoting your interface.

Anti-patterns

The most painful — the “surprise widget”. The user is having a deep conversation, and suddenly a fullscreen app takes over the entire screen without being asked for. Context is lost, and so is the sense of control.

Another common sin is using the App as advertising. For example, the user asks a theoretical question, and the model responds: “First I’ll open our super widget where everything is written,” and shows a UI that’s half marketing copy. The official guidelines explicitly call such scenarios “poor use cases.”

A third anti-pattern is frequent unnecessary switching between UI and text. If you open and close the App for every small clarification, the conversation looks like a blinking garland. The user — especially on mobile — will quickly get tired.

Good practices

In all scenarios where you do open the App, try to stick to three simple rules.

First, give a heads-up. Let GPT explicitly say it’s going to open the app and why. For example: “I’ll open the GiftGenius assistant now to show options as cards.” It’s 1–2 lines that completely change how the transition feels.

Second, explain what to do in the UI. Not everyone is used to a new interface. GPT can add: “At the bottom you’ll see gift cards; you can paginate and click ‘More details’ on any option.” If the widget has anything unusual (for example, “Show N more” or nonstandard filters), it’s better to explain it in words.

Third, summarize the result in text. After the App does something (selects, calculates, submits), GPT should briefly report: “I picked 3 gift options. The first two are under $50; the third is a bit more but with fast shipping. Want to narrow it down?” This is especially important on mobile and in voice scenarios: a person might not look at the UI but will hear the text summary.

6. The role of the system‑prompt and App descriptions in managing UX

You’ve already seen how the system‑prompt defines the App’s “personality” and how the model uses tools. Now add UX rules: when to propose the App, how to announce it, and when to hold back.

What to put into the system‑prompt

For GiftGenius, the system‑prompt can include a “Conversation and UX” section. The documentation and articles suggest writing it in a structured way, as separate rules.

Example snippet (pseudocode, but very close to reality):

### Conversation and UX

1. If the user provides gift selection criteria (for whom, budget, occasion),
   first ask 1–2 clarifying questions in text.
2. After clarifying, suggest opening the GiftGenius App:
   "I can open the GiftGenius assistant to show gift options. Open it?"
3. If the user explicitly asks "launch GiftGenius" or "show the gift list",
   reply "Opening GiftGenius..." and immediately call the App without extra questions.
4. If the user asks for theory or general advice (e.g., "how to choose gifts"),
   answer in text and don’t open the App until they ask for it.
5. If the user says "don’t open the app" or "just answer in text",
   don’t suggest the App again in this conversation.
6. After the App runs, always summarize the result in text (briefly).

This packs all our UX principles: chat-first, respect for refusal, the difference between auto‑launch and suggest, and the required text summary.

How TypeScript configs can help

In real projects it’s convenient to store some of these rules in a structured form (so you don’t hunt for text in prompts by hand). For example, you can create a simple config:

// Example type for App UX triggers config
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' },
];

The model doesn’t read this config directly — it’s for you, the developers, to collect product/design agreements in one place and then carefully transfer them into the system‑prompt, App descriptions, and documentation.

7. Example: how GPT announces GiftGenius without hijacking the chat

Let’s tie it to our app. Imagine the user writes to the chat for the first time:

I’m looking for a gift for a colleague, up to 3,000 ₽, he likes board games.

A good model response (given our system‑prompt) might look like this:

Got it! Let’s clarify a couple of details and then pick ideas.

Roughly how old is he, and is this more of a formal gift or from a close friend?

(After your reply I can open the GiftGenius assistant, where we’ll browse options as cards.)

After a clarification, GPT writes:

Great, I have enough information.

I’ll open the GiftGenius app now — there I’ll show you several gift options as cards. You’ll be able to view details and narrow down by budget and game type.

Only then — the App launches. No “surprises,” everything is explained in words.

A small React component for announcing the App inside the widget

From a code perspective, a widget usually just renders when it’s invoked. But you can bake the “don’t hijack” philosophy into its UI even after it’s already open.

For example, GiftGenius’s first screen can be very simple:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Gift selection with GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        I’ll show several options as cards. You’ll be able to
        pick the ones you like, and ChatGPT will explain the pros and cons.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        You can return to the regular chat at any time and continue the discussion.
      </p>
    </section>
  );
}

This component doesn’t do anything “powerful” technically, but it’s important from a UX standpoint: it reminds the user that the chat is still there and GPT’s role remains central.

Later you’ll transition from this intro screen to gift cards, wizards, and so on — but that’s a topic for future lectures.

8. Practice and exercises

Above we collected a set of principles — chat-first, respect for user intent, the difference between auto‑launch and suggesting an App. To cement “when and how to show an App,” it helps to think through real requests and explicitly separate where the App is needed and where it isn’t. For homework, try two small exercises.

First, take GiftGenius and come up with 5–7 user requests. For each, answer honestly:

• should you immediately propose opening the App here;
• should you only mention the App as an option;
• or is it better not to tie the answer to the App at all.

For example:

1. “Get something for my wife for our anniversary, budget up to $1000” — most likely start with a couple of clarifying questions in text, then suggest opening the App.
2. “How do I wrap a gift creatively?” — purely theoretical, you can do without the App.
3. “Launch GiftGenius, I want to pick gifts for the whole team” — direct auto‑launch.

Second exercise — write the launch announcement text for the App. Try 1–2 short phrases GPT would use to explain the switch to the App. Compare different tones: more formal (“Opening the GiftGenius app…”) and more friendly (“Let’s try the GiftGenius assistant — it’ll make it easier to compare options”).

This way you’ll learn to think not only like a developer but also as the author of a conversation.

9. Common mistakes in UX for “when to show the App”

Mistake #1: Show the App for any mention of the topic.
A frequent extreme: if your App is about gifts, any appearance of the word “gift” immediately triggers the widget. The user asks “how not to mess up a gift for my boss,” and instead of a genuine tip gets a UI with cards. It feels like advertising and ignores the true user intent — which directly contradicts the official UX guidelines and the “Respect user’s intent” principle.

Mistake #2: Fullscreen without warning.
The “surprise widget” that suddenly takes over the entire screen is a reliable way to ruin the experience. It looks especially bad mid‑conversation when the user didn’t expect an abrupt switch from text to UI. OpenAI’s guidelines consider such scenarios poor practice; always announce the transition and, if possible, ask for consent.

Mistake #3: UI instead of an answer.
Sometimes App authors think: “Why answer in text — we have a beautiful interface!” As a result, GPT says almost nothing, and all the “answers” are hidden in the widget. A user — especially in voice or on mobile — might miss important details. The right approach: the UI complements the answer, it doesn’t replace it. The App shows details and options; GPT explains what they mean.

Mistake #4: Ignoring the user’s refusal to use the App.
If a person explicitly says “don’t open the app” or “just answer in text,” the App should treat that as a hard rule for the rest of the conversation. Continuing to propose the App every other message is like a nagging “rate our service” pop‑up. This degrades UX and can affect Store review. Respecting refusal should be explicitly encoded in the system‑prompt.

Mistake #5: No distinction between auto‑launch and “suggestion.”
When a developer doesn’t distinguish explicit vs implicit intent, they either never launch the App even when the user clearly asks, or always launch it even when the user just offhandedly says “maybe I’ll try your App someday.” Hence, auto‑opening the widget “just because the word sounded similar.” Formalizing triggers (auto / suggest / avoid) and well‑thought logic in the system‑prompt help avoid this confusion.

Mistake #6: No UX rules in the system‑prompt at all.
Sometimes all UX decisions are only “in the team’s heads,” and the system‑prompt is reduced to “You are the GiftGenius assistant; help with gifts.” The model then sometimes suggests the App, sometimes forgets about it, sometimes opens it at the wrong moment. Written, structured UX rules in the system‑prompt and documentation are as important as a JSON schema for tools.

Mistake #7: Trying to “bolt UX on later.”
A common approach is to “make it work first” and only later think about UX. With ChatGPT Apps, this leads to being tied to certain tool‑calling patterns, making it harder to change the system‑prompt and GPT behavior. It’s better to lay down at least basic UX guidelines right away: chat‑first, respect for refusal, clear display criteria for the App, and no “surprise widgets.” Then everything that follows (inline patterns, fullscreen, voice) will be built on a solid foundation.