Progettare la navigazione del bot

si applica a: SDK v4

Gli utenti possono esplorare i siti Web usando percorsi di navigazione, app usando menu e Web browser usando pulsanti come avanti e indietro. Tuttavia, nessuna di queste tecniche di navigazione ben consolidate soddisfa completamente i requisiti di navigazione all'interno di un bot. Come illustrato in Progettare e controllare il flusso di conversazione, gli utenti spesso interagiscono con i bot in modo non lineare, rendendo difficile progettare lo spostamento dei bot che offre in modo coerente un'esperienza utente ottimale.

Considerare i seguenti dilemma:

• Come si garantisce che un utente non si perda in una conversazione con un bot?
• Un utente può tornare indietro in una conversazione con un bot?
• In che modo un utente passa al "menu principale" durante una conversazione con un bot?
• In che modo un utente "annulla" un'operazione durante una conversazione con un bot?

Le specifiche della progettazione di navigazione del bot dipendono in gran parte dalle funzionalità e dalle funzionalità supportate dal bot. Indipendentemente dal tipo di bot in fase di sviluppo, è consigliabile evitare le insidie comuni delle interfacce conversazionali progettate in modo non appropriato. Questo articolo descrive queste insidie in termini di cinque personalità: il "bot testardo", il "bot inconsapevole", il "bot misterioso", il "bot capitano ovvio" e il "bot che non può dimenticare".

Suggerimento

La mitigazione di ogni tipo di queste personalità per il bot può spesso essere eseguita gestendo correttamente le interruzioni dell'utente.

Il "bot testardo"

Il bot testardo insiste sul mantenimento del corso corrente della conversazione, anche quando l'utente tenta di orientare le cose in una direzione diversa.

Si consideri lo scenario seguente:

Gli utenti spesso cambiano idea, decidono di annullare o a volte vogliono ricominciare completamente.

Suggerimento

Do: progettare il bot per considerare che un utente potrebbe tentare di modificare il corso della conversazione in qualsiasi momento.

Non: progettare il bot per ignorare l'input dell'utente e continuare a ripetere la stessa domanda in un ciclo infinito.

Un modo per impedire a un bot di porre la stessa domanda senza fine è specificare un numero massimo di tentativi per ogni domanda. Se progettato in questo modo, il bot non esegue alcuna operazione intelligente per comprendere l'input dell'utente, ma evita di porre la stessa domanda in un ciclo infinito.

Il "bot senza indizi"

Il bot senza indizi risponde in modo senza senso quando non comprende il tentativo di accesso a determinate funzionalità da parte di un utente. Un utente può provare comandi di parole chiave comuni come "help" o "cancel" con aspettative ragionevoli che il bot risponderà in modo appropriato.

Si consideri lo scenario seguente:

Anche se si potrebbe essere tentati di progettare ogni dialogo all'interno del bot per restare in ascolto e rispondere in modo appropriato a determinate parole chiave, questo approccio non è consigliato.

Suggerimento

Operazione: implementare il middleware che esaminerà l'input dell'utente per le parole chiave specificate (ad esempio: "help", "cancel", "start over" e così via) e rispondere in modo appropriato.

Non: progettare ogni finestra di dialogo per esaminare l'input dell'utente per un elenco di parole chiave.

Definendo la logica nel middleware, è possibile renderla accessibile a ogni scambio con l'utente. È quindi possibile creare singoli dialoghi e richieste per ignorare in modo sicuro le parole chiave, se necessario.

Il "bot misterioso"

Il bot misterioso non riesce a riconoscere immediatamente l'input dell'utente in alcun modo.

Si consideri lo scenario seguente:

In alcuni casi, questa situazione potrebbe essere un'indicazione che il bot ha un'interruzione. Tuttavia, potrebbe essere solo che il bot sta elaborando l'input dell'utente e non ha ancora completato la compilazione della risposta.

Suggerimento

Do: progettare il bot per confermare immediatamente l'input dell'utente, anche nei casi in cui il bot potrebbe richiedere del tempo per compilare la risposta.

Non: progettare il bot in modo da posticipare la conferma dell'input dell'utente fino a quando il bot non ha completato la compilazione della sua risposta.

Riconoscendo immediatamente l'input dell'utente, si elimina qualsiasi potenziale confusione per quanto riguarda lo stato del bot. Se la risposta richiede molto tempo per essere elaborata, considera l'invio di un messaggio di "digitazione" per indicare il funzionamento del bot, e successivamente invia un messaggio proattivo.

Il "bot capitano ovvio"

Il bot Capitan Ovvio fornisce informazioni non richieste completamente ovvie e quindi inutili per l'utente.

Si consideri lo scenario seguente:

Suggerimento

Do: progettare il bot per fornire informazioni utili per l'utente.

Non: progettare il bot per fornire informazioni non richieste che è improbabile che siano utili per l'utente.

Progettando il bot per fornire informazioni utili, si aumentano le probabilità che l'utente interagisca con il bot.

Il "bot che non può dimenticare"

Il bot che non può dimenticare integra in modo inappropriato le informazioni delle conversazioni precedenti nella conversazione corrente.

Si consideri lo scenario seguente:

Suggerimento

Do: progettare il bot per mantenere l'argomento corrente della conversazione, a meno che/finché l'utente non esprime il desiderio di rivedere un argomento precedente.

Non: progettare il bot per inserire informazioni dalle conversazioni precedenti quando non è rilevante per la conversazione corrente.

Mantenendo l'argomento corrente della conversazione, si riduce il potenziale di confusione e frustrazione e si aumentano le probabilità che l'utente continuerà a interagire con il bot.

Passaggi successivi

Progettando il bot per evitare queste insidie comuni di interfacce conversazionali progettate in modo non appropriato, si sta prendendo un passo importante per garantire un'esperienza utente ottimale.

Altre informazioni sugli elementi dell'esperienza utente su cui si basano in genere i bot per scambiare informazioni con gli utenti.