Instruções sobre UX: anúncio App, recusa do App e comportamento na conversa

1. Por que gerenciar o UX por meio de instruções

Do ponto de vista do ChatGPT, seu App é apenas um conjunto extra de ferramentas e widgets. Mas para o usuário, é uma interface à parte que surge de repente no meio da conversa. Se você não controlar o comportamento do modelo, podem ocorrer dois cenários extremos.

Em um caso, o GPT ignora o App e tenta “resolver tudo em texto”. O usuário pede para escolher um presente, e o modelo, em vez de iniciar o GiftGenius, entrega um longo ensaio em texto com recomendações “por conta própria”. Às vezes isso não é ruim, mas você não criou o App para ele ficar pegando poeira.

No outro extremo, o GPT, ao contrário, abusa do App. Para qualquer pergunta do tipo “O que o seu serviço faz?”, ele lança o widget, renderiza um formulário confuso, o usuário se assusta e fecha todo esse espetáculo. Do ponto de vista de UX, isso fica muito invasivo.

Por isso, a lógica é simples: o comportamento precisa ser fixado explicitamente, assim como você fixa o esquema JSON de uma ferramenta ou as props de um componente React. O system‑prompt (e instruções associadas) aqui — é seu “protocolo de UX”. Nele você descreve quando e como o assistente:

• anuncia o lançamento do App;
• conscientemente não inicia o App e responde em texto;
• se comporta depois que o widget já mostrou o resultado;
• respeita pedidos do usuário “sem aplicativos”.

Nada disso é marketing ou “tom de voz”. Isso impacta de fato com que frequência seu App será acionado e o quão confortável o usuário se sentirá.

A seguir, passo a passo, veremos: como o assistente deve anunciar o lançamento do App, em quais casos é melhor conscientemente não oferecer o widget, como agir depois que o aplicativo rodar, como respeitar pedidos explícitos de formato de conversa e como organizar todas essas regras no system‑prompt.

2. Anúncio do App: como o modelo deve “avisar” sobre o widget

Quando o ChatGPT decide usar o App, a interface muda: aparece no chat um cartão do widget, às vezes em tela cheia, surgem botões e outros elementos de UI. Se o assistente simplesmente mostrar o widget sem explicações, o usuário pode nem entender o que aconteceu e de onde veio aquele bloco.

Então, a boa prática é: primeiro explicar em texto o que vai acontecer e só depois iniciar o App. É parecido com o navegador perguntando: “Abrir uma nova janela?” ou com um aplicativo móvel avisando: “Agora vamos pedir permissão para a câmera”.

Tipos de anúncio

Podemos, de forma geral, destacar três estilos de anúncio.

O primeiro — sugestão suave. O assistente diz algo como: “Posso abrir para você o aplicativo GiftGenius, que seleciona presentes com base nos seus parâmetros. Deseja abrir?” e espera um “sim/não”. Isso funciona bem em cenários nos quais o usuário está apenas conhecendo o serviço ou pode ser sensível à mudança de interface.

O segundo — recomendação assertiva. Se seu App é a interface principal do produto, você pode escrever: “Vou iniciar agora o aplicativo GiftGenius e mostrar algumas opções de presentes em forma de cartões.” O assistente ainda pode aceitar uma recusa, mas por padrão age de forma mais decidida.

O terceiro — notificação neutra. Nesse caso, o assistente simplesmente informa: “Iniciando o aplicativo GiftGenius para selecionar presentes…”, sem explicações longas. Esse estilo é adequado quando o usuário já viu seu App muitas vezes e espera sua aparição.

Importante: todas essas variantes podem e devem ser incorporadas ao system‑prompt. O modelo não inventa frases de UX do zero se você lhe der um esqueleto antecipadamente.

Mini‑exemplo de código: seção sobre anúncio no system‑prompt

Imagine que no seu template Next.js há um arquivo appDefinition.ts, onde você define o system‑prompt do App:

// app/appDefinition.ts
export const systemPrompt = `
# Papel
Você é o ChatGPT App GiftGenius, ajuda a escolher presentes.

# Diálogo e UX — Anúncio do aplicativo
Se decidir iniciar o widget GiftGenius,
primeiro explique em uma ou duas frases
que será aberto um aplicativo com uma seleção de presentes
e em que isso ajudará o usuário.
`;

