Un valido aiuto è difficile da trovare

Best practices#section1

Il contenuto dell’help efficace è una sfida più grande di quello che potremmo pensare. Sviluppare una strategia significa andare oltre la scrittura di semplici istruzioni per portare a termine un task.

Tono#section2

Per prima cosa, dobbiamo capire che chiunque stia leggendo il contenuto dell’help è già frustrato. Il nostro obiettivo è quello di ridurre quei sentimenti negativi. Il tono deve essere sensibile, non arrogante. Non dovete mai biasimare un cliente per i problemi. Considerate lo scenario seguente: un’applicazione web richiede che gli utenti clicchino su un link di conferma in un’email prima di permettergli di effettuare il login, ma l’e-mail non arriva mai a destinazione nella inbox dell’utente. Immaginate di leggere il seguente messaggio d’aiuto riguardante questo problema:

Se non avete ricevuto un’email di conferma, controllate il vostro filtro spam. Il vostro programma di email potrebbe aver identificato in maniera errata il messaggio di conferma come spam. Se non riuscite ancora a trovarlo, fate riferimento all’argomento “Non avete ricevuto un’e-mail prevista.”

Questo linguaggio, leggermente modificato rispetto ai messaggi di aiuto del mondo reale, potrebbe anche essere peggio, ma notate come le possibili spiegazioni assumano ci sia una colpa da parte dell’utente: “il vostro programma per le email” e “se voi non siete ancora riusciti a trovarla” Il tono di questo testo è sulla difensiva. Il problema potrebbe effettivamente essersi generato a lato utente, ma affermando ciò non li si fa sentire meglio. Considerate questa alternativa:

Se non l’avete ancora fatto, controllate che il nostro messaggio non sia finito nella cartelletta di spam. Se non si trova lì, chiamateci e saremo felici di aiutarvi ad attivare il vostro account.

Questo messaggio è molto più conciliante. Implica che è responsabilità dell’applicazione web far giungere un’email all’utente, non che sia responsabilità dell’utente trovarla. Inoltre, lascia anche aperta la possibilità che l’utente sia sufficientemente saggio da aver già controllato la cartelletta di spam. Infine, offre un modo per risolvere il problema immediatamente, non solo un link ad un’altra pagina.

Quando gli sviluppatori scrivono da soli il contenuto dell’help (o anche il testo dei messaggi d’errore), è facile avere un tono accondiscendente perché siamo molto vicini all’argomento in questione. Se fosse possibile, il contenuto dell’help dovrebbe essere scritto da una persona che abbia familiarità con l’uso di un’applicazione o di un sito web, ma che non sia necessariamente intimo con il suo funzionamento interno.

Brevità#section3

Il contenuto dell’help non esiste per sé stesso: fornisce supporto a qualcuno che ha provato ma non è stato in grado di compiere un task. Le persone seguono il percorso che offre minor resistenza al raggiungimento di un obiettivo e, se le istruzioni del task richiedono troppo tempo per essere processate, probabilmente abbandoneranno la ricerca. Il contenuto dell’help dovrebbe essere breve e contenere solo il numero sufficiente di dettagli per affrontare il problema e riportare l’utente al task.

Cura#section4

Il contenuto del help fa riferimento alla forma e alla funzione dell’applicazione sottostante. Questa dipendenza potrebbe non apparire ovvia agli sviluppatori, che concentrano i loro sforzi sull’applicazione stessa. Designate qualcuno ad assumersi la responsabilità di valutare i cambiamenti per determinare se influenzano il contenuto della sezione di aiuto. Ad esempio, un semplice cambiamento nell’interfaccia dell’applicazione ha conseguenze di vasta portata se il contenuto della sezione help contiene degli screenshot dell’applicazione. Se un link prima era chiamato “Torna agli elenchi” ora si chiama “Cancella” dovrete aggiornare dozzine di riferimenti. Una volta che il contenuto del help non è più sincronizzato con il sito web o con l’applicazione a cui fa riferimento, decisamente non è più di nessun aiuto. La content strategy di un sito web— o il workflow di mantenimento di un’applicazione— devono includere delle procedure per rivedere ed aggiornare il contenuto del help man mano che cambia il materiale sorgente.

Aiuto integrato#section5

Il contenuto d’aiuto può essere reso in molti modi, ma se è possibile, integrarlo direttamente all’interno della feature a cui si riferisce è quasi sempre la scelta migliore. Quando si offre del contenuto d’aiuto all’interno del contesto, l’affordance è alta: ossia, l’aiuto risulta ovvio per l’utente. Ancora meglio, l’aiuto basato sul contesto è meno disgregativo del workflow, perché non richiede al lettore di consultare una pagina separata. In aggiunta a ciò, non fa affidamento su degli screenshot o su delle illustrazioni, quindi è anche più semplice da mantenere. Ad un livello tecnico, l’aiuto integrato dovrebbe essere strettamente agganciato al codice che supporta, rendendo molto meno probabile che i cambiamenti all’applicazione si insinuino indipendentemente.

