Istruzioni sulla UX: annuncio App, rinuncia a App e comportamento nel dialogo

1. Perché gestire la UX tramite istruzioni

Dal punto di vista di ChatGPT la tua App è solo strumenti e widget aggiuntivi. Ma per l'utente è un'interfaccia a sé stante che compare all'improvviso in mezzo alla conversazione. Se non si governa il comportamento del modello, si possono ottenere due scenari estremi.

In un caso GPT ignora la App e prova a “risolvere tutto a parole”. L'utente chiede di scegliere un regalo, e il modello invece di avviare GiftGenius restituisce un lungo saggio testuale con raccomandazioni “di suo”. A volte non è male, ma non hai scritto la tua App perché prenda polvere sullo scaffale.

Nel secondo caso GPT, al contrario, abusa della App. A ogni minimo starnuto tipo “Che cosa sa fare il vostro servizio?” avvia un widget, renderizza un modulo confuso, l'utente si spaventa e chiude tutto questo splendore. Dal punto di vista UX risulta molto invadente.

Perciò la logica è semplice: il comportamento va fissato esplicitamente, così come fissi lo schema JSON di uno strumento o le props di un componente React. Il system‑prompt (e le istruzioni correlate) qui è il tuo “protocollo UX”. In esso descrivi quando e come l'assistente:

• annuncia l'avvio della App;
• consapevolmente non avvia la App, ma risponde in testo;
• si comporta dopo che il widget ha già mostrato il risultato;
• rispetta le richieste dell'utente “senza applicazioni”.

Tutto questo non riguarda il marketing né lo stile di conversazione. Influisce davvero su quanto spesso la tua App verrà chiamata e su quanto a proprio agio si sentirà l'utente.

Di seguito, passo dopo passo, vedremo: come l'assistente deve annunciare l'avvio della App, in quali casi sia meglio non proporre il widget, come comportarsi dopo che l'applicazione ha lavorato, come rispettare le esplicite richieste dell'utente sul formato del dialogo e come confezionare con cura tutte queste regole nel system‑prompt.

2. Annuncio App: come il modello deve “avvisare” del widget

Quando ChatGPT decide di utilizzare la App, l'interfaccia cambia: nella chat appare una card del widget, talvolta a schermo intero, compaiono pulsanti e altri elementi UI. Se l'assistente mostra il widget senza spiegazioni, l'utente può non capire affatto che cosa sia successo e da dove sia spuntato quel blocco.

Quindi è buona norma spiegare prima a parole che cosa sta per accadere e solo dopo avviare la App. È come quando il browser chiede: “Aprire una nuova finestra?” oppure come un'app mobile avverte: “Ora chiederemo il permesso per la fotocamera”.

Tipi di annuncio

Si possono, grosso modo, distinguere tre stili di annuncio.

Il primo — proposta soft. L'assistente dice qualcosa del tipo: “Posso aprire per te l'applicazione GiftGenius, che seleziona regali in base ai tuoi parametri. La apro?” e aspetta la risposta “sì/no”. Funziona bene negli scenari in cui l'utente sta solo conoscendo il servizio o può essere sensibile al cambio di interfaccia.

Il secondo — raccomandazione decisa. Se la tua App è l'interfaccia principale del prodotto, puoi scrivere: “Ora avvio l'app GiftGenius e mostro alcune opzioni di regali come card.” L'assistente può comunque tenere conto di un rifiuto, ma per impostazione predefinita agisce in modo più deciso.

Il terzo — notifica neutra. In questo caso l'assistente si limita a comunicare: “Avvio l'app GiftGenius per la selezione dei regali…”, senza lunghe spiegazioni. È adatto quando l'utente ha già visto molte volte la tua App e ne prevede l'apparizione.

Importante: tutte queste varianti si possono e si devono codificare nel system‑prompt. Il modello non inventa frasi UX da zero se gli fornisci in anticipo uno scheletro.

Mini‑esempio di codice: sezione sull'annuncio nel system‑prompt

Immagina che nel tuo template Next.js ci sia il file appDefinition.ts, dove definisci il system‑prompt per la App:

// app/appDefinition.ts
export const systemPrompt = `
# Ruolo
Sei la ChatGPT App GiftGenius, aiuti a scegliere i regali.

# Dialogo e UX — Annuncio dell'applicazione
Se decidi di avviare il widget GiftGenius,
prima spiega in una-due frasi
che ora si aprirà un'app con una selezione di regali
e in che modo aiuterà l'utente.
`;