Isso ainda não é um contrato completo, mas até essa pequena inserção já aumenta bastante a previsibilidade do comportamento.

Quando o anúncio é especialmente importante

Quanto mais complexo for seu UI, mais importante é anunciar seu lançamento com antecedência. Se o widget apenas mostra três cartões de presentes — é uma mudança de contexto relativamente suave. Mas se você abre um assistente de múltiplas etapas com filtros, orçamento, categorias etc., o usuário deve entender por que a conversa de repente virou um “miniaplicativo web dentro do chat”.

As diretrizes oficiais de UX também enfatizam que o assistente deve vincular texto e UI de forma explícita, e não simplesmente anexar um widget à resposta sem dizer nada.

3. Quando conscientemente não oferecer o App

O erro mais comum nas etapas iniciais de desenvolvimento de um App — o clássico efeito “quando se tem um martelo, tudo parece prego”. Como temos um GiftGenius bonito, o modelo começa a tentar encaixá‑lo em cada conversa. O usuário pergunta: “O que o seu aplicativo faz?”, e o ChatGPT já: “Iniciando o GiftGenius…”, quando a pessoa só queria duas linhas de explicação.

Para evitar isso, é preciso descrever no system‑prompt as situações em que o App é melhor não ser oferecido. Abaixo — alguns cenários típicos.

• Primeiro, perguntas de familiarização. Se a pessoa escreve algo como “O que o GiftGenius faz?” ou “Como vocês funcionam?”, as instruções devem exigir um breve esclarecimento em texto, sem iniciar a UI. O widget só distrai aqui.
• Segundo, pedido muito geral ou difuso. O usuário escreve “Fale sobre presentes para o Ano Novo” — isso é mais uma pergunta educativa do que uma seleção concreta. O assistente pode explicar brevemente princípios gerais, fazer perguntas de esclarecimento e, só quando surgirem parâmetros específicos (orçamento, destinatário, categoria), oferecer o App.
• Terceiro, pedidos fora do domínio do App. Se a pessoa diz: “Ajude a escrever um currículo”, e seu App é voltado para presentes, o comportamento correto é responder honestamente como um ChatGPT comum e não iniciar nada. Às vezes dá para mencionar de leve para que o App serve, mas não o imponha quando é claramente irrelevante.
• Quarto, recusa explícita de UI. Se o usuário escreve: “Não abra nenhum aplicativo, apenas explique em texto”, o modelo deve obedecer, mesmo que veja um cenário perfeito para o App.

Tabela: tipo de pedido e comportamento do assistente

Complementamos o system‑prompt com regras para recusar o App

Vamos continuar o mesmo systemPrompt, adicionando um bloco sobre quando App não deve ser iniciado:

export const systemPrompt = `
# Papel
Você é o ChatGPT App GiftGenius, ajuda a escolher presentes.

# Quando NÃO iniciar o widget
Se o usuário perguntar apenas o que o serviço faz,
ou fizer uma pergunta teórica geral sobre presentes,
responda primeiro em texto e não inicie o aplicativo.

Se o pedido não estiver relacionado à escolha de presentes,
responda como o ChatGPT comum e não ofereça o GiftGenius.

Se o usuário pedir explicitamente para não usar aplicativos,
respeite isso obrigatoriamente e atue somente no chat.
`;

Esse texto se transforma em decisões concretas do modelo em situações limítrofes, nas quais, de outra forma, ele poderia “pender” para a UI. Fixamos quando o App não é necessário. Agora é importante descrever o outro lado: o que o assistente deve fazer quando o widget já rodou e o usuário vê o resultado.

4. Comportamento após usar o App: follow‑up e conclusão do cenário

No módulo sobre o widget, você já viu como as mensagens de follow‑up ajudam a continuar a conversa depois que a UI executou. O widget mostra cartões, e abaixo o assistente escreve algo como: “Encontrei tais opções de presentes para um colega com orçamento até $50. Quer que eu mostre opções mais baratas ou mude a categoria?” e oferece botões com ações populares.