Istruzioni in linea#section6

L’aiuto integrato può essere tanto semplice quanto una guida in linea su cosa inserire in una form web, come si vede nell’esempio sotto nel processo di registrazione di un account in Twitter. Qui, del testo esplicativo appare parallelamente ad ogni campo di input della form non appena riceve il focus.

La pagina di registrazione di Twitter mostra le richieste di formato accanto al campo password.

Questo approccio funziona bene per semplici istruzioni o per definizioni di termini—cose che quasi sicuramente vanno bene per tutti gli utenti— ma non è pratico se il contenuto dell’aiuto non è estremamente corto.

Tooltip#section7

Il modello “tooltip” è un altro modo non intrusivo per integrare l’aiuto. Con questo approccio, un link o un’icona indicano che è disponibile un aiuto, i cui dettagli vengono rivelati solo al passaggio del mouse sopra di esso. L’effetto può essere raggiunto nella maggior parte dei browser web usando l’attributo title di un’anchor o di un elemento immagine. Tuttavia, questa tecnica non offre alcun controllo sulla formattazione del testo e c’è spesso un ritardo tra l’azione “mouseover” e la resa del contenuto, un effetto indesiderato. Considerate CSS e/o JavaScript per creare dei tooltip più sofisticati.

Come per l’aiuto in linea, i tooltip dovrebbero essere strettamente abbinati al contenuto dell’applicazione ed avere una forte affordance. Un ulteriore vantaggio consiste nel tenere il contenuto nascosto alle persone a cui non serve. Comunque, sono ancora una volta utili solo per presentare dei brevi segmenti di testo con uno stile minimale. Inoltre, questo modello potrebbe non funzionare bene al di fuori dei tradizionali browser desktop—ad esempio, in un’interfaccia tattile.

Il software di analitica in realtime Chartbeat usa i tooltip all’interno della sua dashboard per spiegare il significato delle singole metriche:

Questo tooltip definisce quello che Chartbeat considera una visita attiva.

Dialoghi modali#section8

Con i dialoghi modali potete presentare del contenuto più lungo o più complesso (includendovi delle illustrazioni, ad esempio) senza portare l’utente fuori dall’attuale workflow. Dovete considerare che l’interazione sul web avviene spesso attraverso le form. Se un utente completa parzialmente una form e ha bisogno di aiuto per completare questo task, un normale link al contenuto che si trova su un’altra pagina può presentare un grande problema: a meno che il link non si apra in una nuova finestra, la persona perderà tutto quello che aveva inserito nella form visitando tale pagina. E aprire una finestra separata introduce della complessità addizionale che considereremo a breve. I dialoghi modali sono un compromesso, permettendoci di utilizzare contenuto più lungo sulla pagina corrente. Questo pattern ha comunque dei problemi: dipende da JavaScript e quindi ha bisogno di un meccanismo di fallback nel momento in cui il linguaggio di scripting non è disponibile. E sebbene un dialogo modale possa contenere maggiori informazioni rispetto ad un tooltip, la lunghezza del contenuto è ancora limitata.

In questo esempio, Facebook utilizza un dialogo modale per rispondere ad una domanda comune sulla sua pagina di registrazione:

Il dialogo modale di Facebook spiega perché gli utenti devono fornire la loro data di nascita al momento dell’iscrizione.

Aiuto non integrato#section9

A volte il contenuto dell’aiuto deve essere lungo ed efficace. Quando questo è il caso, il content strategist e gli sviluppatori devono affrontare una serie di decisioni importanti. Come interagiranno gli utenti con l’informazione? Vi accederanno indipendentemente dall’applicazione a cui si riferisce, richiedendo una navigazione separata o attraverso un tool di ricerca? E, più critico, come gestiranno gli aggiornamenti e le aggiunte? Assicuratevi di stabilire delle politiche di workflow fin dall’inizio di un progetto.

Finestre separate#section10

Le finestre di popup hanno la meritata reputazione di essere una delle tecnologie più dolorosamente abusate del web. La saggezza dell’industria dell’usabilità convenzionale asserisce che gli utenti vogliono avere controllo sulla propria esperienza. Se vogliono una nuova finestra del browser o un nuovo tab, ne apriranno uno: gli sviluppatori non dovrebbero prendere delle decisioni al posto loro. Ma ci sono delle eccezioni a questa regola, come i link che puntano a dei documenti non HTML. Quando questi vengono aperti nella finestra principale del browser e resi attraverso un plugin, gli utenti tendono a chiudere inavvertitamente il browser invece di tornare alla pagina precedente.

