L'onboarding che abbiamo scelto di non costruire

Se nel 2026 aprirai una nuova app, è molto probabile che ti ritroverai davanti a un carosello di dieci diapositive che spiega cose che un’interfaccia ben progettata non avrebbe bisogno di spiegare.

“Scorri per vedere altro.” Sì, lo sappiamo. “Tocca qui per iniziare.” Lo stavamo già facendo. “Le notifiche ti aiutano a rimanere coinvolto.” Abbiamo qualcosa da dire su questa frase.

Il modello che evitiamo

Il lungo tutorial che precede l’installazione. La schermata iniziale che parte dal presupposto che l’utente non abbia mai visto un’app prima d’ora. La schermata che spiega “ecco come si usa un pulsante”. Queste non sono fasi di onboarding: sono semplici tattiche dilatorie che si frappongono tra l’utente e ciò che è venuto a fare.

Se l'interfaccia utente necessita di dieci schermate di spiegazioni prima di poter essere utilizzata, il problema è l'interfaccia utente. Non l'utente.

Il carosello è anche sintomo di qualcos’altro: è il posto più facile in cui inserire le spiegazioni che un team non è riuscito a inserire nel design. Ogni diapositiva è una piccola ammissione del fatto che una schermata, da sola, non era abbastanza chiara. Rimuovere il carosello ci costringe invece a correggere quelle schermate.

Cosa costruiamo invece

Una prima schermata immediatamente utile — anche se un po“ spoglia — in modo che l’utente possa iniziare a esplorare e imparare con la pratica. Suggerimenti solo dove le cose non sono davvero intuitive (e solo la prima volta). Stati vuoti che indicano all’utente cosa andrà inserito in quel punto (”La tua prima nota apparirà qui”) invece di mostrare un’immagine animata.

In pratica, questo aspetto varia a seconda dell’app. Un’app per imparare a digitare dovrebbe farti iniziare a digitare pochi istanti dopo averla aperta, perché la digitazione è la lezione stessa. Un'app per il monitoraggio delle abitudini dovrebbe consentirti di aggiungere la tua prima abitudine già dalla prima schermata. Un'app per l'organizzazione del matrimonio ha effettivamente bisogno di alcune informazioni prima di poterti aiutare, quindi può chiedertele — ma solo quelle di cui ha bisogno in quel momento — e dovrebbe mostrarti qualcosa di utile non appena hai risposto.

Chiediamo i permessi quando ne abbiamo effettivamente bisogno, non al momento del lancio. Chiediamo un account quando è utile all'utente, non perché vogliamo l'e-mail.

Per quanto riguarda le autorizzazioni, la tempistica è fondamentale. Una richiesta di autorizzazione alla localizzazione ha senso la prima volta che qualcuno chiede le previsioni di pesca per le condizioni nelle vicinanze; nella schermata iniziale, invece, è solo un pop-up che ostacola l’accesso. Se la richiesta viene fatta nel contesto giusto, il motivo è ovvio e gli utenti possono prendere una decisione consapevole. Se invece viene fatta subito all’inizio, nella maggior parte dei casi gli utenti toccano qualsiasi opzione pur di far sparire la finestra di dialogo.

I compromessi

Saltare il tutorial ha un costo. Alcune funzionalità non sono affatto intuitive e alcune persone non le scopriranno mai senza una piccola spinta. Siamo consapevoli che alcune funzionalità avanzate verranno scoperte più tardi piuttosto che subito, e ci impegniamo a renderle individuabili nel contesto — un suggerimento la prima volta che è pertinente, un'etichetta chiara, un'impostazione predefinita sensata — piuttosto che inserirle tutte all'inizio in una presentazione che nessuno ricorderà.

Cosa abbiamo sbagliato

In passato abbiamo esagerato con le correzioni. Una prima schermata vuota e priva di indicazioni non è “minimalista”; è fonte di confusione. Uno stato vuoto che riporta semplicemente la dicitura “Nessun elemento” lascia gli utenti incerti su cosa fare dopo. Ora ogni stato vuoto risponde a una domanda — “Cosa devo fare per primo?” — con un’unica azione chiara.

Il percorso più breve dall'installazione al primo momento in cui il prodotto diventa utile: ecco cos'è l'onboarding. Tutto il resto è solo un biglietto di auguri.