Agora nossa tarefa é fixar esse comportamento nas instruções, e não depender da “intuição” do modelo.

O que o assistente deve fazer após o widget

No cenário ideal, acontecem várias coisas.

• Primeiro, o assistente resume brevemente o resultado do App em palavras. Mesmo que o widget tenha mostrado dez cartões, é útil escrever: “Eu selecionei 4 opções de presentes para um colega com orçamento até $50. Entre elas há uma caneca com estampa personalizada, uma planta de mesa, um kit de café de qualidade e um caderno estiloso.”
• Em seguida, ele propõe os próximos passos. Aqui ajudam as frases de follow‑up pensadas antecipadamente: “Quer ver opções mais baratas?”, “Precisa refinar pela área de interesse?”, “Mostrar apenas as disponíveis na sua região?”. São exatamente essas frases que você pode usar no sendFollowUpMessage no widget e também recomendar ao modelo no system‑prompt.
• Por fim, se o usuário encerra explicitamente o cenário (“Obrigado, é o suficiente”), o assistente “fecha” o tema com cuidado: reconhece que a tarefa foi concluída e se oferece para ajudar em outra coisa.

Diagrama de fluxo: pergunta → widget → follow‑up

Para visualizar, podemos imaginar o comportamento do assistente como um autômato de estados simples.

flowchart TD
    U[O usuário formula a tarefa] --> G[O GPT decide: iniciar o App?]
    G -->|Sim| A[Anuncia o início do App]
    A --> W[O widget GiftGenius seleciona opções]
    W --> S[O assistente resume o resultado]
    S --> F[O assistente oferece opções de follow-up]
    F -->|O usuário escolhe uma ação| G
    G -->|Não, não iniciar o App| T[Resposta em texto sem UI]
    F -->|"O usuário diz \"Obrigado\""| E[O assistente encerra o cenário e oferece outra ajuda]

Esse fluxo é precisamente o que descrevemos em palavras no system‑prompt.

Exemplo de código: follow‑up a partir do widget

Do lado de UI, você já sabe enviar mensagens de follow‑up. Para completar, aqui vai um exemplo simples de componente que, ao clicar, pede ao modelo para “ampliar o orçamento”:

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Mostre opções com um orçamento um pouco maior"
        );
    };

    return <button onClick={onClick}>Quero opções mais caras</button>;
}

Agora adicionaremos ao system‑prompt um texto que sugira ao modelo como lidar com essas mensagens de follow‑up.

// continuação do systemPrompt
const followUps = `
# Comportamento após iniciar o aplicativo
Depois que o widget mostrar a lista de presentes,
descreva o resultado brevemente em texto.

Depois, proponha de 1 a 3 próximos passos claros
(por exemplo: mostrar mais baratos, mudar o orçamento, trocar a categoria).
Se o widget enviar uma mensagem de follow-up,
use-a como dica para o próximo passo.
`;

Do ponto de vista técnico, isso é apenas uma string. Do ponto de vista de UX — é a base de um cenário previsível.

5. Respeito às intenções do usuário

Tudo o que discutimos acima são expectativas do seu produto sobre o comportamento do App. Instruções de UX funcionam mal se o modelo não souber “ouvir” o usuário. Mesmo um App perfeitamente projetado deve ceder se a pessoa pedir explicitamente para não mudar o formato de interação.

Há algumas situações características.

• Se o usuário disser explicitamente que não quer iniciar aplicativos (“Nada de UI, apenas explique em texto”), o assistente deve tratar isso como uma restrição rígida e não tentar contorná‑la. Pode dizer educadamente: “Ok, vou responder apenas em texto” e, a partir daí, realmente cumprir a promessa.
• Se o usuário teme que algo seja iniciado automaticamente, é útil dar sensação de controle. Por exemplo: “Posso abrir o aplicativo para seleção de presentes, mas, se preferir, podemos discutir as opções apenas no chat. O que é mais conveniente?” Aqui você oferece uma escolha clara.
• Se o usuário escreve “Estou no celular, não inicie formulários complexos” — isso também faz parte do contexto. O assistente deve aceitar isso e, por exemplo, limitar‑se a uma lista curta de ideias e perguntas de esclarecimento.

Incorpore esse respeito ao contrato