Non è ancora un contratto completo, ma anche un inserto così piccolo aumenta molto la prevedibilità del comportamento.

Quando l'annuncio è particolarmente importante

Più complessa è la tua UI, più è importante anticiparne l'avvio. Se il widget mostra solo tre card di regali, è un cambio di contesto relativamente soft. Se invece apri un wizard multistep con filtri, budget, categorie ecc., l'utente deve capire perché il dialogo si è trasformato all'improvviso in una “piccola web‑app dentro la chat”.

Anche le linee guida UX ufficiali sottolineano che l'assistente deve collegare esplicitamente testo e UI, non aggiungere silenziosamente un widget alla risposta.

3. Quando non proporre consapevolmente la App

L'errore più comune nelle prime fasi di sviluppo di una App è il classico effetto “se hai un martello, tutto ti sembra un chiodo”. Dal momento che abbiamo un bel GiftGenius, il modello cerca di tirarlo in ogni dialogo. L'utente chiede: “Che cosa fa la vostra applicazione?”, e ChatGPT già: “Avvio GiftGenius…”, anche se alla persona bastavano due righe di spiegazione.

Per evitarlo, nel system‑prompt bisogna descrivere le situazioni in cui è meglio non proporre la App. Qui sotto — alcuni scenari tipici.

• Primo, domande conoscitive. Se qualcuno scrive qualcosa come “Che cosa fa GiftGenius?” oppure “Come lavorate?”, le istruzioni devono richiedere prima una breve spiegazione testuale, senza avviare l'UI. Il widget qui è solo una distrazione.
• Secondo, richiesta troppo generale o vaga. L'utente scrive “Raccontami i regali per Capodanno” — è più una domanda informativa che una selezione concreta. L'assistente può spiegare brevemente i principi generali, porre domande di chiarimento e solo quando compaiono parametri specifici (budget, destinatario, categoria) proporre la App.
• Terzo, richieste fuori dal dominio della App. Se qualcuno dice: “Aiutami a scrivere il CV”, ma la tua App è fatta per i regali, il comportamento corretto è rispondere onestamente come un normale ChatGPT e non avviare nulla. A volte si può menzionare con tatto a cosa serve la App, ma non bisogna imporla quando è chiaramente irrilevante.
• Quarto, rifiuto esplicito dell'UI. Se l'utente scrive: “Non aprire nessuna applicazione, spiegami solo a parole”, il modello deve obbedire, anche se vede uno scenario ideale per la App.

Tabella: tipo di richiesta e comportamento dell'assistente

Completiamo il system‑prompt con regole sul non usare la App

Continuiamo lo stesso systemPrompt, aggiungendo un blocco su quando non avviare la App:

export const systemPrompt = `
# Ruolo
Sei la ChatGPT App GiftGenius, aiuti a scegliere i regali.

# Quando NON avviare il widget
Se l'utente chiede solo che cosa sa fare il servizio
o pone una domanda teorica generale sui regali,
rispondi prima a testo e non avviare l'applicazione.

Se la richiesta non è collegata alla selezione di regali,
rispondi come un normale ChatGPT e non proporre GiftGenius.

Se l'utente chiede esplicitamente di non usare applicazioni,
rispetta obbligatoriamente e lavora solo in chat.
`;

Un testo del genere si trasforma in decisioni concrete del modello nelle situazioni limite, dove altrimenti potrebbe “tirare la coperta” verso l'UI. Abbiamo fissato quando la App non serve. Ora è importante descrivere il rovescio della medaglia: che cosa deve fare l'assistente quando il widget ha già lavorato e l'utente vede il risultato.

4. Comportamento dopo l'uso della App: follow‑up e chiusura dello scenario

Nel modulo sul widget hai già visto come i messaggi di follow‑up aiutino a proseguire il dialogo dopo che l'UI ha lavorato. Il widget mostra delle card e sotto di esse l'assistente scrive qualcosa del tipo: “Ho trovato queste opzioni di regali per un collega con budget fino a $50. Vuoi che mostri opzioni più economiche o cambi categoria?” e propone pulsanti con azioni popolari.

