Non mi serve aiuto

Ammettiamolo: non abbiamo scuse. La UX può vantarsi di essere intuitiva e carina, ma facciamo davvero schifo nell’aiutare le persone, che poi è la cosa che maggiormente definisce e incarna una grande user experience.

Nel corso dei secoli, abbiamo assistito a un tema ricorrente: alla gente serve aiuto. Per quel se ne sa, il bisogno di assistenza potrebbe aver dato il via allo sviluppo delle comunicazioni. Potrebbe aver portato alla formazione di legami tra le tribù e alla nostra esistenza attuale. Nel futuro, potrebbe essere l’unica cosa che eviterà l’estinzione umana e promuoverà l’evoluzione della società.

Ma se è così, una domanda sorge spontanea: perché troviamo così difficile chiedere aiuto o offrire una guida gli uni a gli altri? Preferiamo capire come funzionano le cose da soli? Siamo spaventati che ogni richiesta di aiuto comporterà degli obblighi a restituire il favore? Siamo preoccupati di essere respinti? O che potremmo non ottenere l’aiuto che ci serve?

Alla gente serve aiuto. È un dato di fato e un problema nel settore della UX. Dichiariamo di fare così tanto per gli utenti ma trattiamo l’aiuto come un’ultima considerazione, non come primaria quale dovrebbe essere. Perché agiamo così?

Uno sguardo alla maggior parte dei siti web, inclusi quelli di grandi e piccole organizzazioni, suggerisce che l’assistenza utente è trattata come un’opzione superficiale: spesso relegata al simbolo di un punto di domanda messo in un angolo. Le assunzioni sono:

• gli utenti non avranno bisogno d’aiuto: il design è intuitivo;
• se gli utenti vogliono aiuto, lo cercheranno (da qualche parte);
• una volta che gli utenti capiscono dove cercare, chiederanno aiuto quando l’avranno bisogno.

Se gli stessi scenari venissero riportati nelle interazioni del mondo reale, sarebbe simile a visitare un grande museo, con mappe, tour, guide e orari del programma nascosti in un armadietto da qualche parte lontano dall’ingresso principale.

Perché offrire aiuto prima che venga chiesto?#section1

Togliere le supposizioni dall’esperienza del cliente fa bene a tutte le persone coinvolte.

Prendiamo ad esempio il caso in cui si stia entrando in una tavola calda. Inizialmente, potreste chiedervi se tutto sia self-service e se alla fine dovrete sgomberare il vostro tavolo da soli. Potreste semplicemente osservare le persone nel locale e comportarvi come fanno gli altri avventori. Oppure, il titolare potrebbe aiutarvi per capire subito. Ikea risolve il problema “cosa devo fare” con un cartello “Perché devo sgomberare io il mio tavolo?” proprio al centro del suo popolare ristorante all’interno degli store. Il cartello risolve due problemi: dà immediatamente le informazioni necessarie al cliente e promuove l’obiettivo di Ikea di ridurre i costi.

I designer creano le user interface con una pianificazione attenta, pertanto giungono alla popolare conclusione che se un design è stato un successo non richiede spiegazioni, non serve alcun cartello bene in vista.

Ma spesso si cerca o si ha bisogno di aiuto per una serie di ragioni. L’aiuto può essere richiesto per spiegare alcuni campi in una form, per definire il significato di un’icona specifica, per analizzare termini altamente tecnici, per identificare nuove feature, per dare delucidazioni su gesture nascoste o per dettagliare politiche ottuse.

Un utente potrebbe capire immediatamente che un’icona di una matita apre un pop-up per l’editing. Se non ci arriva, potrebbe alla fine scoprirlo, ma solo dopo aver perso tempo in uno stato confusionale.

Non importa quanto sia smart un design: a meno che non sia personalizzato sulla personalità, sui bisogni, sulle condizioni di lavoro, sul device, sulla conoscenza dello specifico dominio, sull’esperienza tecnica e sull’umore di ciascun utente, saranno necessarie delle spiegazioni. Un buon designer empatizza con le preoccupazioni uniche e prende gli utenti così come sono, dai navigati esperti dell’online a quelli che ci vanno di tanto in tanto. Un buon design include l’assistenza all’utente a cui viene data la dovuta considerazione.

