Come trovare e ottenere il massimo dal percorso dell'utente non pianificato

I fallback possono essere definiti come un piano alternativo che può essere utilizzato e, nel contesto dei percorsi degli utenti, rappresenterebbero un percorso alternativo al comportamento previsto o pianificato dell'utente. Quindi, quando pensiamo ai nostri siti e app, li costruiamo con un piano particolare in mente per raggiungere un obiettivo particolare seguendo un percorso particolare e vivere un'esperienza particolare.

Se hai esperienza nella creazione di prodotti, saprai che gli utenti hanno la tendenza a fare cose per cui non hai pianificato, e va bene perché non possiamo assolutamente capire tutte le loro esigenze e intenzioni. Questo è il motivo per cui i fallback sono così preziosi.

Nel corso degli anni, abbiamo provato e testato molti strumenti in Venture Harbor per aiutarci a ottenere cicli di feedback migliori. I nostri prodotti hanno esigenze che richiedono diversi tipi di strumenti per rivelare tutti i tipi di intuizioni. Dalle mappe di calore e dagli strumenti di registrazione dei visitatori (come Hotjar e Fullstory) alle piattaforme di analisi come Google Analytics e Amplitude.

Questi strumenti sono fantastici e ci aiutano a realizzare molto, ma vanno solo così lontano. Ora abbiamo bisogno di ottenere informazioni più approfondite che possono essere ottenute solo implementando fallback nei percorsi degli utenti .

Per iniziare, dobbiamo pensare a quali comportamenti o percorsi alternativi potrebbero sperimentare i nostri utenti che non vedevamo arrivare. Ecco tre comuni fallback:

• Vicoli ciechi
  Il viaggio dell'utente è giunto al termine e non ci sono passaggi chiari o successivi. L'obiettivo sarebbe quello di offrire i passaggi successivi all'utente e tenere traccia di tali scelte.
• Aree grigie
  L'utente sta interagendo con il tuo sito o con la tua app, ma abbiamo poca o nessuna comprensione di cosa sta succedendo o perché stanno facendo quello che stanno facendo. L'obiettivo è fare luce su quelle aree per conoscere cosa potrebbe accadere.
• Errori
  All'utente viene presentato un messaggio di errore che fornisce un contesto insufficiente. L'obiettivo qui è offrire contesto interagendo con l'utente per ottenere feedback da loro.

Immergiamoci in alcuni esempi naturali in cui i circuiti di feedback mancano nei popolari fallback. Quindi, seguirò le idee su come potrebbe apparire e funzionare quel ciclo di feedback in quei fallback.

Nota : solo perché tu lo sappia, questi sono modelli basati su scenari del mondo reale.

Trasformare i vicoli ciechi in miniere d'oro di feedback

I vicoli ciechi in un flusso utente sono comuni. Un modo per scoprirli è analizzare le tue pagine di uscita nel tuo strumento di monitoraggio delle analisi, come Google Analytics. Ciò evidenzierà le pagine di uscita comuni sul tuo sito o sulla tua app e ti darà un punto di partenza per iniziare a indagare.

Ora dobbiamo porci la semplice domanda:

"Perché gli utenti se ne vanno a questi punti?"

Dai un'occhiata alle pagine effettive su cui si verificano queste uscite e inizia a considerare a che punto del processo di utilizzo della tua app o del tuo sito si trova l'utente quando ha raggiunto questo vicolo cieco. Stanno appena iniziando, sono a metà o sono vicini al raggiungimento di un obiettivo particolare nel viaggio? Queste considerazioni ti aiuteranno a tracciare un quadro migliore della situazione dell'utente e delle possibili ragioni.

Esempio: vicoli ciechi nella ricerca

Un vicolo cieco molto comune è con la ricerca quando stai cercando qualcosa e ti viene mostrata la pagina "Nessun risultato". Le aziende stanno iniziando a investire davvero in queste pagine e scoprirai che normalmente ti verrà mostrato una sorta di risultato, specialmente sui siti di e-commerce.

