Empty state: i 4 stati che ogni schermata deve prevedere

Alla fine di questa guida avrai quattro empty state scritti per ogni lista, tabella e dashboard del tuo prodotto: primo accesso, nessun risultato, lista svuotata, errore. Ognuno con un titolo, una sola azione e un messaggio che lo screen reader legge quando lo stato cambia. Serve circa un pomeriggio per schermata ed è il lavoro di onboarding che costa meno di tutti.

L'empty state è la schermata che il prodotto mostra quando non ci sono dati. Il design system di Atlassian lo definisce come la vista che compare quando non ci sono dati e dice all'utente cosa può fare. È la seconda metà della definizione a saltare quasi sempre: si rilascia un solo «Nessun elemento» e lo si usa per quattro situazioni che chiedono quattro risposte diverse.

Cosa serve prima di cominciare

• L'elenco delle schermate il cui contenuto arriva da una query: liste, tabelle, dashboard, risultati di ricerca, pannelli laterali, feed di attività, centro notifiche.
• Chi scrive il microcopy. Un empty state è quasi tutto scrittura: lasciarlo a uno sviluppatore produce venti schermate con «Nessun dato disponibile».
• Una decisione sulle illustrazioni, presa una volta per tutto il prodotto: disegnarle, comprarle o non usarle. Tre stili diversi su dieci schermate si notano più dell'assenza di illustrazioni.
• Uno screen reader. VoiceOver su macOS, NVDA su Windows. Il punto 6 non si verifica leggendo il codice.

Passo 1: censire ogni schermata che può restare senza dati

Attraversa il prodotto e annota ogni schermata alimentata da una query. Per ciascuna, poniti la domanda che il design system Carbon di IBM mette al centro del suo pattern sugli empty state: come si presentano pagine, tile, tabelle e pannelli laterali senza contenuto? Un prodotto B2B di media dimensione ne ha tra le 15 e le 40. Metà non le ha mai viste vuote nessuno del team, perché in sviluppo i dati di test le nascondono.

Due modi rapidi per trovarle. Punta una build locale su un database vuoto e apri ogni rotta. Poi interroga la produzione cercando gli account con zero righe nell'entità principale: quelle persone stanno guardando i tuoi empty state adesso, e sono le stesse che decidono se tornare.

Passo 2: separare l'unico empty state in quattro

I quattro stati hanno cause diverse, quindi chiedono testi e azioni diverse.

• Primo accesso. L'account è nuovo e la tabella non ha mai contenuto dati. Il compito è dire cosa comparirà qui e come metterlo.
• Nessun risultato. Una ricerca o un filtro non hanno trovato niente. I dati ci sono, la query li ha mancati. Il compito è riportare l'utente ai risultati.
• Lista svuotata. L'utente ha archiviato, completato o cancellato tutto. È un successo, e il testo deve dirlo prima di proporre altro.
• Errore. La richiesta è fallita. Il compito è dire cosa è andato storto e offrire un nuovo tentativo.

L'errore è il caso che finisce più spesso dentro gli altri tre, ed è quello che fa danni veri. Una richiesta fallita mostrata come «Non hai ancora nessun progetto» comunica a un cliente pagante che il suo lavoro è sparito. Tieni le strade separate dentro il componente: una prop variant con quattro valori costa un'ora e rende l'errore impossibile.

Passo 3: scrivere il titolo in positivo

L'indicazione di Carbon sui titoli è breve e conviene copiarla: scrivi il titolo come un'affermazione positiva ogni volta che puoi. «Comincia aggiungendo un asset» si legge meglio di «Non hai nessun asset». Quando il negativo è inevitabile, la parola «ancora» ripara buona parte del tono.

Tre regole che valgono per ogni empty state che rilasciamo:

• Il titolo dice la situazione o il passo successivo in meno di otto parole.
• Il corpo spiega cosa ottiene l'utente facendo quel passo, non come funziona il pulsante sotto.
• Nessuna scusa. «Ci dispiace, qui non c'è niente» consuma l'attenzione di chi legge per parlare dei tuoi sentimenti su una tabella vuota.

Passo 4: una sola azione, messa dove sta l'azione

Un'azione primaria per empty state. Un link secondario alla documentazione va bene. Un secondo pulsante è una scelta che l'utente non può fare, perché quella funzione non l'ha mai usata.

Carbon elenca tre modi per presentare l'azione: un pulsante sotto il testo, un link dentro il testo, oppure un'istruzione che indica il controllo vero dell'interfaccia. Il terzo è sottovalutato. Indicare il pulsante «Nuovo progetto» nella barra insegna dove sta il controllo, così la seconda volta l'empty state non serve più. Usalo quando il controllo è nella stessa schermata, e usa un pulsante quando non lo è.

Passo 5: trattare «nessun risultato» come un problema di recupero

È lo stato su cui esiste ricerca pubblica. Il benchmark di Baymard Institute sulla ricerca negli ecommerce ha rilevato che quasi la metà dei siti non offre una via di ritorno utile dopo una ricerca a vuoto: la schermata diventa un vicolo cieco e gli abbandoni salgono.