Quando l’aiuto va a finire male#section2

A volte i siti web fanno degli attenti tentativi di aiuto e a volte questi tentativi sanno di eccesso.

Ci sono dei video tour creati con perizia che guidano gli utenti attraverso ciascuna feature del prodotto. Ci sono degli slideshow con dei font personalizzati e dei caratteri vivaci che sottolineano tutte le cose nuove e promettenti nella nuova release. Ci sono degli overlay semi-trasparenti di puntatori intelligenti per indicare dove si trovano i comandi di azione utili.

Statistiche e studi mostrano che quando viene presentato uno qualsiasi degli elementi di cui sopra al lancio di un’applicazione, l’utente:

1. o vi scorre attraverso rapidamente senza alcun interesse nel suo contenuto
2. o lo chiude.

Il problema principale del fornire assistenza a livello di informazioni come prima schermata è che agli utenti non interessa ancora. Non hanno visto abbastanza del prodotto da voler imparare di più sulla sua complessità.

Gli utenti vogliono arrivare il prima possibile al prodotto: hanno già letto il materiale di marketing, sono passati attraverso il processo di registrazione, magari hanno addirittura letto i “Termini e condizioni”. Non vogliono che altre cose prolunghino l’attesa. Se li si obbliga a leggere il contenuto preliminare o a vedere tutti i tour, lo faranno senza esserne interessati e, quindi, si dimenticheranno subito di quello che hanno imparato.

Alcune applicazioni hanno dei manuali di aiuto della lunghezza di un libro. Ci vuole moltissimo ragionamento e lavoro per scrivere e creare questi documenti, ma questi esistono in un mondo separato, lontano dall’applicazione stessa, e si aspettano che l’utente si allontani dal task che sta facendo per leggere e imparare. Spesso sono progettati male, rendendo il processo di ricerca dell’informazione nel sito web di “aiuto” una rogna.

Si può far entrare l’aiuto clandestinamente?#section3

L’aiuto invasivo, che tiene per mano, non è visto di buon occhio nel mondo del design così come la mancanza di intuito. Esempi di ciò includono: l’apertura forzata di un overlay con offerte di aiuto mentre l’utente è impegnato in un task, il caricamento di schermate piene di descrizioni prodotto senza contesto o il lancio del tour di un prodotto che deve essere completato prima che l’utente possa accedere al prodotto. Qui entra in gioco la necessità di capire gli obiettivi dell’applicazione.

Si tratta di un’applicazione enterprise con storage cloud-base, con più connessioni al server e con trasferimento di dati sensibili? In questo caso, l’aiuto dovrebbe diventare una priorità visibile. Cosa succede se un’app è costruita con un solido approccio gamification? In quel caso, l’aiuto può probabilmente assumere un ruolo passivo di secondo piano.

Prendete in considerazione i pattern di user behaviour mentre progettate la funzione aiuto. Alcuni utenti preferiscono l’esperienza di lettura non interrotta: a loro piace immergersi completamente nell’oggetto in questione, leggere tutte le istruzioni e magari anche scaricare il contenuto per la lettura offline e fanno affidamento su descrizioni dettagliate dell’argomento. Dall’altro lato dello spettro, alcuni utenti preferiscono dare una rapida lettura al testo: cercheranno aiuto solo dopo aver fatto un errore e raramente andranno su un sito di aiuto dedicato al di fuori del contesto. Per loro funzioneranno meglio dei piccoli pezzi di supporto all’interno dell’applicazione.

Le istruzioni offerte in maniera non intrusiva possono migliorare un’esperienza, che sia reale o virtuale. Fare un’escursione su un sentiero con delle chiare indicazioni del percorso, delle indicazioni sulla distanza, precauzioni riguardanti la fauna e descrizioni di piante e arbusti risulta sicuro e informativo e pertanto di aiuto. Il tag “x minute read” nei post di Medium, il messenger Slackbot in Slack e il delineamento di semplici passi nel Google Apps Learning Center sono tutti esempi di aiuto offerto agli utenti senza distrazioni rumorose.

