L’onboarding ha funzionato, gli utenti se ne sono andati lo stesso

Nei team di prodotto con cui lavoriamo capita spesso di assistere alla stessa scena.

Il prodotto è stato costruito con cura, dopo mesi di ricerca, wireframe e test; l’onboarding funziona, al primo accesso gli utenti capiscono cosa possono farci e i numeri delle prime settimane sono incoraggianti.

Due mesi dopo, circa la metà di quegli utenti non apre più l’app, e nessuno sa spiegare perché: non ci sono segnalazioni, non ci sono bug.

Il prodotto funzionava, e anche l’onboarding. Mancava la risposta a una domanda che nessuno aveva mai messo sul tavolo: perché quella persona dovrebbe tornare?

La domanda che quasi nessuno si fa

Come far capire il prodotto al primo utilizzo? Su questa domanda il settore ha costruito negli anni un intero repertorio di pratiche: flussi di onboarding, tour guidati, tooltip, empty states che spiegano cosa fare.

Molto più raramente, nei brief che riceviamo o nei kickoff a cui partecipiamo, qualcuno chiede perché l’utente dovrebbe riaprire il prodotto dopo una settimana, dopo un mese o dopo due.

Sono domande diverse, e confonderle è l’origine di molti problemi.

L’onboarding risolve un problema di comprensione: l’utente deve capire cosa fa il prodotto e come si usa.

La retention ci mostra la sua abitudine: il prodotto deve trovare un posto stabile nella giornata di qualcuno che ha già molte altre cose da fare.

Cambiano i tempi, cambiano le metriche e cambia il tipo di lavoro che serve al team di design.

I primi minuti contano ma non bastano

C’è però un punto in cui le due fasi si toccano, ed è il Time to First Value: il tempo che passa tra il primo accesso e il momento in cui l’utente vede (in modo concreto) che il prodotto risolve un suo problema reale.

Se quel momento arriva troppo tardi, la questione della retention non si pone nemmeno, perché l’utente se ne va prima di avere avuto il tempo di creare un abitudine.

Slack è l’esempio più citato, e lo è per una buona ragione: pochi minuti dopo l’iscrizione l’utente ha mandato un messaggio e ha ricevuto una risposta. Non ha bisogno di leggere nulla per capire a cosa serve lo strumento, perché lo ha appena usato per la cosa per cui esiste.

Accorciare il Time to First Value, quindi, non vuol dire semplificare il prodotto o nascondere le funzioni avanzate, ma individuare il percorso più breve verso quel primo risultato concreto e togliere tutto ciò che lo rallenta.

Detto questo, un buon Time to First Value è una condizione necessaria e non sufficiente. Ci dice che l’utente ha capito, non che tornerà.

Le abitudini non si decidono

Le abitudini non nascono dal nulla.

La ricerca in psicologia comportamentale, a partire dai lavori di Wendy Wood, mostra che si formano per ripetizione in un contesto stabile: lo stesso momento della giornata, lo stesso trigger, lo stesso problema che si ripresenta.

Uno studio della University College London ha misurato che per rendere automatico anche un comportamento semplice servono in media più di 2 mesi, con differenze molto ampie da persona a persona. È un orizzonte che va ben oltre la fine di qualsiasi onboarding.

Per chi progetta la conseguenza è piuttosto precisa.

Un utente continua a usare un prodotto perché, nel frattempo, il prodotto è diventato parte di qualcosa che faceva già.

Il prodotto ha quindi molte più possibilità di restare se si aggancia a un momento che esiste già nella giornata dell’utente, a un problema che si ripresenta con regolarità, a un trigger che c’è comunque: l’inizio della settimana lavorativa, la chiusura di un ordine, il resoconto da mandare al proprio responsabile ecc.

Vale anche il contrario: i prodotti che si presentano come una rivoluzione, e chiedono all’utente di abbandonare i suoi strumenti, ripartire da zero e convincere il resto del team a fare lo stesso, partono con una salita molto più ripida.

Anche quando la proposta è tecnicamente migliore, il costo di cambiare abitudini ricade tutto sull’utente, e di solito l’utente preferisce evitarlo.