Ora il nostro compito è fissare questo comportamento nelle istruzioni, invece di affidarci all’“intuizione” del modello.

Cosa deve fare l'assistente dopo il widget

Nello scenario ideale accadono diverse cose.

• Per prima cosa l'assistente riassume brevemente a parole il risultato del lavoro della App. Anche se il widget ha mostrato dieci card, è utile scrivere: “Ho selezionato 4 opzioni di regali per un collega con budget fino a $50. Tra queste ci sono una tazza con stampa personalizzata, una pianta da scrivania, un set di buon caffè e un taccuino elegante.”
• Poi propone i prossimi passi. Qui aiutano frasi di follow‑up pensate in anticipo: “Vuoi vedere opzioni più economiche?”, “Serve restringere la scelta in base agli interessi?”, “Mostrare solo quelle disponibili nella tua regione?”. Proprio queste frasi puoi usarle in sendFollowUpMessage nel widget, e anche raccomandarle al modello nel system‑prompt.
• Infine, se l'utente chiude esplicitamente lo scenario (“Grazie, basta così”), l'assistente “chiude” con tatto l'argomento: riconosce che il compito è risolto e propone aiuto su qualcos'altro.

Diagramma di flusso: domanda → widget → follow‑up

Per chiarezza, si può immaginare il comportamento dell'assistente come un semplice automa a stati.

flowchart TD
    U[L'utente formula una richiesta] --> G[GPT decide: avviare l'App?]
    G -->|Sì| A[Annuncia l'avvio dell'App]
    A --> W[Il widget GiftGenius seleziona le opzioni]
    W --> S[L'assistente riassume il risultato]
    S --> F[L'assistente propone opzioni di follow-up]
    F -->|L'utente sceglie un'azione| G
    G -->|No, non avviare l'App| T[Risposta testuale senza UI]
    F -->|"L'utente dice \"Grazie\""| E[L'assistente chiude lo scenario e offre altro aiuto]

Questo flusso lo descriviamo di fatto a parole nel system‑prompt.

Esempio di codice: follow‑up dal widget

Dal lato UI sai già inviare messaggi di follow‑up. Per completezza, ecco un semplice esempio di componente che, dopo il clic, chiede al modello di “aumentare il budget”:

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Mostra opzioni con un budget leggermente più alto"
        );
    };

    return <button onClick={onClick}>Voglio opzioni più costose</button>;
}

Ora aggiungeremo nel system‑prompt un testo che suggerisca al modello come elaborare tali messaggi di follow‑up.

// continuazione di systemPrompt
const followUps = `
# Comportamento dopo l'avvio dell'applicazione
Dopo che il widget ha mostrato l'elenco dei regali,
descrivi brevemente a testo il risultato.

Poi proponi 1–3 prossimi passi chiari
(per esempio: mostrare più economici, cambiare budget, cambiare categoria).
Se il widget invia un messaggio di follow-up,
usalo come suggerimento per il passo successivo.
`;

Dal punto di vista tecnico è una normale stringa. Dal punto di vista UX — è la base di uno scenario prevedibile.

5. Rispettare le intenzioni dell'utente

Tutto ciò di cui abbiamo parlato sopra sono le tue aspettative di prodotto sul comportamento della App. Le istruzioni UX funzioneranno male se il modello non sa “ascoltare” l'utente. Anche una App progettata perfettamente deve cedere se la persona chiede esplicitamente di non cambiare il formato dell'interazione.

Ci sono alcune situazioni tipiche.

• Se l'utente dice esplicitamente di non voler avviare applicazioni (“Niente UI, spiegami solo cosa comprare”), l'assistente deve considerarlo un vincolo rigido e non provare ad aggirarlo. Si può dire con cortesia: “Ok, risponderò solo a testo”, e poi mantenere davvero la parola.
• Se l'utente teme che qualcosa si avvii automaticamente, è utile dargli una sensazione di controllo. Per esempio: “Posso aprire un'app per la selezione dei regali, ma se preferisci possiamo discutere le opzioni direttamente in chat. Come ti è più comodo?” Qui offri esplicitamente una scelta.
• Se l'utente scrive “Sono da telefono, non avviare moduli complessi” — anche questo è parte del contesto. L'assistente deve accettarlo e, per esempio, limitarsi a un breve elenco di idee e domande di chiarimento.