Il contenuto del help è un altro forte candidato all’apertura in nuove finestre, per evitare di spezzare il flusso di lavoro dell’utente. Tuttavia, questa pratica porta con sé dei rischi: gli utenti “power” potrebbero trovarsi a loro agio nel gestire più finestre ma sono anche quelli che probabilmente avranno meno bisogno di aiuto. Le nuove finestre possono confondere gli individui meno tecnici. Se la nuova finestra va a sovrapporsi alla vecchia e contiene le cromature di default del browser, la nuova finestra potrebbe non risultare ovvia ed il pulsante “indietro” sarà inutile per far tornare l’utente alla pagina originale.

Usare JavaScript invece di un link target può aiutare ad affrontare questa questione. Possiamo controllare la dimensione della nuova finestra per assicurarci che non oscuri completamente la pagina originale e possiamo disabilitare la barra di navigazione ed altre cromature che non sono rilevanti. Però questo carica molto il lavoro degli sviluppatori, che devono gestire in maniera adeguata più finestre. Considerate il seguente scenario comune:

1. Viene creata una nuova finestra con:
   window.open('widget-1-help.html','help_window','width=450')
2. L’utente ne legge il contenuto e poi clicca per tornare indietro alla pagina originale senza chiudere la finestra di aiuto.
3. L’utente clicca su un secondo link di aiuto con:
   window.open('widget-2-help.html','help_window','width=450')

In molti browser (Safari è un’eccezione), sembrerà che il secondo click non serva ad alcunché. In realtà, il nuovo contenuto è stato caricato nella finestra esistente (perché lo stesso nome era stato specificato nel secondo argomento della funzione). Ma la finestra non ottiene automaticamente il focus quando viene aggiornata. Pertanto, ogni chiamata a window.open deve o specificare un nome univoco per la finestra o portavi il focus esplicitamente dopo il caricamento.

La gestione della finestra è solo una delle complessità che i contenuti di aiuto in forma estesa introducono e questioni come queste costituiscono un argomento convincente per l’utilizzo dell’aiuto integrato ogni qualvolta sia possibile. Ma anche quando questo non è possibile, i link al contenuto di aiuto dovrebbero essere sensibili al contesto. E’ molto più efficace fornire dei link a dei topic specifici piuttosto che un generico pulsante “Help” che richiede all’utente una nuova navigazione.

Nell’esempio seguente, Github informa il nuovo utente che deve generare delle chiavi SSH per pubblicare il codice. Generare delle chiavi non è un argomento semplice, così il sito mette un link alle istruzioni. Il collegamento si apre in una finestra separata con una pagina di aiuto lunga, ma oltre a questo, rileva automaticamente se il sistema operativo è MacOS o Windows e mostra un insieme di istruzioni specifiche per il sistema rilevato—un eccellente esempio di sensibilità al contesto.

Github fornisce un collegamento alle istruzioni per la creazione delle chiavi SSH.

Domande e Risposte#section11

Molti siti web strutturano il contenuto di aiuto in un formato domanda-e-risposta, anche quando non utilizzano esplicitamente l’etichetta “FAQ.”. Sebbene il modello FAQ sia stato lungamente discusso altrove, è interessande considerare come funziona.

Quando è scritto sotto forma di domande, il contenuto di aiuto guadagna automaticamente un tono conversevole ed informale. Se l’utente si identifica con una delle domande, si sente compreso—l’azienda ha previsto le sue domande e non pensa che sia stupido. Chiaramente, la chiave qui sta nello scrivere delle buone domande—e anche se il testo non è scritto come una domanda, l’informalità è disarmante. Il contenuto dell’aiuto è l’ultimo posto per i messaggi di marketing. Una domanda come “Perché le widget ACME sono le widgets migliori del mondo?” è molto improbabile che aiuti sia l’utente sia gli affari dell’azienda.

Può essere una sfida tuttavia organizzare le domande in maniera tale che un utente possa farle scorrere quando la frase scritta dall’autore non è la stessa dell’utente. Ancora una volta, è di aiuto collegare topic specifici all’interno del contesto piuttosto che offrire un gran numero di domande ad un utente che ne sta ponendo solo una.

Fan straordinari#section12

Gli utenti frustrati possono diventare i più grandi fan di un’azienda. Le persone che non hanno problemi ad usare un sistema possono non prendere in grande considerazione l’esperienza. Ma quelli che si imbattono in alcune difficoltà e poi trovano che il sistema anticipi il loro bisogno di aiuto (e sia davvero efficace) sono più propensi ad apprezzare il riguardo che gli sviluppatori del sistema hanno per il business stesso. Un contenuto di aiuto efficace è un tool potente e sotto-utilizzato per rendere l’esperienza possibile.

Illustrazioni: {carlok}