Come dovrebbero riconoscere i prodotti di chat companion quando un utente vuole fermarsi?
Un prodotto di chat companion dovrebbe trattare un chiaro messaggio di stop come un'istruzione, riconoscere quando l'attività richiesta è completata e consentire all'utente di mettere in pausa senza doverne spiegare il motivo. Quando lo scambio è terminato, dovrebbe chiudere brevemente e lasciare la mossa successiva all'utente. Un modo pratico per progettare questo comportamento consiste nell'ordinare i segnali in base alla loro chiarezza, dare la priorità alle richieste esplicite ed evitare di fare supposizioni a partire dall'umore o dal silenzio dell'utente.
Parti dalle parole dell'utente, non da una teoria sul suo umore
Messaggi come "stop", "ho finito", "basta così", "arrivederci" o "fermiamoci qui" sono la prova diretta che l'utente desidera terminare lo scambio. Integra queste frasi, insieme alle loro variazioni naturali, nella gestione dello stop del prodotto. Trattale come istruzioni di controllo durante tutta la conversazione, anche durante un'attività creativa o mentre il sistema sta ponendo una domanda.
Ciò segue le linee guida consolidate di conversation design. Google raccomanda di rispettare espressioni come "ho finito" e "lascia perdere", indicando di non mettere in dubbio la scelta di chi vuole abbandonare un'attività incompleta quando si perderebbe poco progresso. Analogamente, Amazon Lex definisce uno stop intent per le frasi che indicano che l'utente desidera terminare un'interazione. (Linee guida di Google sulle conclusioni delle conversazioni; stop intent integrato di Amazon Lex)
La risposta del prodotto dovrebbe confermare la ricezione dell'istruzione una sola volta e terminare il turno. Ad esempio: "Ricevuto. Possiamo fermarci qui." Non far seguire a questa conferma un'altra domanda, un invito a continuare a parlare o una richiesta di giustificare la decisione. Un comando di stop non dovrebbe trasformarsi in una piccola negoziazione in cui l'utente deve ripetersi.
Tratta il completamento come un naturale punto di chiusura
Un utente potrebbe finire senza dire "stop". Potrebbe chiedere un racconto breve e riceverlo, scegliere un'idea per un'attività nel fine settimana o finire di revisionare un messaggio. Una volta fornito l'output richiesto e in assenza di parti irrisolte dell'attività, il sistema può chiudere con una breve dichiarazione come "Ecco la versione finale" o "Questo ti dà un piano per sabato." Non è necessario aggiungere automaticamente "Cos'altro vorresti fare?"
Questa è un'inferenza progettuale derivata dalle linee guida volte a mantenere le risposte conversazionali brevi, pertinenti e focalizzate sull'attività. La checklist di conversation design di Amazon raccomanda passaggi minimi e messaggi pertinenti, sconsigliando di interrompere un'esperienza con un'offerta non correlata. Applicato alla chat companion, ciò suggerisce di rendere le domande di follow-up subordinate a un reale passaggio successivo, piuttosto che associarne una a ogni risposta completata. (Principi di conversation design di Amazon Alexa)
Ci sono delle eccezioni. Se la richiesta è composta da più parti, il prodotto dovrebbe completare le parti promesse o indicare chiaramente cosa rimane da fare. Se un utente chiede una bozza e una revisione, restituire solo la bozza non rappresenta un'attività completata. Ma una volta soddisfatto l'ambito concordato, un prompt aperto può far sembrare incompiuta un'interazione conclusa. Una chiusura concisa evita che il sistema espanda silenziosamente il compito dell'utente.
Rendi la pausa facile da esprimere e facile da riprendere
Mettere in pausa è diverso dal terminare. "Facciamo una pausa", "Ci tornerò più tardi", "un momento" o "salva questo per dopo" possono segnalare che l'utente desidera un'interruzione conservando il lavoro svolto. Laddove il prodotto supporti la cronologia delle conversazioni o le bozze salvate, può confermare in un linguaggio semplice cosa rimarrà disponibile. Se non è in grado di preservare lo stato attuale, dovrebbe comunicarlo prima che l'utente se ne vada, qualora tale limite sia rilevante.
Mantieni la pausa sotto il controllo dell'utente. Non richiedere una spiegazione né suggerire un motivo per l'interruzione. Se il prodotto dispone di un comando visibile per mettere in pausa o chiudere, etichettalo chiaramente e attribuiscigli un risultato prevedibile. Le linee guida del W3C sul controllo dell'utente affermano che i cambiamenti di contesto dovrebbero essere avviati dall'utente o disporre di un meccanismo per disattivarli; tale principio sostiene comandi chiari e comportamenti prevedibili per le transizioni. (Linee guida W3C su Change on Request)
Il prodotto dovrebbe inoltre distinguere una pausa da uno stop esplicito utilizzando le parole e le azioni disponibili nell'interfaccia. Una pausa può preservare una bozza o la posizione all'interno di un'attività, se la funzionalità lo supporta. Uno stop dovrebbe terminare l'interazione corrente. Non dichiarare che una conversazione è salvata a meno che non lo sia davvero, e non considerare l'uscita dall'app o il silenzio come una richiesta di inviare ulteriori messaggi.
Usa un ordine chiaro per segnali ambigui ed espliciti
Una gerarchia utile dei segnali per l'implementazione è:
Stop esplicito o arrivederci: termina prontamente lo scambio.
Richiesta esplicita di pausa o salvataggio: metti in pausa o salva se supportato, quindi conferma brevemente il risultato.
Richiesta completata: fornisci il risultato richiesto e chiudi senza richiedere un altro turno.
Messaggio non chiaro: poni una sola breve domanda di chiarimento, esclusivamente quando l'ambiguità blocca l'attività.
Silenzio: attendi o termina la sessione attiva in base al comportamento normale del prodotto; non dedurre uno stato emotivo.
Questo ordinamento è una proposta pratica di progettazione, non una metrica pubblicata o un classificatore universale. Il suo scopo è evitare che le istruzioni dirette vengano scavalcate da supposizioni più deboli. Ad esempio, "Basta così" dovrebbe avere la precedenza sulla previsione del sistema secondo cui un suggerimento correlato potrebbe essere gradito. Una domanda come "Intendi fermarti qui o salvare per dopo?" è appropriata solo quando la formulazione dell'utente lascia realmente incerti tali esiti.
Se un prodotto supporta un'azione di grande impatto o rischia di far perdere una parte significativa di lavoro, una conferma può essere appropriata per proteggere tale lavoro. Mantieni la conferma specifica e facile da rispondere: "Vuoi fermarti ora ed eliminare questa bozza?" Per le normali conversazioni in cui si perderebbero pochi progressi, una conferma ripetuta crea un attrito inutile. Le linee guida di Google tracciano la stessa distinzione: non verificare due volte un'uscita a meno che non vadano persi progressi significativi. (Linee guida di Google sulle conclusioni delle conversazioni)
Mantieni la risposta di chiusura breve e completa
Un messaggio di chiusura dovrebbe svolgere un unico compito: chiarire che il sistema ha compreso l'utente e che l'interazione è terminata o in pausa. Esempi appropriati includono:
Stop: "Va bene. Ci fermiamo qui."
Attività creativa completata: "Ecco la poesia revisionata."
Pausa con lavoro salvato: "In pausa. La tua bozza è salvata in questa chat."
Pausa senza funzionalità di salvataggio: "Va bene. Potrai tornare a questa chat più tardi, ma non posso salvare una bozza separata."
Usa solo affermazioni che corrispondano al reale comportamento del prodotto. Evita appelli emotivi, frasi colpevolizzanti o nuove domande. Una chiusura può essere calorosa senza chiedere all'utente di rassicurare il sistema o di continuare l'interazione. L'obiettivo del design è una conclusione chiara di cui l'utente possa fidarsi.
Testa i casi limite, non solo i comandi ovvi
Esamina brevi esempi di conversazione tratti dall'uso comune: uno stop diretto durante una storia, un "basta così" dopo una raccomandazione, un'attività di scrittura completata, una richiesta di pausa a metà percorso e un ambiguo "magari più tardi". Verifica che ciascun caso porti al comportamento previsto e che non compaia una domanda di follow-up dopo un chiaro stop o un'attività completata.
Controlla anche la presenza di falsi positivi. "Smetti di usare quella frase e provane un'altra" contiene la parola "smetti", ma è un'istruzione all'interno dell'attività, non necessariamente una richiesta di terminare la chat. Interpreta le parole nel contesto, mantenendo al contempo disponibile un comando di stop dedicato nel caso in cui il sistema fraintenda il linguaggio. La documentazione di Amazon descrive uno stop intent integrato per le frasi di stop più comuni; un prodotto di chat companion può utilizzare la stessa idea di base adattando il riconoscimento alla propria interfaccia testuale o vocale. (Stop intent integrato di Amazon Lex)
Monitora i fallimenti pratici come una richiesta di stop seguita da un'altra domanda, un'attività completata che innesca un prompt irrilevante o una pausa che perde il lavoro pur avendo lasciato intendere che fosse salvato. Questi sono controlli comportamentali osservabili, non giudizi su ciò che l'utente prova. Aiutano i team a migliorare l'interazione senza tentare di fare diagnosi sugli utenti a partire dalle loro parole.
Una semplice regola per una conclusione rispettosa
Quando l'utente conclude chiaramente lo scambio, fermati. Quando l'attività concordata è completata, chiudi brevemente. Quando l'utente chiede di mettere in pausa, preserva il suo controllo e spiega il comportamento di salvataggio disponibile. Poni una domanda di follow-up solo quando è necessaria per completare la richiesta o risolvere una reale ambiguità. Ciò offre ai prodotti di chat companion un modo concreto per riconoscere le conclusioni, lasciando le scelte ordinarie, i tempi e la continuazione all'utente.