Quando cerchiamo qualcosa, dovremmo almeno restituire una sorta di risultato. Quando non abbiamo un risultato reale da mostrare, allora dobbiamo pensare in modo creativo a come capitalizzare questi scenari. Questo può assumere la forma di una domanda o di un'azione comune che potrebbe essere stata l'intenzione della ricerca dell'utente in primo luogo.

Di seguito è riportato un esempio di una ricerca senza uscita:

In questo caso, cosa possiamo scoprire dall'utente che non sappiamo già per aiutarci a migliorare la sua esperienza e aiutarci a imparare? Quali domande potremmo porre loro? Cosa potremmo fornire all'utente a questo punto, ora che non ha trovato quello che cerca?

Questo particolare scenario è interessante e ho pensato a un paio di idee su come ottenere informazioni dall'utente per aiutarci a migliorare la nostra app e fornire loro il passaggio successivo.

Come mostrato di seguito, iniziamo dicendo all'utente che ciò che sta cercando non è disponibile ora, ma potrebbe esserlo in futuro. In cambio, possiamo ottenere un feedback su ciò che speravano di fare o trovare invece:

Potremmo quindi fornire all'utente un passaggio successivo offrendo loro un filtro che lo aiuterà a trovare un'alternativa e successivamente ci informerà su quale categoria di estensione stavano cercando, che potremmo quindi rivedere e capire quali categorie dovremmo investire tempo dopo. Con queste informazioni raccolte dall'utente, possiamo iniziare a costruire una base di conoscenza di ciò che gli utenti potrebbero aspettarsi in questi scenari e iniziare a suggerire categorie e suggerimenti più intelligenti all'utente finale in futuro. In questo modo, possiamo fornire loro un'esperienza utente molto migliore.

Esempio: vicoli ciechi naturali

I vicoli ciechi possono anche verificarsi come un ordine naturale del tuo sito o app. Potrebbero verificarsi scenari in cui gli utenti incontrano una pagina priva di contenuto e nessun passaggio successivo a causa del fatto che il sistema non ha avuto il tempo di elaborare i dati. O forse i dati non sono stati ancora creati, come illustrato di seguito:

Quindi ora quello che vogliamo fare è assicurarci di due cose:

1. L'utente dovrebbe capire perché e cosa sta succedendo;
2. Coinvolgi l'utente mentre attende i dati.

Di seguito è riportato un amichevole, prezioso e utile ripiego sia per l'utente che per noi stessi. All'utente vengono offerte notifiche da inviare al proprio indirizzo e-mail, insieme a un mese di abbonamento gratuito! In cambio, informiamo gli utenti quando tornare all'app: utenti felici con un mese gratuito e dati extra sugli utenti stessi. È sempre meglio quando vincono tutti!

Con il tempo, possiamo iniziare a capire se la maggior parte degli utenti desidera o meno avere determinate funzionalità e se preferisce iniziare ad accenderle di default o rimuoverle completamente. Inoltre, le informazioni provenienti dai sondaggi possono aiutare ad accrescere la nostra comprensione delle aspettative degli utenti sull'app e aiutarci a modellarla per adattarla alle esigenze degli utenti.

Letture consigliate : Come migliorare il tuo processo di progettazione con le persone basate sui dati

Converti le aree grigie in approfondimenti

Quello che intendo per "aree grigie" sono aree che mancano di comprensione e chiarezza su ciò che gli utenti potrebbero fare o sul motivo per cui gli utenti stanno prendendo decisioni particolari. Normalmente si tratta di aree che non hanno una priorità elevata per il sito/l'app, ma fanno parte del percorso dell'utente chiave. Più dati abbiamo durante il percorso dell'utente, meglio possiamo capire cosa, perché e come delle azioni degli utenti.

Esempio: capire il tuo "altro"

È pratica abbastanza comune etichettare qualcosa come "altro" quando non c'è un adattamento chiaro. Di seguito è riportato un esempio di questo tipo di interfaccia utente e, mentre analizziamo questo scenario, è chiaro che l'unica intuizione che abbiamo è che sappiamo che l'utente lo sta etichettando come un tipo "altro" e questo ci lascia con poca comprensione di ciò che è o di ciò che volevano che fosse.

