Gli utenti di software enterprise usano spesso solo una frazione delle funzionalità disponibili e sviluppano workaround manuali fuori dalla piattaforma. Non è sempre un problema di usabilità delle features. Quando un onboarding viene progettato per il consumatore invece che per il professionista, quella scelta può danneggiare l’investimento nel software.
Immagina di essere un cardiologo con quindici anni di esperienza.
Mentre stai completando una pratica, apri per la prima volta il nuovo sistema di refertazione adottato dall’ospedale.
Appare una schermata: “Benvenuto! Inizia il tour guidato →”.
Chiudi il tour immediatamente. Clicchi in giro. Ti senti rallentato. Decidi che è necessario chiamare l’IT perché hai bisogno di completare diverse pratiche.
Non è semplicemente la descrizione di un problema di usabilità. È un problema di progettazione che non tiene conto degli utenti e del loro contesto.
L’onboarding non è progettato per il professionista
Tutti i pattern, tutti i framework sull’onboarding e parte della letteratura sono costruiti attorno a un’assunzione implicita: l’utente è un principiante che ha bisogno di essere guidato.
Questo funziona per Duolingo, per Spotify, per un’app consumer. Non funziona per un trader su una piattaforma di execution, per un avvocato su un sistema di gestione documentale, o per un biologo su un software di analisi genomica.
L’utente esperto porta con sé qualcosa che una progettazione generalista ignora sistematicamente: un modello mentale già formato, un vocabolario tecnico preciso e una necessità di massima efficienza e di controllo degli strumenti.
Chiedergli di seguire un wizard di introduzione al lavoro è come spiegare le note musicali a un pianista classico prima di farlo suonare.
Tre errori di onboarding che impattano gli utenti business (e costano contratti)
1. Il tour obbligatorio
Bloccare l’interfaccia con un overlay che guida passo dopo passo è il pattern più diffuso e più odiato dagli utenti esperti. Li rallenta, li tratta come principianti, e, se non c’è un modo chiaro per saltarlo, genera frustrazione immediata che si accumula sulla percezione del prodotto.
2. I tooltip contestuali non richiesti
Ogni volta che un utente porta il cursore su una voce di menu e appare una spiegazione di cosa fa quella funzione, il messaggio implicito è: “Tu questa non la sai, fattelo spiegare da me!”. Nel primo periodo di utilizzo, specialmente, è un bombardamento, finché l’utente non trova il modo per disfarsene o finché non scompare da solo.
3. Il completamento forzato di informazioni
Quando l’onboarding prevede azioni forzate, come “Completa il profilo per continuare” o “Prima di iniziare, imposta le tue preferenze”, cioè quando il flusso di lavoro viene bloccato per forzare il completamento di step preliminari, il risultato può essere un ostacolo all’efficienza. Questa tecnica può funzionare bene in contesti che, per fornire un risultato utile, richiedono l’input di dati essenziali. Ma spezza il flusso utente e può portare all’abbandono, alla frustrazione o all’adozione di workaround anche fuori dalla piattaforma.
Il tono sbagliato
Questo è un errore più sottile, e sta diventando più comune, a causa di un uso non professionale nella generazione di microcopy.
Un testo informale calibrato sul consumatore, invece che sul professionista, scritto con un tono colloquiale, incoraggiante e semplificato, funziona bene su Airbnb.
In un software di diagnostica clinica, di gestione del rischio finanziario o di analisi legale, quel tono suona fuori luogo e a volte è percepito come fastidioso. Un medico specialista che ad esempio legge: “Ottimo lavoro! Hai salvato il tuo primo referto 🎉” non si sente necessariamente incoraggiato. Si sente trattato come un bambino.
Il linguaggio dell’interfaccia dovrebbe riflettere il registro professionale del dominio: privo di metafore infantilizzanti, preciso, possibilmente coerente e in linea con il mondo che vive ogni giorno il professionista.
Lo stesso vale per i messaggi di errore: “Ops, qualcosa è andato storto!” non è accettabile in un contesto dove l’errore può avere conseguenze operative e oltretutto sminuisce la percezione dell’intelligenza del software.
L’utente esperto ha bisogno di sapere esattamente cosa è successo, perché è successo e come risolvere, perché ha bisogno che il software sia di supporto al suo intento, non di essere rassicurato con emoji fuori luogo.
Empatizzare con l’utente significa attenzione all’altro. In ambito professionale, quell’attenzione si traduce in un UX writing calibrato: più precisione, piuttosto che personalità; più rispetto, piuttosto che calore.
Il costo di un onboarding sbagliato in ambito B2B
Quello che gli utenti temono quando adottano un nuovo sistema non è il cambiamento in sé, ma la perdita di produttività durante la transizione. Per evitarla, restano su ciò che conoscono: usano solo le funzionalità più ovvie, sviluppano workaround su Excel o su carta, e costruiscono abitudini che escludono tutto il resto della piattaforma.
In ambito enterprise il costo non si misura in churn immediato. Il contratto è firmato, il deployment è avvenuto: l’utente deve usare il prodotto.
Il risultato è un prodotto pagato per intero e usato in parte.
Il problema si vede solo al rinnovo: la percezione è che il software “non soddisfi tutte le nostre esigenze”, quando in realtà le soddisfaceva, ma nessuno le aveva mai scoperte.
Il vero costo di un onboarding sbagliato in ambito B2B è questo: un investimento che non viene mai recuperato, e una relazione con il prodotto che si cristallizza nelle prime settimane di utilizzo e raramente cambia.
Come deve essere progettato un onboarding per utenti business
Un product onboarding progettato per utenti esperti è contestuale, progressivo e reversibile: fornisce informazioni quando servono, rivela la complessità gradualmente e lascia sempre il controllo all’utente.
L’onboarding per esperti non significa rinunciare a un onboarding guidato. Significa un onboarding progettato secondo principi diversi.
Contestuale
Le informazioni appaiono nel momento in cui l’utente ne ha bisogno, non prima.
Un chiarimento sull’uso di una funzione appare ad esempio con un delay, quando l’utente si ferma su quell’informazione, e non appena apre la schermata o appena sfiora l’informazione.
Progressivo
Le funzionalità avanzate si rivelano gradualmente, man mano che l’utente le esplora. Non perché siano nascoste, ma perché il sistema riconosce il contesto o il livello di utilizzo e adatta le informazioni e le azioni di conseguenza. È il principio di progressive disclosure applicato a un flusso di lavoro, non solo alla schermata ‘statica’.
Reversibile
L’esperto ha bisogno di sapere che è lui a controllare il sistema, non il contrario. La guida e gli aiuti possono essere richiamati dall’utente manualmente quando servono. Eventuali configurazioni iniziali possono essere modificate in qualsiasi momento senza penalizzare l’utente.
Cosa dovrebbe fare il team di progetto in questi casi
Prima di riprogettare l’onboarding, occorre rispondere a tre domande che spesso nessuno si pone:
- Chi sono gli utenti reali, in cosa differiscono da quelli descritti nei pitch deck? Quanti anni di esperienza hanno nel dominio? Quanti sistemi simili hanno già usato? Che tipo di aspettative hanno rispetto all’applicazione?
- Quale è la prima azione significativa degli utenti, quella che, se compiuta con successo nei primi giorni, può predire la retention a 90 giorni?
- Cosa rappresenta il “successo” per queste persone, invece che per il product manager? La risposta non è nel completamento di un tour, ma in un referto inviato, un’analisi esportata, un contratto archiviato.
Queste domande richiedono una conoscenza contestuale. Non un sondaggio, non un A/B test, bensì la conoscenza degli utenti e del loro contesto di lavoro, con strumenti veloci di analisi, pensati per chi lavora in ambienti ad alta densità cognitiva e ha scarso tempo da dedicare a indagini mirate.
Conclusione
L’onboarding standard ha un impatto diverso sugli utenti esperti, può essere dannoso per il business, perché comunica il messaggio sbagliato nel momento più delicato, quello in cui l’utente sta decidendo se fidarsi del sistema.
Progettare onboarding per utenti esperti è una disciplina separata, che richiede comprensione profonda del dominio, metodi di analisi diversi e pattern di interazione che ancora oggi sono poco documentati o dibattuti.
È qui che si gioca sottotraccia la differenza tra un prodotto adottato e un prodotto abbandonato, anche quando il contratto è già firmato.
Stai progettando software per utenti professionali in ambito sanitario, finanziario, legale o industriale? Raccontaci il tuo progetto
Autore: Gabriella Moro, UX Manger @ Bitrock