Design per la coda lunga
Non sovraccaricare
Nella fase dei requisiti, hai definito un insieme chiaro di casi d'uso chiave. Tieni presente queste priorità ed evita di aggiungere casi limite a questo elenco. Man mano che entri nel dettaglio nel design, emergono nuovi scenari che non avevi mai preso in considerazione. Prima di ampliare l'ambito del progetto per gestire questi nuovi scenari, valuta attentamente l'impatto.
| La testa | Il corpo | La coda lunga |
|---|---|---|
|
Casi d'uso principali Questi sono i percorsi di conversazione più importanti e comuni che gli utenti seguiranno nella funzionalità. Concentrati sul percorso più impegnativo per rendere questi percorsi un'esperienza utente ottimale. |
Deviazioni Si tratta di percorsi di conversazione meno comuni e spesso meno diretti o di minore successo attraverso la tua funzionalità. Prenditi il tempo necessario per supportarli adeguatamente, ma evita di dedicare troppo tempo e impegno alla loro progettazione. |
Casi limite Si tratta di percorsi molto insoliti. Valuta se messaggi generici come "Mi dispiace non so come aiutarti" sono sufficientemente buoni oppure se puoi essere un po' più specifico con una soluzione simile minimamente fattibile. |
Utilizza la regola 80/20, o Principio di Pareto, per evitare sovraprogettazioni.
Per la progettazione delle conversazioni, questa regola consente di indicare che non tutti i percorsi sono uguali. L'80% degli utenti segue il 20% dei percorsi più comuni in una finestra di dialogo. Investi quindi le risorse di conseguenza per ottenere il massimo impatto.
Analogamente, esistono compromessi in termini di perfezione o completezza. Per completare l'ultimo 20% del progetto potrebbe essere necessario l'80% del lavoro. In questi casi, lo sforzo non lucidato può essere "sufficientemente buono".
Deviazioni comuni
Tra i casi d'uso principali e i casi limite ci sono diverse deviazioni piuttosto comuni. Di solito si tratta di nuovi scenari che non avevi preso in considerazione fino a quando non sono stati rilevati durante i test o rilevati durante lo sviluppo. E la maggior parte delle volte richiede una gestione più lunga e meno diretta di un percorso alternativo.
Ecco un paio di deviazioni comuni da tenere in considerazione:
Account scollegati
In questo caso, l'utente non ha collegato il proprio account.
Azioni non supportate
Gli utenti potrebbero chiedere azioni non supportate dalla tua azione.
Copertura intenti
La progettazione delle conversazioni presuppone la scrittura di una metà del dialogo, nella speranza che sia sufficientemente solida da consentire a chiunque di intervenire e intervenire sull'altra metà. Durante la progettazione di elementi long-tail, concentrati su ciò che l'utente potrebbe dire in ogni passaggio della finestra di dialogo per definire i tuoi intenti (detti anche grammaticali).
Un intent rappresenta una mappatura tra ciò che dice un utente e cosa dovrebbe fare l'azione come risultato. Ad esempio, il messaggio "Ti piace la pizza?" richiede l'intento di "sì" e "no". A ogni intent deve essere associata una varietà di frasi di addestramento, tra cui sinonimi come "sì" e "no no", nonché varianti come "Mi piace" o "È pessimo". Questi potrebbero essere ponderati in base alla frequenza con cui si verificano. Gli intent possono anche includere l'annotazione, ad esempio categorizzando "mozzarella fresca" come pizza in cima alla risposta dell'utente "solo se è preparata con mozzarella fresca".
Se utilizzi Dialogflow, vai qui per saperne di più sugli intent.
Prevenire gli errori è meglio che gestire gli errori dopo che si sono verificati.
Azioni consigliate.
Includi un intent "completato" con frasi di addestramento come "Ho finito" o "Questo è tutto".
Non fare nulla.
Se l'azione prevede solo domande sull'I/O, la risposta dell'utente attiverà un errore di mancata corrispondenza.
Gestione degli errori
Anche se le intenzioni sono solide, c'è ancora spazio per gli errori. Gli utenti potrebbero ignorare lo script restando in silenzio (un errore No Input) o dire qualcosa di imprevisto (un errore No Match). Utilizza i messaggi di errore per indirizzare delicatamente gli utenti verso percorsi riusciti o per reimpostare le loro aspettative su ciò che è o non è possibile.
Una buona gestione degli errori è specifica del contesto, quindi le richieste di errore Nessun input e Nessuna corrispondenza devono essere progettate per ogni svolta della finestra di dialogo.