Diretrizes de UX da OpenAI: quando mostrar App e como não “tomar” a conversa

1. Chat‑first: ChatGPT é, antes de tudo, um chat — e só depois, aplicativos

Nos primeiros 6 módulos, entendemos todos os aspectos do aplicativo: de UI e MCP a debug e deploy. Agora vamos percorrer novamente todos os seus lados, só que mais a fundo. Você não achou que seria tão simples, né?

E vamos começar por UX, mais precisamente pelos requisitos oficiais de UI e pelas diretrizes de UX. Você quer que seu app passe na review, certo? Ótimo, então vamos ao que interessa: a principal mudança de mentalidade necessária para quem vem do mundo SPA/Next.js: ChatGPT é, em primeiro lugar, uma interface de diálogo, e o App é um convidado dentro desse diálogo. Não o contrário.

A OpenAI formula isso em suas diretrizes assim: os aplicativos ampliam o que o usuário pode fazer sem quebrar o fluxo da conversa. O widget não é uma nova aba do navegador, e sim uma inserção cuidadosa no chat, que traz estrutura quando o texto sozinho já fica pesado.

O jeito mais fácil de memorizar é separar os papéis.

Papéis do GPT e do App

Dentro do ChatGPT há dois “papéis”:

O GPT continua sendo o narrador principal. É ele quem, em palavras, explica o que vai acontecer, por que está sugerindo o App, o que significam os botões, e quem resume o resultado do widget. O App, por sua vez, foca na parte visual e nas ações: escolher opções, configurar filtros, percorrer etapas de um assistente.

Uma regra muito importante, que vale repetir como um mantra: todas as decisões importantes devem ser explicitamente enunciadas na resposta em texto do GPT, mesmo se o usuário clicar pela UI. O usuário não é obrigado a ler cada linha da interface do widget — as consequências-chave (por exemplo, “finalizamos o pedido” ou “você escolheu estes parâmetros”) devem ser comunicadas no chat.

2. Quando o App realmente é necessário: critérios de exibição

Do ponto de vista técnico, você pode chamar o widget a cada mensagem. Mas, do ponto de vista de UX — é como abrir um diálogo em tela cheia a cada caractere digitado no input. Funciona? Sim. Viver com isso confortavelmente? Não.

A OpenAI e o Apps SDK sugerem um princípio simples: o App é apropriado quando pensar com ele é mais fácil do que só com texto.

Solicitações com estrutura e roteiro repetível

O App funciona muito bem quando a solicitação do usuário já sugere uma estrutura:

• “Escolha 5 opções de presentes para um colega, até $50.”
• “Compare estes três planos.”
• “Monte um roteiro de 3 dias por Tóquio.”
• “Mostre minha lista de tarefas da semana e ajude a priorizar.”

Em todos esses casos, há entidades claras (presentes, planos, dias do roteiro, tarefas) com as quais é preciso manipular, e etapas: selecionar, filtrar, comparar, confirmar. Aqui, uma UI com cartões, checkboxes e filtros é justificada — e até salva.

Exemplos para GiftGenius

Vamos pegar nosso herói favorito, o GiftGenius. Um pedido típico:

Preciso escolher presentes para 10 convidados de um casamento, com orçamentos e interesses diferentes.

Em puro texto, o GPT pode enumerar 10 listas separadas, mas isso será doloroso de ler. Muito mais agradável:

• mostrar uma tabela com convidados, orçamento e interesses,
• dar a possibilidade de filtrar “mais barato/mais caro”,
• exibir um conjunto de cartões para cada convidado.

Aqui, o App é praticamente obrigatório: entidades e parâmetros demais para manter só em texto.

Em contraste com isso:

O que dar de presente ao meu irmão por 5000 ₽?

É uma pergunta simples, de uma etapa. O GPT pode responder com 3–5 ideias em texto e, só se o usuário pedir “mostre opções onde eu possa filtrar por hobbies e idade”, é possível fazer uma transição suave para o App.

Mini‑heurística

Vale manter em mente uma tabela simples:

Falaremos em detalhes sobre inline e fullscreen nas próximas aulas, mas já dá para ver: o App é uma ferramenta para tarefas estruturadas e de múltiplas etapas — não para cada “estou triste, o que faço?”.

3. Quando o App atrapalha: modo “só conversar” e reflexão

Já vimos em quais casos o App realmente simplifica a vida e ajuda a estruturar o diálogo. Mas há o outro lado: existem situações em que qualquer UI só atrapalha.

Tanto papo sobre “vamos desenhar UI” costuma levar a um reflexo: “opa, o usuário perguntou algo — hora de lançar o widget”. É aí que, na review da Store, você pode perder pontos de UX.

Há uma classe inteira de solicitações em que o App normalmente faz mais mal do que bem:

1. Usuário no modo “só conversar”. Reflexões filosóficas, questões pessoais, dilemas de carreira, conversas terapêuticas. Nesses cenários, o usuário espera uma conversa em texto, perguntas de esclarecimento, às vezes empatia. Inserir cartões e filtros aqui vai soar como um banner de spam.
2. Perguntas introdutórias sobre o serviço. Se a pessoa escreve “Conte o que o GiftGenius faz”, ela quer uma visão geral, não UI de cara. Aqui, o GPT deve primeiro explicar brevemente a finalidade do App, talvez mostrar exemplos de solicitações, e só então sugerir, com cuidado, experimentar o widget.
3. Perguntas teóricas gerais. “Como escolher presentes para introvertidos?” ou “Como funciona um programa de fidelidade em lojas?” — é um cenário de aprendizagem, não transacional. O GPT pode dar uma boa resposta em texto e, no fim, adicionar de forma sutil: “Se quiser, posso abrir o GiftGenius e selecionar algumas opções concretas.”

Sempre que a UI não agrega valor novo e apenas duplica o texto, é melhor ficar no chat. Isso é o tal respeito às intenções do usuário de que os gurus de UX tanto falam.

4. Como oferecer o App: auto‑launch versus “humble handoff”

Mesmo que você tenha certeza de que o App é apropriado, a pergunta “como iniciá-lo” permanece. Variante grosseira: o widget abre inesperadamente em tela cheia, sem aviso. Variante normal: o GPT primeiro explica em palavras o que vai acontecer e pede consentimento ou, ao menos, avisa.

Na documentação de UX dos ChatGPT Apps, destacam-se dois padrões: auto‑launch e suggestion (humble handoff).

Auto‑launch: quando o usuário pede explicitamente

Auto‑launch é apropriado quando o usuário expressa claramente a intenção:

Inicie o GiftGenius.
Abra as configurações do GiftGenius.
Mostre meu carrinho de presentes no GiftGenius.

Aqui as regras são simples:

1. O GPT escreve algo curto como “Abrindo o GiftGenius…”.
2. O modelo chama imediatamente a ferramenta / widget.

O diálogo pode ficar assim:

Usuário: Inicie o GiftGenius, quero escolher um presente para um amigo.
GPT: Abrindo o assistente GiftGenius para selecionar presentes.
[O widget GiftGenius aparece inline ou em tela cheia]

O início automático sem maiores esclarecimentos é justificado porque o usuário pediu explicitamente para “abrir”.

Suggestion (humble handoff): quando a intenção não é explícita

Em muitos casos, o usuário nem conhece seu aplicativo. Ele escreve:

Preciso pensar em algo para um colega no aniversário, o orçamento é pequeno.

O padrão correto aqui é:

1. O GPT analisa a solicitação e percebe que o App pode ajudar.
2. O GPT faz 1–2 perguntas de esclarecimento ou oferece diretamente o App em texto.
3. Só depois do consentimento ou de um sinal claro — inicia o widget.

Exemplo:

Usuário: Preciso pensar em algo para um colega no aniversário, o orçamento é pequeno.
GPT: Posso ajudar com ideias diretamente ou abrir o aplicativo GiftGenius, onde selecionaremos opções por orçamento e interesses. Prefere apenas conselhos ou quer experimentar o aplicativo?
Usuário: Vamos com o aplicativo.
GPT: Abrindo o GiftGenius para selecionar opções de presentes.
[O widget aparece]