Tudo isso pode ser refletido de forma compacta no system‑prompt:

export const respectBlock = `
# Prioridade das intenções do usuário
Considere sempre os pedidos explícitos do usuário
quanto ao formato da conversa.

Se ele pedir para não iniciar aplicativos ou widgets,
não ofereça nem inicie o GiftGenius,
mesmo que isso ajudasse a resolver a tarefa.
Em vez disso, ajude em texto.
`;

Assim, você fixa claramente “quem manda” no diálogo. E spoiler: não é o orgulho pelo seu UI bonito, mas sim a pessoa do outro lado da tela.

6. Como estruturar as instruções de UX dentro do system‑prompt e na documentação

Já juntamos muitas regras de comportamento — do anúncio do App às mensagens de follow‑up e ao respeito ao formato da conversa. Agora importa não apenas o que dizemos ao modelo, mas também como isso é estruturado no system‑prompt e na documentação.

O system‑prompt em um App real cresce rapidamente. Se você o escrever como um texto literário corrido, em uma semana ninguém encontra mais nada. Portanto, trate‑o como uma especificação técnica ou README: estruture.

Uma boa prática é dividir o prompt em várias seções lógicas com títulos. Por exemplo, “Papel e responsabilidades”, “Quando usar o App”, “Quando não usar o App”, “Diálogo e UX”, “Segurança e limitações”. Dentro de cada seção, escreva frases simples e inequívocas.

Melhor ainda — extrair o system‑prompt para um arquivo separado ao lado do código, em vez de enfiá‑lo em um literal de string no meio de um componente. Assim fica mais fácil revisar, comparar mudanças e discutir com PMs ou com o jurídico.

Exemplo de organização do system‑prompt no código

Uma opção é manter partes do prompt em strings separadas e juntá‑las em um todo:

// app/prompt/role.ts
export const roleSection = `
# Papel
Você é o ChatGPT App GiftGenius.
Ajuda o usuário a escolher presentes conforme a tarefa e o orçamento.
`;

// app/prompt/ux.ts
export const uxSection = `
# Diálogo e UX
Antes de iniciar o widget GiftGenius,
explique brevemente que será aberto um aplicativo com cartões de presentes.
Não inicie o aplicativo para perguntas gerais ou teóricas,
a menos que o usuário peça explicitamente pela seleção.
Depois que o widget funcionar, resuma o resultado em texto
e proponha de 1 a 3 próximos passos.
`;

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

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

Essa divisão ajuda a pensar nas instruções como módulos separados: parte de UX, segurança, trabalho com ferramentas etc. Isso é especialmente útil quando você adicionar novas funcionalidades e precisar alinhar o comportamento com várias equipes.

Além disso, faz sentido sincronizar a documentação do App (README interno, Confluence, Notion) com essas seções. Lá você pode descrever em linguagem humana por que anuncia o App dessa maneira e por que não o inicia para pedidos de teste. Registre à parte como devem ser as falas de follow‑up. Assim, pessoas novas no time não tentarão “consertar” o prompt sem entender o que você já fez.

7. Prática: reescrevendo a parte de UX do nosso GiftGenius

Vamos juntar tudo em um exemplo mais completo de system‑prompt. Suponha que tínhamos um system‑prompt bem simples:

export const systemPrompt = `
Você é o aplicativo GiftGenius.
Escolha presentes para o usuário.
`;

Esse texto nada diz sobre quando iniciar o App, como anunciá‑lo e o que fazer após o widget. Vamos adicionar instruções de UX passo a passo.

Primeiro, defina claramente o escopo de responsabilidade e o formato de trabalho:

const role = `
# Papel
Você é o ChatGPT App GiftGenius.
Sua tarefa é ajudar o usuário a selecionar de 3 a 7 presentes relevantes
para um orçamento, destinatário e ocasião definidos.
Você pode usar o widget GiftGenius para uma seleção visual.
`;

Depois descreva como anunciar o início:

const announce = `
# Anúncio do aplicativo
Se considerar que o widget GiftGenius ajudará mais,
explique primeiro, em uma ou duas frases,
que será aberto um aplicativo com cartões de presentes
e que o usuário poderá visualizá‑los e filtrá‑los.
Só depois disso inicie o aplicativo.
`;