Integrare il rispetto nel contratto

Tutto questo si può riflettere in modo compatto nel system‑prompt:

export const respectBlock = `
# Priorità alle intenzioni dell'utente
Tieni sempre in considerazione le richieste esplicite dell'utente
sul formato della conversazione.

Se chiede di non avviare applicazioni o widget,
non proporre e non avviare GiftGenius,
anche se ciò aiuterebbe a risolvere il compito.
Invece, aiuta a testo.
`;

In questo modo fissi chiaramente “chi è il capo” nel dialogo. Spoiler: non è l'orgoglio per la tua bella UI, ma la persona viva dall'altra parte dello schermo.

6. Come strutturare le istruzioni UX all'interno del system‑prompt e nella documentazione

Abbiamo già messo insieme parecchie regole di comportamento — dall'annuncio della App ai messaggi di follow‑up e al rispetto del formato di dialogo. Ora conta non solo cosa diciamo al modello, ma anche come è organizzato nel system‑prompt e nella documentazione.

Il system‑prompt in una App reale cresce in fretta. Se lo scrivi come un testo letterario continuo, dopo una settimana nessuno ci capirà più niente. Quindi trattalo come una specifica tecnica o un README: strutturalo.

Una buona pratica è dividere il prompt in più sezioni logiche con titoli. Per esempio, “Ruolo e area di responsabilità”, “Quando usare la App”, “Quando non usare la App”, “Dialogo e UX”, “Sicurezza e limitazioni”. Dentro ogni sezione scrivi con frasi semplici e univoche.

Ancora meglio — estrarre il system‑prompt in un file separato vicino al codice, invece di infilarlo in un literal di stringa in mezzo a un componente. Così sarà più facile fare review, confrontare le modifiche e discuterlo con product o legali.

Esempio di organizzazione del system‑prompt nel codice

Una delle opzioni — conservare le parti del prompt in stringhe separate e assemblarle in un unico tutto:

// app/prompt/role.ts
export const roleSection = `
# Ruolo
Sei la ChatGPT App GiftGenius.
Aiuti l'utente a selezionare regali in base al compito e al budget.
`;

// app/prompt/ux.ts
export const uxSection = `
# Dialogo e UX
Prima di avviare il widget GiftGenius
spiega brevemente che ora si aprirà un'app con card di regali.
Non avviare l'app per domande generali o teoriche,
se l'utente non chiede esplicitamente una selezione.
Dopo il lavoro del widget, riassumi il risultato a testo
e proponi 1–3 prossimi passi.
`;

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

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

Questa suddivisione aiuta a pensare alle istruzioni come a moduli separati: parte UX, sicurezza, lavoro con gli strumenti ecc. Tornerà particolarmente utile quando aggiungerai nuove funzionalità e dovrai concordare il comportamento con più team.

Inoltre, ha senso sincronizzare la documentazione della App (README interno, Confluence, Notion) con queste sezioni. Lì puoi descrivere in linguaggio naturale perché annunci la App in quel modo e perché non la avvii per richieste di prova. Fissa a parte quali devono essere le battute di follow‑up. Così le persone nuove nel team non proveranno a “sistemare” il prompt senza capire cosa avevi fatto.

7. Pratica: riscriviamo la parte UX per il nostro GiftGenius

Mettiamo insieme tutto in un esempio di system‑prompt più o meno completo. Supponiamo che il nostro system‑prompt fosse molto scarno:

export const systemPrompt = `
Sei l'applicazione GiftGenius.
Seleziona regali per l'utente.
`;

Un testo simile non dice quando avviare la App, come annunciarla e cosa fare dopo il widget. Aggiungiamo le istruzioni UX passo dopo passo.

Per prima cosa, definiamo chiaramente l'area di responsabilità e il formato di lavoro:

const role = `
# Ruolo
Sei la ChatGPT App GiftGenius.
Il tuo compito è aiutare l'utente a selezionare 3–7 regali pertinenti
in base al budget, al destinatario e all'occasione.
Puoi usare il widget GiftGenius per una selezione visuale.
`;

Poi descriviamo come annunciarne l'avvio:

const announce = `
# Annuncio dell'applicazione
Se ritieni che il widget GiftGenius aiuti meglio,
prima spiega in una-due frasi
che ora si aprirà un'app con card di regali
e che l'utente potrà visualizzarle e filtrare.
Solo dopo avvia l'applicazione.
`;