Essa abordagem enfatiza: a iniciativa continua sendo do usuário, e o App é uma opção, não um banner imposto. Isso combina bem com o princípio “Respect user’s intent” das diretrizes de UX.

Mini‑exemplo de “classificador de intenções” em TypeScript

Suponha que, no seu backend, você já classifique aproximadamente a solicitação do usuário (não confundir com o próprio GPT — é uma lógica auxiliar):

// Tipo simplificado de intenções do usuário
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Qual gatilho para o App queremos usar
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "inicie o GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // solicitação implícita
  return 'avoid';                                // chat normal, sem App
}

Essa lógica, por si só, não chama o widget — é mais um modo de formalizar sua abordagem de UX. Depois, você traduz essas regras para o system‑prompt e as descrições do App, para que o modelo se comporte do mesmo jeito.

5. Como não “roubar” a conversa: padrões bons e ruins

Na documentação da OpenAI e em artigos de UX para ChatGPT Apps, está formulado de maneira bem clara o que não fazer: não “roubar” a conversa. Ou seja, não transformar o chat num canal de promoção da sua interface.

Antipadrões

O mais doloroso é o “widget‑surpresa”. É quando o usuário está numa conversa profunda e, de repente, a tela inteira é tomada por um aplicativo em tela cheia que ele não pediu. O contexto se perde, e a sensação de controle também.

Outro pecado frequente é usar o App como propaganda. Por exemplo, o usuário faz uma pergunta teórica, e o modelo responde: “Primeiro vou abrir nosso super widget, lá está tudo explicado” — e mostra uma UI onde metade é texto de marketing. As diretrizes oficiais citam esses cenários explicitamente como “poor use cases”.

O terceiro antipadrão é alternar desnecessariamente e com frequência entre UI e texto. Se, a cada pequeno esclarecimento, você abrir e fechar o App, o diálogo vira uma árvore de Natal piscante. O usuário, especialmente no celular, vai se cansar rápido.

Boas práticas

Em todos os cenários em que você abrir o App, procure seguir três regras simples.

Primeiro, avise. Deixe o GPT dizer explicitamente que vai abrir o aplicativo e por quê. Por exemplo: “Vou abrir o assistente GiftGenius para mostrar as opções em forma de cartões.” São 1–2 linhas, mas mudam completamente a sensação da transição.

Segundo, explique o que fazer na UI. Nem todos os usuários estão acostumados a uma interface nova. O GPT pode adicionar texto: “Na parte de baixo, você verá cartões de presentes; é possível navegar pelas páginas e tocar em ‘Detalhes’ em qualquer opção.” Se houver algo incomum no widget (por exemplo, “Mostrar mais N” ou filtros não padronizados), é melhor comunicar isso em palavras.

Terceiro, resuma o resultado em texto. Depois que o App fizer algo (selecionar, calcular, enviar), o GPT deve contar brevemente: “Encontrei 3 opções de presentes. As duas primeiras ficam até $50; a terceira é um pouco mais cara, mas tem entrega rápida. Quer refinar a seleção?” Isso é especialmente importante em dispositivos móveis e cenários de voz: a pessoa pode não olhar para a UI, mas ouvirá o resumo em texto.

6. O papel do system‑prompt e das descrições do App na condução do UX

Até aqui você já viu como o system‑prompt define a “personalidade” do App e como o modelo usa as ferramentas. Agora, adicionamos ali regras de UX: quando oferecer o App, como anunciá-lo e quando evitá-lo.

O que colocar no system‑prompt

Para o GiftGenius, o system‑prompt pode incluir uma seção “Diálogo e UX”. Na documentação e nos artigos, recomendam descrever isso de forma estruturada, em regras separadas.

Exemplo de trecho (pseudocódigo, mas bem próximo da realidade):

### Diálogo e UX

1. Se o usuário fornecer condições para a seleção do presente (para quem, orçamento, ocasião),
   primeiro faça 1–2 perguntas de esclarecimento em texto.
2. Após os esclarecimentos, proponha abrir o App GiftGenius:
   "Posso abrir o assistente GiftGenius para mostrar opções de presentes. Abrir?"
