Pattern per stati vuoti che riducono la confusione e guidano l'utente al passo successivo di setup con copy, layout e checklist pronti da applicare rapidamente.
Una schermata vuota non è neutra. Crea una pausa in cui le persone iniziano a indovinare cosa fare, se hanno saltato un passaggio o se il prodotto funziona. Durante il setup quella pausa è costosa. Trasforma un “sto iniziando” in un “tornerò più tardi”.
Lo stato vuoto è ciò che l'utente vede quando non c'è ancora nulla da mostrare perché non ha creato, importato o collegato niente. Non è una schermata di caricamento, un messaggio d'errore o un avviso di permessi. È il momento subito prima che arrivi valore, quando l'app deve aiutare l'utente ad arrivare a un primo risultato significativo.
Un buon stato vuoto ha un solo compito: portare l'utente verso la prossima azione di successo con il minimo sforzo mentale possibile. “Successo” conta. Il passo successivo dovrebbe produrre un risultato reale (un primo progetto, una fonte dati collegata, un primo elemento creato), non un modulo senza uscita o un tour generico del prodotto.
Questi momenti compaiono più spesso di quanto i team pensino: primo accesso dopo la registrazione, uno spazio di lavoro nuovo di zecca, una tab di funzionalità senza elementi (progetti, clienti, file) o un percorso di setup dove l'import è stato saltato e non esiste nulla.
Quando uno stato vuoto fa il suo lavoro, risponde rapidamente a tre domande:
Esempio: in Koder.ai un nuovo utente può aprire uno spazio di lavoro vuoto e non vedere ancora app. Uno stato vuoto efficace dice chiaramente che non è stato creato nulla, offre un'azione successiva ovvia come “Crea la tua prima app” e aggiunge una piccola nota di sicurezza (per esempio, che l'esportazione del codice sorgente e gli snapshot sono disponibili una volta iniziato). L'obiettivo è trasformare “niente qui” in “posso arrivare a un primo risultato funzionante”.
Per un utente alla prima esperienza, una schermata vuota può sembrare che l'app si sia bloccata o che abbia fatto qualcosa di sbagliato. La mente riempie il vuoto rapidamente, e di solito non a tuo favore.
La maggior parte delle persone si fa in silenzio le stesse domande:
Le emozioni dietro a queste domande guidano il comportamento. L'incertezza fa esitare. La paura di sbagliare fa evitare il pulsante primario. L'impazienza spinge a chiudere l'app se non compare un passo successivo chiaro in pochi secondi.
Gli stati vuoti per nuovi utenti e per utenti esperti risolvono problemi diversi. I nuovi utenti hanno bisogno di contesto e sicurezza perché non conoscono ancora il tuo vocabolario. Gli utenti di ritorno vogliono velocità: un modo rapido per creare un altro elemento, importare dati o ripetere un'azione già nota.
Gli stati vuoti di setup sono anche diversi dagli stati di errore e di caricamento. Il caricamento dice “aspetta, qualcosa sta succedendo.” L'errore dice “qualcosa è fallito, ecco perché.” Il setup dice “qui non c'è ancora niente, ed è normale. Ecco come iniziare.”
Un esempio concreto: se qualcuno apre un nuovo workspace in Koder.ai e vede una pagina Progetti vuota, non sta pensando alle funzionalità. Sta chiedendosi “Parto da un prompt, importo codice o scelgo un template, e romperò qualcosa?” Il tuo stato vuoto dovrebbe rispondere a questo senza mandarlo alla documentazione.
Un buon stato vuoto non sembra vuoto. Si comporta come un segnale: “Ecco cos'è questa area, ecco il prossimo clic.”
Una struttura che funziona nella maggior parte dei flussi di setup ha tre parti:
Mantieni la spiegazione stretta. Se ti serve un paragrafo per spiegare la schermata, stai chiedendo all'utente di pensare troppo. Punta a 1–2 frasi brevi con parole semplici come “Aggiungi il tuo primo progetto” o “Crea il tuo primo workspace.”
Poi rendi il passo successivo ovvio con un singolo pulsante primario. Se mostri tre pulsanti di pari importanza stai chiedendo all'utente di scegliere una strada prima di capire la pagina. Se devi offrire alternative (importa, template, salta), mantienile visivamente più discrete rispetto all'azione principale.
Usa la riga di rassicurazione per rimuovere paure comuni: sbagliare, perdere tempo o necessitare di competenze tecniche. Piccoli suggerimenti su cosa succede dopo e su cosa può essere annullato aiutano più della spiegazione lunga.
Esempio di copy per una schermata Progetti per chi arriva per la prima volta:
Titolo: Crea il tuo primo progetto
Spiegazione: I progetti contengono la configurazione dell'app e le release.
Azione primaria: Crea progetto
Rassicurazione: Ci vogliono circa 2 minuti. Puoi rinominarlo in qualsiasi momento.
Se il tuo prodotto supporta più modi per iniziare (build da chat, import, o template, come strumenti tipo Koder.ai), mantieni “Crea” come predefinito e metti “Importa” e “Usa un template” come azioni secondarie sotto.
Gli stati vuoti falliscono quando il copy parla di funzionalità invece di cosa ottiene l'utente. Le tue parole dovrebbero rispondere in fretta: cos'è questa schermata? Perché dovrei fare qualcosa qui? Cosa devo fare dopo?
Una formula semplice per l'headline è Risultato + oggetto. Nomina il risultato e la cosa che creeranno, non il nome interno della feature.
Per il corpo, usa cosa è + perché conta in una o due frasi:
"I clienti sono le persone a cui vendi. Aggiungine uno ora per poter inviare una fattura e tracciare i pagamenti."
Le CTA dovrebbero iniziare con un verbo chiaro e includere un sostantivo specifico. Evita pulsanti vaghi come “Inizia” quando ci sono più percorsi.
Aggiungi microcopy vicino alla scelta che sembra rischiosa. Piccole rassicurazioni spesso valgono più di spiegazioni lunghe:
Se il tuo prodotto genera output per l'utente (come Koder.ai), fissa aspettative in modo che le persone sappiano che non stanno prendendo una decisione definitiva: “Creeremo una prima bozza. Potrai revisionarla e modificarla prima di distribuire.”
Un buon stato vuoto deve leggere come un segnale, non come un poster. Il layout necessita di un ordine chiaro così le persone possono capire con un colpo d'occhio e agire.
Usa una gerarchia semplice che rispecchia come si scansiona una pagina: titolo, una frase breve, una CTA primaria, poi un'azione secondaria più discreta (importa, template, salta).
Tieni il pulsante primario vicino al messaggio. Se l'utente deve leggere, scrollare e poi decidere, spesso si ferma. Un pattern comune è un blocco compatto (titolo + corpo + CTA), con più spazio bianco tra quel blocco e il resto (navigazione, footer, pannelli laterali).
Icone e piccole illustrazioni possono aiutare la scansione, ma solo se aggiungono senso. Un'icona a cartella vicino a “Nessun progetto” è utile. Una mascotte casuale di solito non lo è. Se usi un'illustrazione, tienila piccola e sopra il titolo in modo che non competa con la CTA.
Uno dei pattern più efficaci è mostrare una piccola anteprima del successo: una scheda di esempio, una riga demo in una tabella o una tessera d'esempio sfumata. In uno strumento come Koder.ai, la schermata vuota “Apps” potrebbe mostrare una tessera app di esempio (nome, stato, ultimo aggiornamento) così l'utente capisce subito cosa sta per creare.
Quando qualcuno arriva su una schermata vuota di solito vuole una di tre cose: partire da zero, portare dati dentro o muoversi velocemente con uno starter. I buoni stati vuoti rendono quei percorsi chiari senza costringere l'utente a studiare il prodotto.
Dai priorità a “Crea” quando la prima vittoria reale è la creazione di una nuova cosa: un progetto, workspace, pagina o primo record. Funziona meglio quando l'utente può finire velocemente e l'azione è reversibile.
Se la creazione richiede tempo, spezzala in un passo iniziale più piccolo (per esempio, “Crea una bozza”) così possono avanzare senza sentirsi bloccati.
Dai priorità a “Importa” quando la maggior parte dei nuovi utenti arriva con un sistema, file o account esistente da collegare. Lo stato vuoto dovrebbe indicare cosa supporta l'import e cosa ottengono dopo (per esempio, campi mappati e elementi creati).
Un modo pratico per scegliere la CTA primaria è usare il contesto. Se l'utente proviene da contenuti di migrazione, evidenzia Importa. Se ha cliccato un pulsante “nuovo progetto” vuoto, evidenzia Crea. Se il setup è complesso, evidenzia Template.
Dai priorità ai template quando il prodotto ha punti di partenza comuni e gli utenti vogliono adattare più che progettare. Nomina i template per risultato (“Pipeline di vendita”, “Pianificatore settimanale”), non per caratteristiche.
Un’opzione “Prova con dati di esempio” riduce la paura. Rendilo chiaro che può essere cancellato. Per un builder chat-first come Koder.ai, un progetto di esempio può mostrare la forma di un'app funzionante prima che l'utente scriva il proprio prompt.
Le schermate vuote non sono neutrali. Le migliori rendono l'azione successiva ovvia, sicura e veloce.
Esempio: se qualcuno apre un CRM nuovo e vede la tab Contatti vuota, la vittoria più veloce è “Aggiungi il tuo primo contatto.” Limitati a nome + email, offri “Importa CSV” come fallback e rassicura che i campi si possono aggiornare dopo.
La maggior parte degli stati vuoti che “bloccano” gli utenti fallisce per una ragione: fanno sembrare il passo successivo rischioso o poco chiaro.
Se mostri tre pulsanti che sembrano ugualmente importanti, gli utenti esitando. Scegli un'azione primaria e una secondaria. Metti tutto il resto dietro un discreto “Altre opzioni”.
“Dashboard potenti, ruoli flessibili, impostazioni avanzate” non dice cosa fare ora. Sostituiscilo con il prossimo risultato che otterranno dopo il clic.
Esempi:
I form lunghi in uno stato vuoto sembrano un impegno. Se hai bisogno di dettagli, guadagnali dopo. Inizia con il passo più piccolo che produce qualcosa di visibile.
Invece di richiedere nome, dimensione azienda, ruolo e obiettivi prima che carichi qualsiasi cosa, chiedi solo “Nome progetto” e rendi il resto opzionale una volta che esiste la prima schermata.
L'umorismo va bene, ma non dove l'utente ha bisogno di chiarezza. “Niente da vedere qui” spreca il momento. Di' esattamente cosa succederà dopo il clic e cosa non succederà.
Alcuni utenti non possono creare da zero. Offri una vera via di riserva: importa, usa un template o prova dati di esempio. Per esempio, se qualcuno usa Koder.ai e non ha un'idea pronta, “Inizia da un'app di esempio” può portarlo a una schermata funzionante senza scrivere una specifica completa.
Un nuovo utente dovrebbe capire cosa è la schermata, perché conta e cosa fare dopo in circa cinque secondi.
La rassicurazione trasforma l'esitazione in azione. Aggiungi una breve nota vicino alla CTA che riduce la paura, come “Puoi modificare questo in seguito” o “Niente viene pubblicato finché non confermi.” Mantienila calma e specifica.
Un test semplice: chiedi a un collega di guardare la schermata per cinque secondi e poi spiegarti cosa pensa succederà se clicca il pulsante principale. Se non riesce a rispondere, stringi copy o gerarchia.
Se stai costruendo flussi di setup in un builder chat-first come Koder.ai, la stessa checklist vale. Lo stato vuoto dovrebbe invitare a una singola azione successiva: partire da un template, importare dati o generare una prima versione modificabile in sicurezza.
Un founder solitario si registra a Koder.ai e apre uno spazio di lavoro nuovo. Arriva su una schermata Progetti con zero app e nessuna idea di cosa sia “buono”.
Invece di una tabella vuota, lo stato mostra una promessa breve, un passo chiaro e una piccola nota di sicurezza. Ecco un esempio di copy e CTA (tratta i tempi stimati come placeholder da validare):
Your workspace is empty.
Create your first app in 5 minutes. Start with a template or describe what you want in plain English.
[Create your first app]
Secondary: Import existing code | Browse templates
Note: You can export the source code anytime.
Dopo che il founder clicca Create your first app, la schermata successiva chiede una sola domanda semplice: “What are you building?” con un singolo campo e 2 prompt di esempio (come “CRM per una piccola agenzia” o “Landing page con signup”). Mantieni il percorso stretto: un campo ovvio, un pulsante ovvio.
La seconda schermata può essere una rapida revisione del piano (funzionalità, pagine, dati), seguita da un passo di build e da un'anteprima funzionante. Il primo momento di successo è quando l'utente può fare una cosa reale in quell'anteprima, come aggiungere un record o inviare una prova di signup.
Una volta che esistono dati, gli utenti che tornano non dovrebbero più vedere lo stesso stato vuoto. La schermata Progetti può trasformarsi in una vista “app recenti” con un'azione rapida prominente (per esempio New app) e azioni più piccole (come Snapshots o Deploy) basate su cosa hanno fatto l'ultima volta.
Per sapere se lo stato vuoto funziona, monitora alcuni numeri:
Scegli un flusso di setup da migliorare questa settimana. Prendi quello con il maggior tasso di abbandono o quello che i nuovi utenti incontrano per primo. Riscrivi il suo stato vuoto in modo che risponda in fretta a tre domande: Che cos'è? Perché farlo adesso? Qual è il prossimo clic?
Mantieni la modifica piccola. Non stai ridisegnando l'onboarding. Stai facendo sembrare ovvia la prima azione di successo.
Un semplice piano settimanale:
Dopo una vittoria, standardizza. Crea un pattern interno breve per gli stati vuoti: spaziatura, stile dei titoli, regole per icone o illustrazioni e un layout coerente delle CTA. Quando i team seguono la stessa struttura, gli utenti la imparano una volta e ovunque procedono più velocemente.
Se stai costruendo una nuova app e vuoi prototipare rapidamente i passi di setup, Koder.ai (koder.ai) può aiutarti a redigere un flusso in Planning Mode e generare la prima versione da testare, poi iterare in base ai punti in cui le persone esitano veramente.
Uno stato vuoto è ciò che l'utente vede quando non c'è ancora nulla da mostrare perché non ha creato, importato o collegato nulla. Dovrebbe spiegare a cosa serve lo schermo e indicare la prossima azione di successo, invece di lasciare l'utente a chiedersi cosa fare.
Una schermata di caricamento dice “aspetta, qualcosa sta succedendo”, e uno stato d'errore dice “qualcosa è andato storto, ecco perché”. Uno stato vuoto per il setup dice “qui non c'è ancora niente, ed è normale” e guida l'utente a creare, importare o partire da un template per raggiungere un primo risultato reale.
Cerca di rispondere velocemente a tre cose: cos'è questa schermata, perché è vuota e cosa fare dopo. Se l'utente non capisce entro pochi secondi, è più probabile che si fermi, pensi di aver sbagliato qualcosa o abbandoni.
Usa una struttura semplice: una breve spiegazione di cosa serve quell'area, un'azione primaria ovvia e una linea di rassicurazione che riduce la paura o lo sforzo. Mantieni il testo sintetico in modo che l'utente non debba leggere un paragrafo per sapere cosa cliccare.
Di norma un solo pulsante primario che corrisponde al passo più comune, e tutto il resto chiaramente secondario. Se mostri più pulsanti pari, le persone spesso si bloccano perché non sanno quale percorso sia “giusto”.
Mostra “Crea” quando partire da zero è il modo più rapido per ottenere un risultato visibile, come un primo progetto o un primo record. Mostra “Importa” quando la maggior parte degli utenti arriva con dati esistenti da collegare, e mostra “Template” quando gli utenti vogliono soprattutto velocità e un punto di partenza già collaudato.
Scrivi i titoli come risultato + oggetto, ad esempio “Crea il tuo primo progetto”, invece di etichette di feature come “Progetti”. Nel testo descrittivo aggiungi una frase che spieghi cosa succede dopo il clic in modo che l'utente possa prevedere il risultato.
Posiziona titolo, una frase breve e il pulsante primario in un blocco compatto con gerarchia visiva chiara. Mantieni le azioni secondarie più discrete e vicine, ed evita di spingere il pulsante principale troppo in basso dove l'utente deve scrollare o cercarlo.
Metti una breve nota di sicurezza vicino all'azione, per esempio “Puoi modificare questo in seguito” o “Niente viene pubblicato finché non confermi”. In strumenti come Koder.ai, può essere utile menzionare azioni reversibili come snapshot/rollback o la possibilità di esportare il codice sorgente una volta iniziato.
Monitora quante volte gli utenti vedono lo stato vuoto, cliccano la CTA primaria e completano la milestone che lo stato deve guidare. Misura anche il tempo per il primo risultato e il tasso di abbandono tra lo stato vuoto e il passo successivo: uno stato vuoto può ottenere click ma comunque non produrre risultati se il flusso dopo non funziona.