Linee guida UX di OpenAI: quando mostrare App e come non «monopolizzare» il dialogo

1. Chat‑first: ChatGPT — prima di tutto è una chat, poi vengono le applicazioni

Nei primi 6 moduli abbiamo affrontato tutti gli aspetti dell’applicazione: dalla UI e MCP fino al debug e al deploy. Ora ripasseremo ancora una volta tutti i suoi lati, ma più a fondo. Non pensavate che fosse tutto così semplice, vero?

E iniziamo dalla UX, più precisamente dagli UI‑requirements ufficiali e dalle UX‑guidelines. Volete che la vostra app superi la review, giusto? Ottimo, allora partiamo dalla cosa più interessante: il cambio di mentalità necessario a un frontend developer abituato a SPA/Next.js: ChatGPT — è prima di tutto un’interfaccia conversazionale, e l’App — è un ospite all’interno di questo dialogo. Non il contrario.

OpenAI nelle sue linee guida lo formula così: le applicazioni estendono ciò che può fare l’utente, senza spezzare il flusso della conversazione. Un widget non è una nuova scheda del browser, ma un inserto discreto nella chat, che offre struttura quando con il solo testo diventa difficile.

La cosa più semplice è ricordarlo tramite la divisione dei ruoli.

Ruoli di GPT e App

All’interno di ChatGPT ci sono due «personaggi»:

GPT rimane il narratore principale. Con le parole spiega che cosa succederà, perché propone l’App, che cosa significano i pulsanti, e riassume il risultato del lavoro del widget. L’App, a sua volta, è focalizzata sulla parte visiva e sulle azioni: selezione di opzioni, impostazione di filtri, avanzamento dei passi di un wizard.

Una regola molto importante, da ripetere come un mantra: tutte le decisioni importanti devono essere esplicitate nella risposta testuale di GPT, anche se l’utente fa clic sulla UI. L’utente non è tenuto a leggere ogni riga nell’interfaccia del widget — le conseguenze chiave (per esempio, «abbiamo effettuato l’ordine» o «hai scelto questi parametri») devono essere annunciate nella chat.

2. Quando l’App è davvero necessaria: criteri di visualizzazione

Dal punto di vista tecnico potete richiamare un widget a ogni messaggio. Ma dal punto di vista UX — è come aprire un dialogo a schermo intero a ogni carattere digitato nell’input. Funziona — sì. Vivere così — no.

OpenAI e l’Apps SDK propongono un principio semplice: l’App è appropriata quando con essa è più facile ragionare rispetto al solo testo.

Richieste con struttura e scenario ripetibile

L’App è particolarmente utile quando la richiesta dell’utente suggerisce già una struttura:

• «Scegli 5 idee regalo per un collega fino a $50».
• «Confronta questi tre piani tariffari».
• «Crea un itinerario di 3 giorni a Tokyo».
• «Mostra la mia lista di attività per la settimana e aiutami a definire le priorità».

In tutti questi casi ci sono entità evidenti (regali, piani tariffari, giorni dell’itinerario, attività) con cui bisogna interagire, e passi: scegliere, filtrare, confrontare, confermare. Qui una UI con card, checkbox e filtri è giustificata e persino salvifica.

Esempi per GiftGenius

Prendiamo il nostro protagonista GiftGenius. Ecco una richiesta tipica:

Bisogna scegliere regali per 10 invitati a un matrimonio, con budget e interessi diversi.

Con il solo testo GPT potrebbe elencare 10 liste separate, ma leggerle sarebbe faticoso. Molto meglio:

• mostrare una tabella con invitati, budget e interessi,
• dare la possibilità di filtrare «meno caro/più caro»,
• visualizzare un set di card per ogni invitato.

Qui l’App è praticamente obbligatoria: troppe entità e troppi parametri per gestire tutto solo via testo.

Al contrario:

Cosa regalare a mio fratello con un budget di 5000 ₽?

È una domanda semplice, a un solo passo. GPT può rispondere con un testo che propone 3–5 idee, e solo se l’utente chiede «mostra opzioni dove posso filtrare per hobby ed età», si può passare in modo fluido all’App.

Mini euristica

Utile tenere a mente una tabella semplice:

Parleremo in dettaglio di inline e fullscreen nelle prossime lezioni, ma è già evidente: l’App è uno strumento per compiti strutturati e multistep, non per ogni «sono triste, che cosa faccio?».

3. Quando l’App intralcia: modalità «parlare» e riflessioni

Abbiamo visto in quali casi l’App semplifica davvero la vita e aiuta a strutturare il dialogo. Ma c’è anche il rovescio della medaglia: esistono situazioni in cui qualsiasi UI non fa che disturbare.

Tutta questa enfasi sul «disegniamo la UI» porta spesso a un riflesso: «oh, l’utente ha chiesto qualcosa — è ora di avviare il widget». Questo è il momento in cui, nella review dello Store, potreste prendere un malus sull’UX.

C’è un’intera classe di richieste in cui l’App è spesso dannosa:

1. Utente in modalità «parlare». Si tratta di riflessioni filosofiche, domande personali, dilemmi di carriera, conversazioni di tipo terapeutico. In questi scenari l’utente si aspetta una conversazione testuale, domande di chiarimento, talvolta empatia. Inserire card e filtri qui verrà percepito come un banner di spam.
2. Domande introduttive sul servizio. Se qualcuno scrive «Raccontami che cosa può fare GiftGenius», vuole una panoramica, non una UI immediata. Qui GPT è meglio che prima spieghi brevemente lo scopo dell’App, magari con alcuni esempi di richieste, e solo dopo proponga con tatto di provare il widget.
3. Domande teoriche generali. «Come scegliere regali per gli introversi?» oppure «Come funziona un programma fedeltà nei negozi?» — questo è uno scenario formativo, non transazionale. GPT può dare una buona risposta testuale e, alla fine, aggiungere senza invadenza: «Se vuoi posso aprire GiftGenius e scegliere alcune opzioni concrete».

Ovunque la UI non porti un valore nuovo, ma replichi soltanto il testo, è meglio restare nella chat. È questo il rispetto per le intenzioni dell’utente, di cui gli esperti UX amano tanto parlare.

4. Come proporre l’App: auto‑launch contro «humble handoff»

Anche se siete convinti che l’App sia appropriata, la domanda «come avviarla» resta aperta. Variante brusca: il widget si apre all’improvviso in fullscreen senza preavviso. Variante corretta: GPT prima spiega a parole che cosa accadrà e chiede il consenso o almeno informa.

Nella documentazione UX delle ChatGPT Apps si distinguono due pattern: auto‑launch e suggestion (humble handoff).

Auto‑launch: quando l’utente lo chiede esplicitamente

L’auto‑launch è appropriato quando l’utente esprime un intento esplicito:

Avvia GiftGenius.
Apri le impostazioni di GiftGenius.
Mostra il mio carrello dei regali in GiftGenius.

Qui le regole sono semplici:

1. GPT scrive brevemente qualcosa come «Apro GiftGenius…».
2. Il modello richiama subito lo strumento / widget.

Il dialogo potrebbe apparire così:

Utente: Avvia GiftGenius, voglio scegliere un regalo per un amico.
GPT: Apro l’assistente GiftGenius per la selezione dei regali.
[Compare il widget di GiftGenius inline o a schermo intero]

L’avvio automatico senza ulteriori chiarimenti è giustificato, perché l’utente ha chiesto esplicitamente di «aprire».

Suggestion (humble handoff): quando l’intento è implicito

In molti casi l’utente non conosce affatto la vostra applicazione. Scrive:

Bisogna pensare a qualcosa per un collega per il compleanno, il budget è ridotto.

Il pattern corretto è:

1. GPT analizza la richiesta e capisce che l’App può aiutare.
2. GPT pone 1–2 domande di chiarimento o propone subito l’App a parole.
3. Solo dopo il consenso o un’indicazione esplicita — avvia il widget.

Esempio:

Utente: Bisogna pensare a qualcosa per un collega per il compleanno, il budget è ridotto.
GPT: Posso aiutare con idee direttamente oppure aprire l’app GiftGenius, dove selezioneremo le opzioni per budget e interessi. Preferisci solo consigli o provare l’app?
Utente: Proviamo l’app.
GPT: Apro GiftGenius per selezionare le opzioni regalo.
[Compare il widget]