3. Se o usuário pedir explicitamente "inicie o GiftGenius" ou "mostre a lista de presentes",
   responda "Abrindo o GiftGenius..." e chame o App imediatamente, sem perguntas adicionais.
4. Se o usuário pedir teoria ou conselhos gerais (por exemplo, "como escolher presentes"),
   responda em texto e não abra o App até que ele peça isso.
5. Se o usuário disser "não abra o aplicativo" ou "responda apenas em texto",
   não sugira o App novamente nesse diálogo.
6. Após o App trabalhar, sempre resuma o resultado em texto (brevemente).

Aqui, de forma condensada, estão todos os nossos princípios de UX: chat‑first, respeito pela recusa do usuário, a diferença entre auto‑launch e suggest, e o resumo textual obrigatório.

Como se ajudar com configs em TypeScript

Em projetos reais, é conveniente manter parte dessas regras de forma estruturada (para não ter que caçar texto nos prompts depois). Por exemplo, você pode criar uma config simples:

// Tipo hipotético de config de gatilhos de UX do App
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' },
];

Essa config não é lida pelo modelo — ela serve para vocês, desenvolvedores, juntarem num só lugar os combinados de produto/design e depois transferirem com cuidado para o system‑prompt, as descrições do App e a documentação.

7. Exemplo: como o GPT anuncia o GiftGenius sem tomar a conversa

Vamos ligar tudo ao nosso aplicativo. Suponha que o usuário escreva pela primeira vez no chat:

Estou procurando um presente para um colega, cerca de 3000 ₽, ele gosta de jogos de tabuleiro.

Uma boa resposta do modelo (considerando nosso system‑prompt) pode ser assim:

Entendido! Vamos esclarecer alguns detalhes e montar ideias.

Diga aproximadamente quantos anos ele tem e se é um presente mais formal ou de um amigo próximo.

(Depois da sua resposta, posso abrir o assistente GiftGenius, onde veremos opções em forma de cartões.)

Após o esclarecimento, o GPT escreve:

Ótimo, já tenho informações suficientes.

Agora vou abrir o aplicativo GiftGenius — nele vou mostrar algumas opções de presentes em forma de cartões; você poderá ver os detalhes e refinar a seleção por orçamento e tipo de jogo.

E só então — o lançamento do App. Sem “surpresas”, tudo explicado em palavras.

Pequeno componente React de “anúncio do App” dentro do widget

Do ponto de vista de código, o widget normalmente só renderiza quando é chamado. Mas você pode embutir na UI dele a filosofia de “não tomar” o contexto, mesmo quando já está aberto.

Por exemplo, a primeira tela do GiftGenius pode ser bem simples:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Seleção de presentes com o GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        Vou mostrar algumas opções em formato de cartões. Você poderá
        escolher as que mais gostar, e o ChatGPT explicará prós e contras.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        A qualquer momento você pode voltar ao chat normal e continuar a conversa.
      </p>
    </section>
  );
}

Esse componente não faz nada “poderoso” tecnicamente, mas do ponto de vista de UX ele é importante: lembra que o chat continua ali, e a função do GPT permanece central.

Depois, é justamente dessa tela de introdução que você vai para os cartões de presentes, assistentes, etc., mas isso já é tema das próximas aulas.

8. Prática e exercícios

Acima reunimos um conjunto de princípios — chat‑first, respeito à intenção do usuário, diferença entre auto‑launch e a oferta do App. Para fixar a abordagem de “quando e como mostrar o App”, vale pensar em solicitações reais e separar explicitamente onde o App é necessário e onde não é. Para praticar em casa, dá para fazer dois exercícios curtos.

Primeiro, pegue o GiftGenius e crie 5–7 solicitações de usuários. Para cada uma, responda honestamente:

• vale a pena já sugerir abrir o App;
• vale apenas mencionar o App como opção;
• ou é melhor não relacionar a resposta ao App.

Por exemplo:

1. “Dê algo de presente para minha esposa no aniversário de casamento, orçamento até $1000” — provavelmente, primeiro algumas perguntas de esclarecimento em texto e, depois, a sugestão de abrir o App.
2. “Como embrulhar um presente de forma original?” — pergunta puramente teórica; dá para ficar sem o App.
3. “Inicie o GiftGenius, quero escolher presentes para toda a equipe” — auto‑launch direto.

O segundo exercício — o texto de anúncio de abertura do App. Tente escrever 1–2 frases curtas com as quais o GPT explicará ao usuário a transição para o App. Compare tons diferentes: mais formal (“Abrindo o aplicativo GiftGenius…”) e mais amistoso (“Vamos experimentar o assistente GiftGenius — assim fica mais fácil comparar as opções”).

Assim você aprende a pensar não só como desenvolvedor, mas também como autor de diálogo.

9. Erros comuns no UX “quando mostrar o App”

Erro nº 1: Mostrar o App a qualquer menção do tema.
Uma armadilha comum: se o App é sobre presentes, qualquer palavra “presente” no diálogo já dispara o widget. O usuário pergunta “como não errar no presente para o chefe”, e, em vez de um conselho vivo, recebe uma UI com cartões. Isso é percebido como propaganda e ignora a verdadeira intenção do usuário, o que contradiz diretamente as diretrizes de UX oficiais e o princípio “Respect user’s intent”.

Erro nº 2: Tela cheia sem aviso.
O “widget‑surpresa” que, de repente, ocupa a tela inteira é um modo garantido de estragar a experiência. Fica ainda pior no meio de uma conversa longa, quando o usuário não espera uma transição brusca do texto para a UI. Pelas diretrizes da OpenAI, esses cenários são má prática; sempre anuncie a transição e, se possível, peça consentimento.

Erro nº 3: UI no lugar da resposta.
Às vezes, autores de App pensam: “Pra que responder em texto, se temos uma interface bonita!” No fim, o GPT quase não fala nada, e todas as “respostas” ficam escondidas no widget. O usuário, especialmente em modo de voz ou no celular, pode nem notar detalhes importantes. A abordagem certa: a UI complementa a resposta, não a substitui — o App mostra detalhes e opções, o GPT explica o que isso significa.

Erro nº 4: Ignorar a recusa do usuário ao App.
Se a pessoa disser claramente “não abra o aplicativo” ou “apenas responda em texto”, o App deve tratar isso como regra rígida até o fim do diálogo. Continuar oferecendo o App a cada duas mensagens é como um pop‑up insistente “avalie nosso serviço”. Essas coisas pioram o UX e podem afetar a review na Store. No system‑prompt é preciso registrar explicitamente o respeito à recusa.

Erro nº 5: Não diferenciar auto‑launch de “sugestão”.
Quando o desenvolvedor não diferencia intenções explícitas e implícitas, ele ou nunca inicia o App, mesmo quando o usuário pede diretamente, ou sempre inicia, mesmo quando a pessoa só soltou “talvez um dia eu teste seu App”. Daí nasce a abertura automática do widget “só porque a palavra pareceu”. Formalizar gatilhos (auto / suggest / avoid) e uma lógica bem pensada no system‑prompt ajuda a evitar essa confusão.

Erro nº 6: Ausência total de regras de UX no system‑prompt.
Às vezes, todas as decisões de UX ficam “na cabeça do time”, e o system‑prompt se limita a “Você é o assistente GiftGenius, ajude com presentes”. No fim, o modelo ora sugere o App, ora esquece dele, ora abre na hora errada. Regras de UX registradas e estruturadas no system‑prompt e na documentação são um artefato tão importante quanto o esquema JSON das ferramentas.

Erro nº 7: Tentar “acoplar o UX depois”.
Uma abordagem comum é “primeiro fazer funcionar” e, um dia, pensar no UX. No caso de ChatGPT Apps, isso leva a você já estar preso a certos padrões de chamada de ferramentas, e mudar o system‑prompt e o comportamento do GPT fica mais difícil. Melhor definir ao menos as diretrizes básicas de UX desde já: chat‑first, respeito à recusa, critérios claros para exibir o App e ausência de “widgets‑surpresa”. Assim, toda a evolução posterior (padrões inline, fullscreen, voz) se apoiará em um fundamento sólido.