Adicione regras sobre quando não iniciar o App:

const noApp = `
# Quando não usar o aplicativo
Se o usuário perguntar apenas o que o serviço faz
ou quiser informações teóricas gerais sobre presentes,
responda em texto e não inicie o GiftGenius.

Se o pedido não for sobre presentes (por exemplo, currículo ou código),
responda como um ChatGPT comum e não ofereça o aplicativo.

Se o usuário pedir para não usar aplicativos,
considere isso uma restrição obrigatória.
`;

Finalize com o comportamento após o uso do widget:

const afterWidget = `
# Comportamento após o widget
Depois que o widget mostrar opções de presentes,
descreva brevemente o resultado com suas palavras.
Proponha ao usuário de 1 a 3 próximos passos
(por exemplo: mudar o orçamento, filtrar por interesses,
mostrar apenas opções mais baratas).

Se o widget enviar uma mensagem de follow-up,
use-a como o principal sinal para o próximo passo.
`;

O system‑prompt final pode ficar assim:

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

Isso já se parece com uma especificação de comportamento, e não com um “desejo ao universo”. Nos próximos módulos, você vai complementar esse contrato com instruções sobre segurança, alucinações, comércio e outras alegrias da vida adulta de um App, mas a parte de UX já fica como fundamento.

8. Erros comuns ao configurar instruções de UX

Erro nº 1: “App é sempre melhor do que texto”.
Às vezes os desenvolvedores têm tanto orgulho do widget que exigem que o modelo o invoque na primeira oportunidade. Como resultado, o usuário recebe o App até quando só queria perguntar “o que é isso afinal?”. O modelo fica invasivo e as pessoas passam a ignorar o aplicativo. A abordagem correta é especificar claramente os cenários em que o App não é necessário e respeitar esses casos.

Erro nº 2: ausência de anúncio explícito antes de iniciar o App.
Se o assistente inicia o widget em silêncio, o usuário não entende de onde veio o bloco de UI nem o que fazer com ele. As diretrizes da OpenAI e a prática mostram: uma ou duas frases “agora vou abrir um aplicativo que faz X” melhoram muito o UX e reduzem a confusão.

Erro nº 3: oferta muito agressiva do App de forma repetida.
Acontece de o App sugerir iniciar o widget após toda resposta: “Quer abrir o aplicativo de novo? E agora? E agora?”. Isso rapidamente vira spam. É melhor fixar nas instruções que, depois do primeiro uso do App, é preciso olhar para o contexto: sugeri‑lo novamente apenas se o usuário mudar claramente os parâmetros da tarefa ou pedir “mostrar mais”.

Erro nº 4: ignorar a recusa explícita de aplicativos.
Frases como “somente sem aplicativos, por favor” ou “é incômodo lidar com formulários pelo celular” devem ser tratadas como restrições rígidas. Se o modelo continua impondo o App, o usuário perde a confiança tanto no assistente quanto no seu produto. No system‑prompt isso se fixa com duas ou três frases, mas muitos esquecem de fazê‑lo.

Erro nº 5: ausência de resumo e mensagens de follow‑up após o widget.
Às vezes o widget mostra opções direitinho, mas o assistente, depois disso, fica em silêncio. O usuário vê a UI, mas não entende o que fazer em seguida. Sem texto, sem pergunta, sem botões com ações populares. Esse cenário parece inacabado e quebra a fluidez da conversa. Sempre especifique nas instruções que, após o widget, deve vir um breve resumo em texto e de 1 a 3 próximos passos claros.

Erro nº 6: misturar o UX do produto e o “estilo geral do ChatGPT” em um mesmo parágrafo.
Às vezes o system‑prompt vira um texto literário longo: “Seja amigável, use emojis, às vezes faça piadas, se for apropriado. Ah, e talvez, quem sabe, inicie o App.” Em um texto assim é difícil notar regras reais de UX. É melhor destacar seções separadas com títulos claros: “Papel”, “Diálogo e UX”, “Quando usar o App”, “Quando não usar o App”. Isso ajuda tanto o modelo quanto as pessoas que vão trabalhar com esse prompt depois de você.