Questo approccio sottolinea che l’iniziativa resta comunque all’utente, e l’App è un’opzione, non un banner imposto. Si sposa bene con il principio «Respect user’s intent» delle linee guida UX.

Mini esempio di «classificatore di intenti» in TypeScript

Immaginiamo che lato backend stiate già classificando grossolanamente la richiesta dell’utente (da non confondere con GPT stesso; è una logica di supporto):

// Tipo semplificato di intenti dell'utente
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Quale trigger per l'App vogliamo usare
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "avvia GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // richiesta implicita
  return 'avoid';                                // chat normale, senza App
}

Questa logica di per sé non avvia il widget — è piuttosto un modo per formalizzare il vostro approccio UX. Poi traducete queste regole nel system‑prompt e nelle descrizioni dell’App, in modo che il modello si comporti nello stesso spirito.

5. Come non «prendere il controllo» del dialogo: pattern buoni e cattivi

Nella documentazione di OpenAI e negli articoli sul design UX per le ChatGPT Apps è formulato in modo piuttosto chiaro che cosa non fare: non «rubare» la conversazione. Cioè non trasformare la chat in un canale di promozione della vostra interfaccia.

Antipattern

Il più doloroso è il «widget‑sorpresa». È quando l’utente sta conducendo una conversazione profonda e all’improvviso tutto lo schermo viene occupato da un’app a schermo intero che non ha richiesto. Si perde il contesto e anche la sensazione di controllo.

Un altro peccato frequente è usare l’App come pubblicità. Per esempio, l’utente fa una domanda teorica e il modello risponde: «Prima apro il nostro super‑widget, lì è tutto spiegato» e mostra una UI in cui metà è testo di marketing. Le linee guida ufficiali chiamano esplicitamente questi scenari «poor use cases».

Terzo antipattern — frequenti e inutili passaggi avanti e indietro tra UI e testo. Se a ogni piccolo chiarimento si avvia e si chiude l’App, il dialogo ricorda una ghirlanda lampeggiante. L’utente, soprattutto su mobile, si stancherà in fretta.

Buone pratiche

In tutti gli scenari in cui decidete di aprire l’App, cercate di attenervi a tre regole semplici.

Primo, preannunciate. Lasciate che GPT dica esplicitamente che aprirà l’app e perché. Per esempio: «Ora apro l’assistente GiftGenius per mostrare le opzioni sotto forma di card». Sono 1–2 righe, ma cambiano completamente la percezione del passaggio.

Secondo, spiegate che cosa fare nella UI. Non tutti sono abituati a una nuova interfaccia. GPT può aggiungere testo: «In basso vedrai le card dei regali, puoi cambiare pagina e premere “Dettagli” su qualsiasi opzione». Se nel widget c’è qualcosa di inconsueto (per esempio, «Mostra ancora N» o filtri non standard), è meglio dirlo a parole.

Terzo, riassumete il risultato in testo. Dopo che l’App ha fatto qualcosa (selezionato, calcolato, inviato), GPT deve raccontarlo brevemente: «Ho selezionato 3 opzioni di regali. Le prime due entro $50, la terza è un po’ più cara ma con consegna rapida. Vuoi restringere la scelta?» È particolarmente importante su dispositivi mobili e in scenari vocali: la persona potrebbe non guardare la UI, ma ascolterà il riassunto testuale.

6. Ruolo del system‑prompt e delle descrizioni dell’App nella gestione della UX

Finora avete visto come il system‑prompt definisce la «personalità» dell’App e come il modello usa gli strumenti. Ora aggiungiamo regole UX: quando proporre l’App, come annunciarla, quando evitarla.

Che cosa inserire nel system‑prompt

Per GiftGenius il system‑prompt può includere una sezione «Dialogo e UX». Nella documentazione e negli articoli si consiglia di descriverla in modo strutturato, con regole separate.

Esempio di frammento (pseudocodice, ma molto vicino alla realtà):

### Dialogo e UX

1. Se l'utente fornisce le condizioni per la selezione del regalo (per chi, budget, occasione),
   prima poni 1–2 domande di chiarimento in testo.
2. Dopo i chiarimenti proponi di aprire l'App GiftGenius:
   "Posso aprire l'assistente GiftGenius per mostrare le opzioni regalo. Aprire?"