Il recupero è lavoro concreto, non una frase più gentile:

• Mostra la query eseguita, così chi legge vede l'errore di battitura.
• Lascia il campo di ricerca compilato e con il focus, così correggere costa un tasto.
• Proponi la cosa più vicina che hai: la stessa ricerca senza un filtro, oppure la lista completa, con il numero dei risultati.
• Dichiara il perimetro. «Nessuna fattura per "acme" nel 2024» dice quale delle tre cose cambiare.

Le indicazioni di Nielsen Norman Group sulle pagine «nessun risultato» vanno nella stessa direzione. I consigli di ricerca generici sono la cosa più debole da mettere qui: quando l'utente legge «controlla l'ortografia», l'ha già controllata.

Passo 6: rendere lo stato udibile allo screen reader

Un empty state che compare dopo il cambio di un filtro è un messaggio di stato ai sensi del criterio WCAG 4.1.3, livello AA. Il contenuto è cambiato senza ricaricare la pagina e senza spostare il focus, quindi la tecnologia assistiva va avvisata a parole.

Cosa vuol dire nel markup:

• La live region deve stare nel DOM prima che il contenuto cambi. Montare il contenitore e il messaggio nello stesso render spesso non annuncia niente.
• Usa role="status" per il conteggio dei risultati. Porta con sé un aria-live="polite" implicito, così l'annuncio aspetta una pausa invece di interrompere chi ascolta.
• Annuncia il fatto, non la decorazione. Il messaggio è «Nessuna fattura corrisponde a questo filtro».
• Le illustrazioni degli empty state sono decorative, quindi vogliono un attributo alt vuoto, come indica la guida W3C sulle immagini decorative. Carbon consiglia l'alt vuoto invece di role="presentation", per ragioni di supporto.

Passo 7: tenere il caricamento fuori dall'empty state

Una schermata che sta ancora caricando non è vuota. Mostrare «Non hai ancora progetti» per 400 millisecondi mentre la richiesta è in corso insegna a chi entra la prima volta che il prodotto non funziona, e succede su ogni connessione più lenta di quella del tuo ufficio. Mostra uno skeleton finché la richiesta è in corso, poi passa all'empty state quando la risposta conferma zero righe. Polaris di Shopify separa le due cose allo stesso modo: componenti skeleton per il caricamento, componente empty state per la risposta.

Come verificare che funzioni

Cinque controlli per schermata, una ventina di minuti l'uno.

1. Crea un account nuovo senza dati e apri ogni rotta. Fai uno screenshot di ogni schermata vuota che incontri.
2. Cerca una stringa che non può corrispondere a niente, poi torna ai risultati con un clic. Se non ci riesci, il passo 5 non è finito.
3. Cancella tutto su una schermata e leggi il risultato ad alta voce. Deve suonare come un lavoro finito, non come un guasto.
4. Blocca la richiesta dai devtools. La schermata deve dire che la richiesta è fallita e offrire un nuovo tentativo, mai «non hai ancora niente».
5. Attiva VoiceOver o NVDA e applica un filtro che non restituisce nulla. Se non senti niente, il passo 6 non è finito.

Errori frequenti e come si risolvono

• L'errore travestito da primo accesso. Un solo catch, un solo componente generico, e un 500 diventa «Crea la tua prima fattura». Si risolve a monte: distinguere un risultato vuoto da una richiesta fallita prima ancora che il componente venga renderizzato.
• Un'azione che l'utente non può compiere. Un account con ruolo di sola lettura legge «Crea il tuo primo progetto» e non ha il permesso di creare. Controlla il permesso prima di mostrare il pulsante e sostituisci il testo con quello che questa persona può fare davvero, cioè quasi sempre chiedere a un amministratore.
• L'illustrazione che porta il messaggio. Se togliendo il disegno sparisce il significato, il testo non è finito. Scrivi lo stato perché funzioni in solo testo, poi aggiungi l'immagine.
• La dashboard vuota. Una dashboard con otto grafici a zero è la peggior prima schermata del software. L'alternativa suggerita da Carbon è lo starter content: dati di esempio che l'utente esplora e poi cancella. Costa lavoro di prodotto vero, quindi tienilo per la schermata principale e lascia empty state semplici su quelle secondarie.
• Testi scritti una volta e poi abbandonati. Gli empty state citano le funzionalità, e le funzionalità cambiano nome. Mettili nella stessa revisione dei testi di onboarding, non in un backlog separato che non apre nessuno.

Dove si collega

Gli empty state sono la metà economica del lavoro sull'attivazione. La metà cara è il flusso che li circonda, di cui parliamo in onboarding UX: i pattern che riducono l'abbandono iniziale. Se la schermata da sistemare è una dashboard, le scelte sulla densità vengono prima: vedi design di dashboard SaaS. E il passo 6 è una riga di una lista molto più lunga, che percorriamo in design accessibile dopo l'EU Accessibility Act.