Un prodotto che migliora con chi lo usa

La domanda più utile che un team possa farsi sulla retention è anche la più semplice: il nostro prodotto diventa più utile man mano che viene usato?

Un CRM diventa più prezioso quando contiene anni di storico sulle relazioni con i clienti, un gestionale quando rispecchia le procedure dell’azienda, uno strumento di analisi quando conosce le metriche che il team cerca davvero.

Lo stesso vale per l’esperienza d’uso: un utente al terzo mese conosce il prodotto, ha meno pazienza per i passaggi che all’inizio lo aiutavano e si aspetta scorciatoie, automazioni, funzioni che al primo accesso sarebbero state solo distrazione.

Progettare per la retention significa prevedere anche questo percorso: cosa scopre l’utente dopo la prima settimana, cosa dopo il primo mese e cosa gli offre il prodotto quando ormai lo conosce bene.

C’è poi un meccanismo psicologico che viene spesso citato a questo proposito, l’effetto IKEA. Una ricerca di Michael Norton, Daniel Mochon e Dan Ariely ha mostrato che le persone attribuiscono più valore alle cose che hanno contribuito a costruire.

Nei software questo si traduce nel valore percepito dello spazio di lavoro personalizzato, delle automazioni configurate, dalle integrazioni installate con altri strumenti.

Va però tenuto distinto da un altro effetto con cui viene spesso confuso: il costo di uscita. Più un utente investe in un prodotto, più gli costa andarsene, perché dovrebbe rifare la configurazione, spostare i dati e imparare uno strumento nuovo.

Su questo la nostra posizione è netta: il costo di uscita può essere la conseguenza di un prodotto che accumula valore, ma non dovrebbe mai diventare l’obiettivo del design.

Un utente che resta solo perché andarsene è troppo faticoso non è un utente fidelizzato, è un utente che aspetta l’occasione giusta per cambiare.

User research come parte del prodotto

Se la retention dipende da comportamenti che si formano nel corso di settimane, il lavoro di design non può fermarsi al lancio.

La maggior parte della ricerca utente si concentra sulle prime sessioni: test di usabilità, interviste prima del rilascio e subito dopo.

I comportamenti che decidono se un utente resta, però, emergono più tardi, e per osservarli servono metodi diversi: diary study che seguono le persone per diverse settimane, interviste a chi usa il prodotto da un mese, da sei mesi o da due anni, analisi dei dati d’uso nel tempo e, soprattutto, conversazioni con chi ha smesso di usarlo.

Molti team considerano queste attività occasionali, da fare quando avanza budget o tempo. Per un prodotto che vive di utilizzo ripetuto nel tempo dovrebbero invece essere una parte ordinaria del ciclo di sviluppo.

Quattro domande per la tua prossima review

Non esiste una formula per la retention, ma ci sono domande che cambiano il modo di lavorare di un team, se vengono poste con regolarità. Ne proponiamo quattro da portare nella prossima revisione di prodotto.

1. Quale comportamento vorremmo vedere in un utente al trentesimo giorno, e oggi lo stiamo misurando?

2. Cosa trova di nuovo nel prodotto una persona che lo usa da tre mesi, rispetto al primo giorno?

3. Il prodotto diventa più utile quanto più viene usato, oppure offre sempre lo stesso valore?

4. Chi, nel team, ha la retention tra i propri obiettivi di progettazione, e non solo tra i numeri da controllare a fine trimestre?

---

eyestudios è uno studio di Experience Design che lavora dove la complessità è reale prodotti digitali articolati, organizzazioni con molti stakeholder, ecosistemi in trasformazione. Non ci fermiamo alla superficie: portiamo strategia, ricerca e metodo nei progetti che richiedono più di un buon wireframe.

Abbiamo lavorato e formato aziende come Unox, Aiko, Shampora, Deliveristo, Restworld, Ulixe Group, Confindustria, Flying Tiger, Gruppo Hera, Alkemy, Mondo Convenienza, Verisure, Unipol, Almaviva, We Are Marketers, PhotoSì, ESA, Reale Mutua.