3. Se l'utente chiede esplicitamente "avvia GiftGenius" o "mostra l'elenco dei regali",
   rispondi "Apro GiftGenius..." e richiama subito l'App senza ulteriori domande.
4. Se l'utente chiede teoria o consigli generali (ad esempio, "come scegliere i regali"),
   rispondi in testo e non aprire l'App finché non lo chiede esplicitamente.
5. Se l'utente dice "non aprire l'app" o "rispondi solo in testo",
   in seguito non proporre l'App in questo dialogo.
6. Dopo il lavoro dell'App riassumi sempre il risultato in testo (brevemente).

Qui sono codificati in modo conciso tutti i nostri principi UX: chat‑first, rispetto del rifiuto dell’utente, differenza tra auto‑launch e suggest, riassunto testuale obbligatorio.

Come aiutarsi con i config TypeScript

Nei progetti reali è comodo conservare parte di queste regole in forma strutturata (per non dover cercare dopo il testo nei prompt a mano). Per esempio, si può introdurre un semplice config:

// Tipo ipotetico per la configurazione dei trigger UX dell'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' },
];

Questo config non viene letto dal modello — serve a voi sviluppatori per raccogliere in un unico posto gli accordi prodotto/design e poi trasferirli con cura nel system‑prompt, nelle descrizioni dell’App e nella documentazione.

7. Esempio: come GPT annuncia GiftGenius senza «intercettare» la conversazione

Colleghiamo tutto alla nostra applicazione. Immaginiamo che l’utente scriva per la prima volta in chat:

Cerco un regalo per un collega, circa fino a 3000 ₽, ama i giochi da tavolo.

Una buona risposta del modello (considerando il nostro system‑prompt) potrebbe essere così:

Capito! Precisiamo un paio di dettagli e individuiamo alcune idee.

Dimmi più o meno quanti anni ha e se è un regalo piuttosto formale o da parte di un amico stretto.

(Dopo la tua risposta posso aprire l’assistente GiftGenius, dove vedremo le opzioni sotto forma di card.)

Dopo il chiarimento GPT scrive:

Perfetto, ho informazioni sufficienti.

Ora apro l’app GiftGenius — lì ti mostrerò alcune opzioni regalo sotto forma di card; potrai vedere i dettagli e restringere la scelta per budget e tipo di gioco.

E solo dopo — avvio dell’App. Nessuna «sorpresa», tutto è spiegato a parole.

Un piccolo componente React di «annuncio dell’App» all’interno del widget

Dal punto di vista del codice, il widget in genere viene renderizzato quando viene richiamato. Ma potete incorporare nella sua UI la filosofia del «non intercettare» il contesto, anche se è già aperto.

Per esempio, la prima schermata di GiftGenius può essere molto semplice:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Selezione di regali con GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        Mostrerò alcune opzioni sotto forma di card. Potrete
        scegliere quelle che vi piacciono e ChatGPT spiegherà pro e contro.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        In qualsiasi momento potete tornare alla chat normale e continuare la conversazione.
      </p>
    </section>
  );
}

Questo componente non fa nulla di «potente» tecnicamente, ma dal punto di vista UX è importante: ricorda che la chat non è scomparsa e che il ruolo di GPT resta centrale.

In seguito proprio da questa schermata introduttiva passerete alle card dei regali, ai wizard e così via, ma questo è già argomento delle prossime lezioni.

8. Pratica ed esercizi

Sopra abbiamo raccolto una serie di principi — chat‑first, rispetto delle intenzioni dell’utente, distinzione tra auto‑launch e proposta dell’App. Per fissare l’approccio «quando e come mostrare l’App», è utile pensare a richieste reali e distinguere esplicitamente quando l’App serve e quando no. Per la pratica a casa potete fare due piccoli esercizi.

Per prima cosa prendete GiftGenius e inventate 5–7 richieste degli utenti. Per ciascuna rispondete onestamente:

• conviene proporre subito di aprire l’App;
• conviene solo menzionare l’App come opzione;
• oppure è meglio non collegare affatto la risposta all’App.

Esempi:

1. «Regala qualcosa a mia moglie per l’anniversario, budget fino a $1000» — molto probabilmente prima un paio di domande di chiarimento in testo, poi la proposta di aprire l’App.
2. «Come incartare un regalo in modo originale?» — domanda puramente teorica, si può fare a meno dell’App.
3. «Avvia GiftGenius, voglio scegliere regali per tutto il team» — auto‑launch diretto.