Naturalmente, potremmo indagare un po' di più su ciò che viene etichettato come "altro" e trovare alcune linee comuni, ma non sapremmo cosa l'utente potrebbe aver inteso etichettandolo così.

Quindi, come possiamo cambiare questo scenario dall'essere solo un'altra risposta "altra" a qualcosa che è informativo e utile sia per l'utente che per noi? Un approccio che suggerirei è un po' più complesso ma renderà l'esperienza molto più coinvolgente.

Vogliamo consentire agli utenti di scegliere la loro opzione facendo clic sull'opzione che sanno di volere o cercando ciò che pensano di cercare. Perché è utile? Ebbene, quando si tratta di opzioni di denominazione, potremmo nominarle in un modo abbastanza diverso rispetto a come l'utente potrebbe avere in mente . Ma se non siamo ancora in grado di offrire all'utente una risposta che sta cercando, allora dovremmo iniziare una conversazione con loro mostrando loro una domanda e una casella di testo e chiedere loro cosa stanno cercando e perché. (Forse aggiungeremo anche una linea che seguiremo con loro e troveremo una soluzione alle loro esigenze.)

Man mano che iniziamo a trovare fili comuni nelle ricerche e nelle risposte che otteniamo, possiamo iniziare a modificare la ricerca in modo da offrire all'utente l'opzione più probabile e possiamo anche creare nuove funzionalità man mano che la domanda aumenta.

Esempio: Capire la tua ricerca istantanea

Un'altra area grigia di seguito è un esempio di me stesso che utilizza una ricerca istantanea mentre cerco alcune parole chiave che non sono associate a nulla che ho nel mio account.

Da questa esperienza mi sono posto le seguenti domande:

• Qual è il vantaggio di questo scenario?
• Posso scoprire quanto è comune questo scenario?
• Cosa sta cercando di ottenere l'utente?
• Come possiamo aiutarli ad arrivare dove vogliono?

Di seguito è riportata la finestra dei risultati "Nessun risultato" con un ciclo di feedback per aiutarci a conoscere le esigenze degli utenti. I risultati della ricerca sono popolati in un modo che può fornire informazioni dettagliate sulle esigenze degli utenti e fornirci almeno un po' di chiarezza su ciò che esattamente stanno cercando con l'opzione "Cerca in".

Alcuni modi per coinvolgere i tuoi utenti sarebbero:

• Offri azioni comuni sul tuo sito o app per consentire all'utente di creare il contenuto che sta cercando;
• Fornisci loro la possibilità di ricevere una notifica una volta che la cosa che stavano cercando diventa disponibile (questo è un bel modo per riportare l'utente in una fase successiva);
• Consenti loro di fornire un feedback diretto perché a volte parlare con qualcuno risolverà tutto (e una conversazione è la migliore fonte di feedback).

Possiamo imparare e diventare più intelligenti con i risultati che otteniamo da questo ciclo di feedback, a condizione che iniziamo a fornire suggerimenti per categorie più intelligenti ai nostri utenti . Nel tempo, è possibile apprendere abitudini personalizzate per i singoli utenti e possiamo iniziare a suggerire opzioni che hanno maggiori probabilità di risuonare con quell'utente a causa delle sue azioni e ricerche passate.

Rendi i tuoi messaggi di errore un punto di forza

Che scegliamo di accettarlo o meno, gli errori accadono. Quando si verificano, dovremmo conoscerli, ma a volte possiamo provvedere agli errori in modo generico che non aiuta né noi né l'utente.

Un esempio di ciò è quando l'utente potrebbe interagire con il tuo sito o app in cui sta salvando una sorta di dati sul tuo sistema, ma per qualche motivo la connessione viene persa e il processo non riesce. C'è poco per diagnosticare cosa sta succedendo o cosa è successo, ma sappiamo che si è verificato un errore. La procedura standard è informare l'utente che si è verificato un errore ed eventualmente riprovare.

Quando sappiamo poco del problema da parte nostra, o che potrebbe essere stato causato da una manciata di cose, allora questa è una grande opportunità per ottenere un feedback dall'utente su cosa sta succedendo. Penso che questo sia il fallback più semplice da implementare, ma quello che vedo meno.

Uno scenario tipico sarebbe quando qualcosa viene salvato automaticamente mentre si utilizza il sito o l'app. Questo è uno scenario in crescita soprattutto con le connessioni mobili; capire che il tuo sito è utilizzato da utenti in movimento o su una connessione mobile è un'ottima intuizione e dovremmo cercare di raccogliere tali informazioni il più possibile.

Oppure potresti renderlo ancora più semplice per l'utente. Se hai già un'idea di quale potrebbe essere il problema e vorresti avere un'idea migliore di quanto spesso è successo all'utente, allora offri loro delle opzioni ma consenti loro comunque di dirti cosa hanno sperimentato. Una volta che hai queste informazioni, puoi quindi iniziare a investire il tuo tempo in possibili nuove funzionalità per aiutare a risolvere quei problemi dati e, si spera, ritrovarti a non dover mostrare affatto un messaggio di errore.

Qualcosa di importante da ricordare è che un fallback non deve essere una caratteristica permanente, ma può essere temporaneo per aiutarti a capire cosa chiedere o cosa costruire dopo. Richiede un po' di investimento e tempo per raccogliere i dati, ma questi possono essere visti come test in esecuzione in aree del tuo percorso utente che non hai mai esaminato prima e aggiungeranno solo alla comprensione dei tuoi utenti e delle loro esigenze.

Detto questo, i fallback in un mondo ideale non sarebbero mai esistiti. Se stai lavorando a un progetto nuovo di zecca o rielaborando il tuo flusso utente, poniti la sfida di creare un flusso in cui un utente non incontrerebbe mai scenari come questi. Considera come impedire a un utente di cercare qualcosa che non esiste. Tieni traccia e analizza tutte le aree del tuo percorso utente per comprendere ogni loro passaggio e formulare modi in cui un messaggio di errore non verrebbe mai mostrato.

Letture consigliate : Test A/B per esperienze Mobile-First

Dove ti stanno costando i fallback?

I fallback avranno un aspetto diverso a seconda del tuo prodotto, poiché porrai domande diverse e offrirai opzioni diverse, ma svolgeranno tutti un ruolo prezioso nell'esporre te stesso e gli utenti a opzioni e comprensione migliori.

Cosa succede dopo?

Perché non dedicare alcune ore a esaminare i percorsi degli utenti e documentare dove si trovano le aree grigie, oltre a cercare vicoli ciechi e messaggi di errore che (ancora) esistono nel tuo prodotto.

Ecco alcune guide per iniziare:

• Vicoli ciechi
  Inizia a esplorare le tue analisi e, se non lo sei già, mettiti comodo. Le pagine di uscita sono normalmente tracciate per impostazione predefinita e ti forniranno ottime informazioni sulla fase in cui i tuoi utenti stanno lasciando il sito. Pensa a dove saranno i tuoi utenti nel loro viaggio e considera il tipo di esigenze che potrebbero avere in quei momenti.
• Aree grigie
  Se non l'hai già fatto, traccia il percorso dell'utente e inizia a evidenziare le aree su cui potresti avere domande. Considera i punti in cui i tuoi utenti prendono decisioni e pensa alle opzioni che stai offrendo loro. Ricorda l'opzione "Altro" e pensa a dove potrebbero esserci delle opzioni piuttosto generiche. Inizia a monitorare queste opzioni per vedere con quale frequenza vengono scelte, quindi inizia a esplorare i modi per ottenere feedback dagli utenti su ciò che desiderano.
• Errori
  Puoi capire rapidamente dove potrebbe essere visualizzato un errore sulla tua app. Con un sito/app che salva, aggiorna e funziona in tempo reale, gli errori possono essere una parte fondamentale del tuo sistema. Inizia scoprendo quale area è più utilizzata, il che potrebbe comportare dove gli errori sono più frequenti. Investi nei messaggi di errore presenti e inizia a raccogliere feedback sul motivo per cui vengono visualizzati, sia dal tuo sistema che dall'utente. Consiglierei anche di creare un messaggio di errore predefinito con un ciclo di feedback che verrebbe utilizzato nel sito per qualsiasi nuova funzionalità in modo da iniziare a imparare da quegli errori dal primo giorno.

Buona costruzione di riserva!