Come aiutare#section4

Essere semplicemente sicuri che la vostra funzione di assistenza utenti sia visibile può già essere sufficiente per dare una sensazione di agio. Nello stesso modo in cui una buona interfaccia non fa pensare troppo gli utenti, una buona funzione di aiuto dovrebbe essere semplice da trovare e accedervi.

Si può progettare l’aiuto affinché sia contestuale o stand-alone (un mix dei due è la miglior soluzione).

L’aiuto contestuale può assumere una qualsiasi forma di assistenza utente che sia incorporata all’interno delle schermate del prodotto. Previene l’interruzione del focus immediato dell’utente. È concisa e rapida da leggere e accedervi. È disponibile quando l’utente la richiede o, ancora meglio, quando se l’aspetta.

Alcuni esempi:

• Tooltip che appaiono all’hover indicando il nome di un’icona o di un pulsante.
• Info-tip che si aprono dopo aver cliccato una “i” o un “?” vicino a una form o a un campo o a una qualsiasi parte dell’UI che debba essere spiegata. Dovrebbe trattarsi di breve contenuto che spieghi lo scopo o il significato dell’elemento rilevante.
• Testo fantasma che appare all’interno di un campo di testo o vicino all’elemento UI per aiutare gli utenti a capire l’elemento.
• Un pannello che funziona come un overlay all’interno della schermata del prodotto, che fornisce agli utenti delle informazioni di aiuto più dettagliate.
• Delle rapide guide “Getting Started” che si fondono con l’interfaccia e portano gli utenti attraverso il flusso delle azioni.
• Tooltip che indicano degli aggiornamenti di feature all’interno dell’UI.
• Testo di suggerimento che dimostra i protocolli di ricerca, come ad esempio le parole chiave suggerite che funzionano davvero nell’applicazione.

L’aiuto stand-alone può richiedere un approccio più dettagliato.

Solitamente, progettare l’help center per un’applicazione è una sfida. L’architettura dell’informazione dovrebbe accordarsi all’architettura dell’applicazione? In che modo gli utenti affronteranno il contenuto? Vorranno che ogni azione e ogni elemento dell’interfaccia siano documentati? In questo caso, come dovrebbe essere strutturato il contenuto per una semplice lettura? Se non lo fanno, in che modo gli autori daranno priorità agli argomenti? Quando troppo è troppo?

Un funzionalità di ricerca efficace può far sì che gli utenti non si perdano nel contenuto: una search box evidente rende semplice localizzare l’argomento giusto prima che l’utente si senta sopraffatto. E se l’opzione di ricerca dell’applicazione è internet friendly, attirerà ancora di più quegli utenti che preferiscono usare un search engine “reale” (come Google o Bing).

La documentazione categorizzata per feature o task permette agli utenti di filtrare più rapidamente. È inoltre importante identificare quali informazioni garantiscono una maggior visibilità: aiutare gli utenti a risolvere i loro problemi più pressanti e in maniera rapida. Il customer feedback, le statistiche e la user research possono aiutare a determinare quali argomenti cercano di più i vostri utenti.

Il mito della capacità tecnica#section5

Le applicazioni enterprise così come le applicazioni consumer possono trarre beneficio da un sistema di aiuto ben congegnato. È una pessima logica dire che un’interfaccia è progettata per utenti con “buone capacità tecniche” che pertanto non avranno bisogno di aiuto.

Una funzione di aiuto ben progettata è più di un insieme di istruzioni durante un’emergenza. È premurosa, cordiale e attenta. Sa che nessuna richiesta di aiuto è insignificante e nessuna spiegazione necessaria è troppo lunga. È ora di estirpare le precedenti funzioni di aiuto scomode o “appena presenti”. È ora di rendere utile l’aiuto.

Dopo tutto, aver bisogno di aiuto fa parte della condizione umana.