Secondo esercizio — il testo di annuncio dell’avvio dell’App. Provate a scrivere 1–2 frasi brevi con cui GPT spiegherà all’utente il passaggio all’App. Confrontate toni diversi: più formale («Apro l’app GiftGenius…») e più amichevole («Proviamo l’assistente GiftGenius — sarà più facile confrontare le opzioni»).

Così imparerete a pensare non solo come sviluppatori, ma anche come autori del dialogo.

9. Errori tipici nell’UX «quando mostrare l’App»

Errore n. 1: mostrare l’App a ogni menzione dell’argomento.
Una deriva frequente: se l’App tratta di regali, qualunque parola «regalo» nella chat scatena subito il widget. L’utente chiede «come non sbagliare il regalo al capo», e invece di un consiglio genuino riceve una UI con card. Questo è percepito come pubblicità e ignora la vera intenzione dell’utente, in diretto contrasto con le linee guida UX ufficiali e il principio «Respect user’s intent».

Errore n. 2: fullscreen senza preavviso.
Il «widget‑sorpresa» che all’improvviso occupa tutto lo schermo è un modo sicuro per rovinare l’esperienza. Soprattutto nel mezzo di una conversazione lunga, quando l’utente non si aspettava un passaggio brusco dal testo alla UI. Secondo le linee guida di OpenAI, tali scenari sono cattiva pratica; è sempre necessario annunciare il passaggio e, se possibile, chiedere il consenso.

Errore n. 3: UI al posto della risposta.
Talvolta gli autori dell’App pensano: «Perché rispondere in testo, tanto abbiamo una bella interfaccia!» Di conseguenza, GPT quasi non dice nulla, e tutte le «risposte» sono nascoste nel widget. L’utente, soprattutto in modalità vocale o su mobile, potrebbe non notare dettagli importanti. L’approccio corretto — la UI integra la risposta, non la sostituisce: l’App mostra dettagli e opzioni, GPT spiega che cosa significano.

Errore n. 4: ignorare il rifiuto dell’utente dell’App.
Se la persona dice esplicitamente «non aprire l’app» o «rispondi solo in testo», l’App deve prenderlo come regola ferrea fino alla fine del dialogo. Continuare a proporre l’App ogni due messaggi è come un pop‑up insistente «valuta il nostro servizio». Queste cose peggiorano la UX e possono influire sulla review nello Store. Nel system‑prompt bisogna codificare esplicitamente il rispetto del rifiuto.

Errore n. 5: nessuna distinzione tra auto‑launch e «proposta».
Quando lo sviluppatore non distingue tra intenzioni esplicite e implicite, o non avvia mai l’App anche quando l’utente lo chiede chiaramente, oppure l’avvia sempre, anche quando l’utente ha solo accennato «magari un giorno proverò la vostra App». Ne derivano avvii automatici del widget «solo perché la parola somiglia». Formalizzare i trigger (auto / suggest / avoid) e una logica ben pensata nel system‑prompt aiuta a evitare questa confusione.

Errore n. 6: totale assenza di regole UX nel system‑prompt.
A volte tutte le decisioni UX vivono solo «nella testa del team», e il system‑prompt si limita a «Sei l’assistente GiftGenius, aiuta con i regali». Di conseguenza, il modello a volte propone l’App, a volte la dimentica, a volte la apre in momenti inopportuni. Regole UX scritte e strutturate nel system‑prompt e nella documentazione sono un artefatto importante quanto lo schema JSON degli strumenti.

Errore n. 7: tentare di «aggiustare la UX dopo».
Approccio diffuso — prima «far funzionare tutto», e poi un giorno pensare alla UX. Nel caso delle ChatGPT Apps, questo porta al fatto che vi siete già legati a determinati pattern di richiamo degli strumenti, e cambiare il system‑prompt e il comportamento di GPT è più difficile. Meglio impostare da subito almeno le linee guida UX di base: chat‑first, rispetto del rifiuto, criteri chiari per mostrare l’App e assenza di «widget‑sorpresa». Così tutto lo sviluppo successivo (pattern inline, fullscreen, voice) poggerà su fondamenta solide.