Perché utilizzare le interfacce vocali e come progettarle
Riflessioni e linee guida tratte dal libro“Don’t Make Me Tap!”: A Common Sense Approach to Voice Usability — di Ahmed Bouzid e Weiye Ma.
Perché è sempre più importante lo sviluppo di interfacce vocali per le applicazioni?
Questa è la prima domanda a cui rispondono @Ahmed Bouzid e Weiye Ma nell’istruttivo “Don’t Make Me Tap!”, libro che delinea principi e modalità di progettazione delle interfacce vocali.
La voce è lo strumento che più di ogni altro permette di ridurre l’attrito che gli utenti sperimentano con qualsiasi user interface, così affermano gli autori, ed è il mezzo più efficace per scambiare grandi quantità di informazioni, l’espressione e la comprensione sono infatti più rapide quando si parla e si ascolta rispetto a quando si scrive e si legge.
Le caratteristiche del mezzo vocale risultano sempre più vincenti, proseguono Bouzid e Ma, in un contesto di crescente interazione con un numero sempre maggiore di “oggetti intelligenti” con i quali siamo chiamati ed abbiamo l’opportunità di “dialogare” allo scopo di facilitare le nostre azioni (tema su cui è lecito porsi legittime domande, ma questo sarà con ogni probabilità il futuro).
La voce permette inoltre di trasmettere informazioni ulteriori rispetto al messaggio, come il genere, la personalità, lo stato emotivo, e consente di comunicare in una serie di situazioni in cui l’interazione scritta sarebbe impossibile (quando si hanno le mani occupate o al buio, ad esempio).
Le potenzialità della voce sono poi significativamente supportate e amplificate dallo sviluppo delle tecnologie wearable.
Non è però sempre e comunque preferibile servirsi di un’interfaccia vocale.
Bouzid e Ma descrivono i fattori da analizzare per determinare se sia o meno la voce lo strumento migliore di interazione, che identificano nell’ambiente (rumoroso o meno, che permetto o no un livello accettabile di privacy), nel contenuto, nello stato psico-fisico dell’utente (non in tutte le condizioni è possibile avere un’interazione vocale efficace) e infine nel mezzo (telefono, chat, video-call..).
Entrando nelle caratteristiche e linee guida per la progettazione di un’efficace VUI, prima di tutto viene sottolineato che una buona VUI non si ottiene “semplificando” una GUI nell’ottica di un utilizzo vocale.
La progettazione di interazioni vocali ha infatti una serie di specificità e complessità caratteristiche di cui tenere conto.
Tra le caratteristiche principali evidenziate nel testo, vi sono il fatto che la comunicazione vocale ha un “accoppiamento lineare” con il tempo, è unidirezionale ed ha una natura “invisibile”, che fa sì che facilmente l’utente abbia la sensazione di “perdersi”, cosa che di norma non succede con le GUI, per quanto possano essere state non ben progettate.
Definita la conversazione come il meccanismo che permette lo scambio metodico di informazioni strutturate, gli autori passano all’esame delle “regole” che implicitamente sono alla base delle conversazioni, date dalla qualità (buona) delle informazioni scambiate, dalla loro quantità, che deve essere appropriata, dalla rilevanza delle informazioni nell’ambito dell’interazione, dall’appropriatezza del linguaggio utilizzato e dalla cooperazione che si presuppone esistere tra gli interlocutori. Il fatto che anche solo una di queste regole venga disattesa fornisce indirettamente delle informazioni.
Venendo alla progettazione/scrittura delle espressioni (prompt), si sottolinea che è fondamentale considerare la natura del messaggio che deve essere trasmesso, che può essere classificato in varie tipologie e utilizzare il linguaggio più appropriato nel contesto specifico dell’interazione.
Si suggerisce di inserire le informazioni più importanti all’inizio della conversazione, di non usare slang, di porre le domande in modo cortese e diretto e di non mescolare per quanto possibile parti registrate e “text to speech” (voce sintetica).
Tra i concetti interessanti che ritornano anche più avanti nel testo, si invita a tenere conto del fatto che gli utenti sono portati ad “imitare” il sistema (elemento importante nella definizione del linguaggio, per avere il “ritorno” desiderato, e da valutare in relazione agli obiettivi dell’interazione) e a mantenere la coerenza nel linguaggio utilizzato.
Si consiglia poi di prevedere percorsi più rapidi e diretti per gli utenti esperti e, sempre al fine di strutturare un’interazione più “leggera” ed efficace possibile, di richiedere conferme esplicite solo se necessario.
Alcune indicazioni fornite dagli autori sono specifiche per la lingua inglese, e rendono evidente lo spazio e la necessità di definire linee guida e buone prassi per le singole lingue utilizzate nelle interfacce.
Partendo dalla constatazione (che forse potrebbe essere messa in discussione?) che i menù rimangono la soluzione più efficiente per raccogliere informazioni dagli utenti, vengono elencate una serie di linee guida per la loro progettazione, tenendo conto delle specificità del mezzo voce.
I consigli, brevemente sintetizzati, consistono nell’inserire all’inizio del menù l’opzione più rilevante, nel cercare in linea generale di non superare le tre opzioni (data la natura invisibile della voce, da valutarsi anche in relazione alla complessità delle opzioni stesse), nel fare esempi di quello che può dire “correttamente” l’utente e dare dei punti di riferimento all’utente contrassegnando lo stato di avanzamento della conversazione e nel permettere all’utente di chiedere che cosa può dire e tornare indietro nella selezione. Si suggerisce poi di ripetere le opzioni del menù dopo tre secondi di pausa e di insegnare agli utenti percorsi “rapidi” di selezione.
Viene dunque definito il linguaggio come il set di possibili risposte “corrette”/”ammissibili” che un utente può fornire in risposta ad una domanda del sistema e la grammatica come la descrizione compatta del linguaggio.
Bouzid e Ma affermano che la progettazione di un efficace speech recognition language è legata alla capacità di definire un buon compromesso tra la flessibilità (data dal non limitare in modo eccessivo le risposte possibili dell’utente) e l’accuratezza (che permette di “circoscrivere” il più possibile il linguaggio). L’assunzione di un linguaggio troppo “ampio” può infatti portare più facilmente ad un errore da parte del sistema di riconoscimento, mentre la definizione di un linguaggio troppo “stretto” rischia di portare al contrario all’esclusione di risposte che l’utente potrebbe ragionevolmente fornire.
Un altro insieme di sfide e di complessità, da approfondire in relazione alle singole lingue, è legato poi alla struttura stessa del linguaggio, ed in particolare alla somiglianza tra singole frasi all’interno del linguaggio. Più somiglianze ci sono infatti tra le singole espressioni, più elevato sarà il rischio di confusione.
Nella definizione del linguaggio e della grammatica, il testo suggerisce prima di tutto di basarsi sull’uso reale della lingua.
Si consiglia poi di considerare le varianti di formulazione delle espressioni, includere i sinonimi, escludere le espressioni di intercalare, i sospiri, le esclamazioni, di non considerare se possibile i monosillabi acusticamente simili e di cercare di utilizzare lunghezze diverse di formulazione per le diverse risposte possibili e opzioni, al fine di ridurre gli errori del sistema di riconoscimento.
La bontà di un sistema, come sottolineano gli autori, si vede anche e soprattutto dalla sua capacità di gestire gli errori e la mancata comprensione di quanto detto dall’utente.
I principali errori possono essere di mancato input o di mancato match (che si verifica quando l’utente dice qualcosa che il sistema “non si aspetta”). In questi casi, gli autori identificano le buone pratiche sintetizzate a seguire:
- far sì che sia il sistema a prendersi la responsabilità dell’errore e non trattare mai l’utente in modo aggressivo
- dare all’utente una seconda possibilità
- fornire un suggerimento di risposta, con esempi di guida
- riformulare in modo diverso la domanda dalla quale è stato generato l’errore
- stabilire dei “punti di sicurezza” all’interno della conversazione, ai quali l’utente può ritornare (ad esempio i menù)
- non terminare mai un’interazione nel corso di un processo di error recovery (in questa situazione le azioni consigliate sono quelle di portare l’utente ad un “punto di sicurezza”, di trasferirlo ad un operatore umano, di procedere — semplicemente — nel flusso di dialogo, di fornire agli utenti informazioni utili per realizzare il loro obiettivo)
- non essere ripetitivi nel corso del processo di error recovery — cambiare le modalità di formulazione della richiesta, sfruttando le diverse formulazioni per dare all’utente informazioni utili per fornire una risposta “corretta”
- aiutare l’utente a capire il contesto in cui si trova
- passare alla possibilità di inviare le informazioni digitando, se è una soluzione realizzabile
- passare al sistema di digitazione se l’ambiente è rumoroso
- non chiudere la comunicazione senza avvertire l’utente
Gli autori evidenziano poi che il sistema di supporto all’utente, date le specificità del mezzo voce, dovrà essere particolarmente mirato e non noioso.
Il testo sottolinea che la progettazione del sistema di supporto all’utente deve essere basata sull’analisi delle difficoltà che può incontrare l’utente. Il sistema di supporto dovrà evidenziare il compito “base” al quale il sistema stava cercando di dare risposta ed offrire prioritariamente aiuto rispetto alle richieste più frequenti e probabili.
Nel caso in cui il sistema risulti particolarmente complesso, gli autori indicano l’opportunità di presentare un menù che permetta di selezionare la tipologia di aiuto richiesto.
E’ necessario che il sistema sia in grado di identificare gli utenti che necessitano di aiuto (chi non risponde, risponde in modo inappropriato o fornisce una risposta negativa ad una richiesta di conferma di un task andato a buon fine, ad esempio) e che sia in grado di riprendere l’interazione dal punto a cui era arrivato l’utente prima di chiedere aiuto.
Il sistema di supporto, proseguono poi gli autori, deve essere conciso e specifico (non deve “approfittare” della sua funzione per perdersi nella descrizione delle sue capacità), deve servirsi del contesto e di esempi per fornire spiegazione e, soprattutto, deve attivarsi solo quando è necessario.
Il libro affronta dunque il tema dei “contrassegni” o “marcatori” del flusso di dialogo (parole come “ok”, “next”, “finally”, in inglese), che rappresentano uno strumento di particolare utilità per confermare che l’interazione sta procedendo correttamente e rispetto ad alcuni obiettivi specifici come la conferma di ricezione corretta di un’informazione, l’annuncio che si sta per fornire una particolare informazione, l’indicazione dell’inizio o della fine di una sezione.
I “marcatori di dialogo” sono poi uno strumento utile per segnalare eventuali errori, e possono essere impiegati per riformulare la domanda all’utente.
“Contrassegnare” con determinate parole il flusso di dialogo permette inoltre di dare forma e consistenza alla conversazione, rendendola più naturale.
I marcatori di dialogo possono poi essere utilizzati per comunicare all’utente che si sta per raggiungere l’obiettivo o che si è alla fine del processo, per indicare implicitamente che il “turno” di conversazione è ancora in mano al sistema, per dire all’utente esplicitamente che è stato messo in pausa o che deve attendere (azione consigliata se si prevede un’attesa superiore ai 5 secondi).
Rispetto all’utilizzo dei marcatori di dialogo, si sottolinea in generale l’importanza di non ripetere due volte lo stesso marcatore nella stessa riga, per evitare di ottenere un effetto robotico, e di prestare una particolare attenzione ai “conflitti” tra possibili errori e marcatori . Un posizionamento dei marcatori che non tenga conto del possibile conflitto con gli errori potrebbe infatti peggiorare il risultato finale.
Il libro prosegue poi con un’interessante sezione dedicata ai marcatori di dialogo non verbali (classificati come beep, blip, chime, earcon, loghi audio e musica), che si rivelano particolarmente utili in alcune situazioni, quali l’apertura di un’applicazione (anche allo scopo di identificare il brand), la segnalazione del passaggio all’utente del turno di conversazione, del fatto che il sistema è momentaneamente occupato e l’utente deve attendere, o che si sta attendendo una risposta da parte dell’utente.
Ci si può inoltre servire utilmente dei marcatori non verbali dopo un mancato input, per segnalare che il sistema non ha recepito correttamente l’input atteso dall’utente, quando si preannuncia il fatto che sarà presentata una lista, quando si annuncia l’ingresso in una nuova sezione o quando si annuncia la presentazione di un aiuto.
Così come per gli strumenti verbali, anche nel caso della comunicazione non verbale è fondamentale la coerenza nel corso dell’interazione, rappresentata dal fatto che l’audio deve essere utilizzato durante tutto il dialogo e non solo a tratti ed il suo utilizzo deve essere “omogeneo” (se si usa una earcon quando si aspetta la risposta dell’utente, ad esempio, è necessario farlo sempre e usare lo stesso audio per le stesse situazioni).
Ahmed Bouzid e Weiye Ma ci ricordano poi che nell’ambito delle interazioni vocali un ulteriore strumento da utilizzare con attenzione e sapienza è…il silenzio!
L’utilizzo del silenzio è in grado di migliorare l’usabilità della VUI, ad esempio, prima di una lista di opzioni, tra un’opzione e l’altra all’interno della stessa lista, tra categorie diverse di opzioni, nell’interazione con utenti esperti (come conferma del fatto che l’input è stato recepito correttamente e per dare modo di correggere eventualmente l’input, se errato) e prima e dopo l’inserimento (se non se ne può fare a meno) di TTS prompt, per diminuire l’effetto sgradevole ed agevolare la comprensione.
I tre principi di base che è fondamentale non trascurare nella progettazione di interazioni vocali, proseguono gli autori, sono dati da:
- il rispetto verso l’utente (rappresentato dal fatto di rispettare il suo tempo, la sua libertà, non ingannarlo, non terminare un’azione unilateralmente, informarlo circa il processo in atto e non modificare senza informarlo le modalità di interazione)
- la realizzazione di un’interfaccia il più possibile “intelligente”, che sia in grado di attuare un coinvolgimento intelligente dell’utente (tenendo conto delle sue preferenze, del suo livello di esperienza, anticipando le sue domande e tenendo conto in generale dei picchi di richiesta)
- la coerenza nella modalità di interazione (rappresentata dal fatto di non manifestare un comportamento “irrazionale” ed incoerente, nel linguaggio utilizzato, nella voce — è preferibile sotto questo profilo non mescolare troppe voci — e nella modalità di interazione, è importante cioè non dare e poi togliere un’opportunità di interazione all’utente senza informarlo)
La progettazione di una VUI richiede la comprensione dei bisogni e degli intenti degli utenti, che devono essere profilati rispetto all’età, alle capacità tecniche e all’esperienza, allo stato emotivo ed al tipo di opportunità ricercata.
E’ necessario poi identificare le richieste più probabili da parte degli utenti ed pattern “tipici” di utilizzo del sistema, in modo da anticipare le richieste dell’utente, tenendo conto anche delle dipendenze tra diverse richieste.
Gli autori affrontano poi il fondamentale tema della “persona” associata alla VUI. E’ essenziale infatti definire la personalità (persona) della VUI, perché l’utente è portato ad associare istintivamente una personalità alla voce e perché la definizione di una personalità permette di migliorare la usability della VUI, in quanto ha una ricaduta positiva in termini di “consistenza” della voce e dello stile utilizzato.
L’obiettivo del designer è quello di costruire una “persona” (tra gli elementi principali da considerare vi sono il genere e l’età) che con la sua voce e la sua personalità corrisponda il più possibile all’identità dell’azienda e all’obiettivo dell’interazione.
Nell’ultima parte del testo vengono infine ripercorse le fasi di attività legate alla progettazione ed al rilascio di un’applicazione ad interfaccia vocale.
In merito alle attività legate al deployment, nella fase di pre-design sarà necessario definire gli obiettivi di business e analizzare le interazioni reali (live o registrate) con l’applicazione. Su questa base sarà possibile definire il dettaglio delle specifiche.
Nella fase di design, saranno progettati il flusso di interazione e di dialogo, sarà definita la persona e saranno sviluppate le specifiche di backend. In questa fase si consiglia anche di realizzare un test nel quale interagiscono due persone, una delle quali impersona il sistema e l’altra l’utente.
Nella fase di sviluppo si procederà con la registrazione delle espressioni (prompt), la “scrittura della grammatica” (codifica di quanto può rispondere l’utente e che deve essere compreso dal sistema), le integrazioni backend, lo sviluppo dell’applicazione vocale e l’inserimento di strumenti per le annotazioni ed il monitoraggio delle interazioni.
Nella fase di test dell’applicazione, sarà necessario effettuare il “tuning” del riconoscimento. E’ infatti necessario accertarsi del fatto che il sistema “accetti” il livello “giusto” di linguaggio — né troppo né troppo poco — che siano compresi i punti “di chiusura” delle affermazioni, che sia definita una soglia di “accettabilità” (comprensione) delle risposte e che sia definita la “resilienza” che può tollerare il sistema rispetto ai rumori di fondo presenti nelle espressioni dell’utente.
Devono poi essere eseguiti un test funzionale, che attesti che il sistema funziona come ci si aspetta, un test che provi quanti più possibili path (anche automatizzato), un test di usabilità ed uno di stress, realizzato mediante l’interazione di un gran numero di utenti con l’applicazione.
Una volta che l’applicazione viene effettivamente e formalmente lanciata, è importante tenere traccia e analizzare le interazioni reali con gli utenti e fare delle annotazioni. Sulla base di un’analisi dei problemi più frequenti, la raccomandazione è quella di fare una revisione dell’applicazione con cadenza mensile nel primo periodo e poi trimestrale.
Il tuning dell’applicazione nel tempo dovrà essere basato su un’analisi delle annotazioni, che mettono in evidenza i comportamenti e problemi tipici che si verificano nel corso di un’interazione, sull’analisi delle registrazioni e sulla valutazione diretta da parte degli utenti.
I principali punti da esplorare nella fase di tuning dell’applicazione vocale sono relativi ai motivi per cui le persone abbandonano la conversazione o vengono dirottate su un agente umano, fanno affermazioni “sbagliate” (rispetto a quello che si aspetta il sistema), non dicono nulla o parlano troppo presto.
E’ necessario poi capire qual è il livello medio di rumore in cui interagiscono gli utenti, quali sono le motivazioni tipiche che li spingono ad utilizzare l’applicazione ed in generale quali sono le loro sensazioni nell’utilizzo dell’applicazione, dato che può essere desunto anche sulla base del loro tono di voce nel corso dell’interazione (rispetto a questo obiettivo si possono utilizzare anche tecnologie ad hoc per analizzare grandi moli di registrazioni e relativo sentiment).
Con lo sviluppo delle interfacce vocali si aggiungeranno forse nel tempo nuove linee guida a quelle riportate in “Don’t Make Me Tap!”, testo che ho trovato molto chiaro e utile per chi si affaccia a questo settore.
E nel tempo forse anche l’espressione umana, pur continuando ad evolvere attraverso lo scambio tra esseri umani, sarà condizionata più di quanto non avviene oggi dalle capacità e dalle modalità di comprensione delle macchine.