Aggiungiamo le regole su quando non avviare la App:

const noApp = `
# Quando non usare l'applicazione
Se l'utente chiede solo che cosa sa fare il servizio
o vuole informazioni teoriche generali sui regali,
rispondi a testo e non avviare GiftGenius.

Se la richiesta non riguarda i regali (per esempio, CV o codice),
rispondi come un normale ChatGPT e non proporre l'applicazione.

Se l'utente chiede di non usare applicazioni,
consideralo un vincolo obbligatorio.
`;

E concludiamo con il comportamento dopo l'uso del widget:

const afterWidget = `
# Comportamento dopo il widget
Dopo che il widget ha mostrato le opzioni di regali,
descrivi brevemente il risultato con parole tue.
Proponi all'utente 1–3 prossimi passi
(per esempio: cambiare budget, filtrare per interessi,
mostrare solo opzioni più economiche).

Se il widget ha inviato un messaggio di follow-up,
usalo come segnale principale per il passo successivo.
`;

Il system‑prompt finale può apparire così:

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

Questo assomiglia già a una specifica di comportamento, non a un “desiderio all'universo”. Nei moduli successivi completerai questo contratto con istruzioni su sicurezza, allucinazioni, commercio e altre gioie della vita adulta di una App, ma la parte UX è già un fondamento solido.

8. Errori tipici nella configurazione delle istruzioni UX

Errore n. 1: “App è sempre meglio del testo”.
A volte gli sviluppatori sono così orgogliosi del loro widget da chiedere al modello di chiamarlo in ogni occasione. Di conseguenza l'utente riceve la App anche dove voleva solo chiedere “che cos'è, in generale?”. Il modello diventa invadente e le persone iniziano a ignorare l'applicazione. L'approccio corretto è definire esplicitamente gli scenari in cui la App non è necessaria e rispettare tali casi.

Errore n. 2: assenza di un annuncio esplicito prima dell'avvio della App.
Se l'assistente avvia il widget in silenzio, l'utente non capisce da dove venga il blocco UI e cosa farci. Le linee guida di OpenAI e l'esperienza pratica mostrano che una-due frasi “ora apro un'app che farà X” migliorano drasticamente la UX e riducono la confusione.

Errore n. 3: proposta troppo aggressiva di riaprire la App.
Capita che la App dopo ogni risposta proponga di avviare di nuovo il widget: “Vuoi aprire di nuovo l'app? E adesso? E ora?”. Diventa rapidamente spam. Meglio fissare nelle istruzioni che, dopo il primo utilizzo, la App vada proposta di nuovo solo se l'utente cambia chiaramente i parametri del compito o chiede lui stesso di “mostrarne altri”.

Errore n. 4: ignorare il rifiuto esplicito delle applicazioni.
Frasi come “solo senza applicazioni, per favore” o “da telefono non mi è comodo lavorare con i moduli” devono essere trattate come vincoli rigidi. Se il modello continua a imporre la App, l'utente perde fiducia sia nell'assistente sia nel tuo prodotto. Nel system‑prompt si fissa facilmente con due‑tre frasi, ma molti se ne dimenticano.

Errore n. 5: assenza di riepilogo e messaggi di follow‑up dopo il widget.
A volte il widget mostra onestamente le opzioni e l'assistente poi tace. L'utente vede l'UI ma non capisce cosa fare dopo. Nessun testo, nessuna domanda, nessun pulsante con azioni popolari. Uno scenario così sembra incompleto e rompe la coerenza del dialogo. Indica sempre nelle istruzioni che dopo il widget deve seguire un breve riepilogo testuale e 1–3 prossimi passi chiari.

Errore n. 6: mescolare la UX di prodotto e lo “stile generale di ChatGPT” nello stesso paragrafo.
A volte il system‑prompt diventa un lungo testo creativo: “Sii amichevole, usa emoji, scherza a volte, se opportuno. E sì, magari ogni tanto avvia la App.” In un testo del genere è difficile notare le vere regole UX. Meglio evidenziare sezioni separate con titoli chiari: “Ruolo”, “Dialogo e UX”, “Quando usare la App”, “Quando non usare la App”. Aiuta sia il modello sia le persone che lavoreranno con questo prompt dopo di te.