Stati coerenti di caricamento, errore e vuoto per web e mobile

Perché questi stati si incasinano così in fretta

Gli stati di caricamento, errore e vuoto sono le schermate (o piccoli blocchi UI) che le persone vedono quando l'app sta aspettando, qualcosa è fallito o non c'è nulla da mostrare. Sono normali: le reti sono lente, i permessi vengono negati e gli account nuovi partono da zero dati.

Si incasinano perché di solito vengono aggiunti alla fine e in fretta. I team costruiscono prima il percorso felice, poi aggiungono uno spinner, un messaggio rosso e un segnaposto “nessun elemento” dove l'interfaccia si rompe. Fatto questo su decine di schermate si ottiene una pila di soluzioni una tantum.

L'iterazione veloce peggiora la cosa. Quando l'UI è prodotta rapidamente (inclusa l'UI generata dall'AI), il layout principale può apparire in minuti, ma questi stati sono facili da saltare. Ogni nuova schermata finisce con uno spinner diverso, una formulazione differente (“Riprova” vs “Tentare di nuovo”), e posizioni di pulsanti diverse. La velocità guadagnata all'inizio si trasforma in lavoro di rifinitura prima del lancio.

Stati non corrispondenti confondono gli utenti e costano tempo ai team. Le persone non capiscono se una lista vuota significa “nessun risultato”, “non ancora caricato” o “non hai accesso”. QA deve testare una lunga coda di piccole variazioni e i bug passano perché il comportamento differisce tra web e mobile.

“Incasinato” spesso si manifesta così:

• Il caricamento nasconde le azioni su una schermata ma non su un'altra.
• Gli errori a volte bloccano la pagina, a volte appaiono come testo piccolo.
• Gli stati vuoti usano tono, icone e azioni successive diverse.
• Web e mobile usano etichette diverse per la stessa azione.

L'obiettivo è semplice: un approccio condiviso tra web e mobile. Se il tuo team genera funzionalità velocemente (per esempio usando una piattaforma come Koder.ai), avere uno schema condiviso per gli stati è ancora più importante perché ogni nuova schermata parte coerente per impostazione predefinita.

I 5 tipi di stato da standardizzare per primi

La maggior parte delle app ripete gli stessi punti critici: liste, pagine di dettaglio, form, dashboard. Qui spiccano spinner, banner e messaggi “niente qui”.

Inizia nominando e standardizzando cinque tipi di stato:

• Initial loading: la prima volta che si apre una schermata, prima di avere dati.
• Refreshing / updating: la schermata ha già dati, ma stai recuperando informazioni più recenti.
• Empty baseline: non c'è davvero nulla (account nuovo, workspace nuovo, nessun elemento creato).
• Zero results: i dati esistono, ma filtri o ricerca non restituiscono risultati.
• Error: richieste fallite, permessi che bloccano l'accesso o altro malfunzionamento.

Due casi speciali meritano regole proprie perché si comportano diversamente:

• Offline: mostra contenuti cache quando possibile e indica chiaramente “Sei offline”.
• Slow network: evita flash rapidi di errore; dopo una breve attesa passa a “Ancora in caricamento…” (o simile).

Su schermi e piattaforme, mantieni la struttura coerente: dove appare lo stato, lo stile delle icone, il tono e le azioni di default (Riprova, Aggiorna, Azzera filtri, Crea). Quello che può variare è il contesto: il nome della schermata e una frase che usa le parole dell'utente.

Esempio: se generi sia una lista web che una lista mobile per “Progetti”, dovrebbero condividere lo stesso pattern per zero-results. L'etichetta dell'azione può comunque adattarsi alla piattaforma (“Azzera filtri” vs “Reset”).

Costruisci un piccolo kit di stati invece di soluzioni one-off

Se ogni schermata inventa il proprio spinner, la scheda di errore e il messaggio vuoto, finirai con una dozzina di versioni leggermente diverse. La soluzione più veloce è un piccolo “state kit” che ogni feature possa usare.

Inizia con tre componenti riutilizzabili che funzionino ovunque: Loading, Error e Empty. Rendili volutamente noiosi. Devono essere facili da riconoscere e non competere con l'UI principale.

Rendi i componenti prevedibili definendo un piccolo insieme di input:

• Titolo (breve e specifico)
• Messaggio (una o due frasi)
• Etichetta azione primaria
• Handler azione primaria (riprova, aggiorna o passo successivo)
• Dettagli opzionali (codice errore, azione secondaria)

Poi blocca l'aspetto. Decidi una volta la spaziatura, la tipografia, la dimensione delle icone e lo stile dei pulsanti, e trattalo come regola. Quando la dimensione delle icone e il tipo di pulsante restano gli stessi, gli utenti smettono di notare l'UI di stato e cominciano a fidarsene.

Limita le varianti così il kit non diventi un secondo design system. Tre dimensioni coprono di solito il necessario: small (inline), default (sezione) e full-page (bloccante).

Se generi schermate in Koder.ai, un'istruzione semplice come “use the app StateKit for loading/error/empty with default variant” previene la deriva. Riduce anche il lavoro di pulizia al termine su React web e Flutter mobile.

Scrivi testi per gli stati che restino coerenti

Il copy fa parte del sistema, non è decorazione. Anche quando il layout è coerente, frasi improvvisate fanno sembrare le schermate diverse.

Scegli una voce condivisa: breve, specifica, calma. Spiega cosa è successo in termini semplici, poi indica cosa fare dopo. La maggior parte delle schermate ha bisogno solo di un titolo chiaro, una breve spiegazione e un'azione ovvia.

Usa template così i team smettono di improvvisare

Alcuni schemi di messaggio coprono la maggior parte delle situazioni. Mantienili brevi in modo che entrino negli schermi piccoli:

• Network: “Impossibile connettersi” + “Controlla la connessione e riprova.” + Azione: “Riprova”
• Timeout: “Sta impiegando più tempo del previsto” + “La richiesta è scaduta.” + Azione: “Tenta di nuovo”
• Permission: “Serve un permesso” + “Concedi l'accesso per continuare.” + Azione: “Apri impostazioni”
• Not found: “Niente qui” + “Questo elemento potrebbe essere stato rimosso.” + Azione: “Indietro”
• Validation: “Correggi un campo” + “Inserisci un indirizzo email valido.” + Azione: “Salva”

Evita testi vaghi come “Qualcosa è andato storto” da soli. Se davvero non conosci la causa, dì quello che sai e cosa può fare l'utente adesso. “Non siamo riusciti a caricare i tuoi progetti” è meglio di “Errore”.

Rendi l'azione successiva prevedibile

Stabilisci una regola: ogni errore e stato vuoto offre un passo successivo.

• Se l'utente può recuperare, offri “Riprova” o “Aggiorna”.
• Se lo stato è vuoto a causa dei filtri, suggerisci “Azzera filtri”.
• Se l'utente è bloccato (permesso), indica esattamente dove modificarlo.

Questo è ancora più importante con l'UI generata dall'AI, dove le schermate appaiono in fretta. I template mantengono il copy coerente così non riscrivi dozzine di messaggi one-off durante la rifinitura finale.

Rendi le azioni prevedibili: riprova, aggiorna e passi successivi

Quando le schermate di stato suggeriscono azioni diverse da una pagina all'altra, gli utenti esitano. I team poi finiscono a modificare pulsanti e testi poco prima del lancio.

Decidi quale azione appartiene a ogni stato e mantieni posizione ed etichetta consistenti. La maggior parte delle schermate dovrebbe avere un'azione primaria. Se aggiungi una seconda, dovrebbe supportare il percorso principale, non competere con esso.

Una piccola mappa delle azioni che scala

Mantieni le azioni ammesse ristrette:

• Loading: di solito nessuna azione (opzionale “Annulla” per attività lunghe avviate dall'utente).
• Empty: “Crea” quando l'utente può aggiungere qualcosa; “Modifica filtri” quando i filtri hanno causato il risultato vuoto.
• Error: “Riprova” per errori temporanei; “Aggiorna” per dati obsoleti; “Contatta supporto” solo per flussi bloccati.
• Success with no data change: “Indietro” o “Fatto”.

Pulsanti noiosi sono una caratteristica. Rendono l'UI familiare e aiutano le schermate generate a rimanere coerenti.

Regole per Riprova e dettagli errore

Mostra “Riprova” solo quando il retry ha senso (timeout, rete instabile, 5xx). Aggiungi un breve debounce così tocchi ripetuti non mandino spam di richieste, e passa il pulsante a uno stato di caricamento mentre si riprova.

Dopo ripetuti fallimenti, mantieni lo stesso pulsante primario e migliora l'aiuto secondario (per esempio, un suggerimento “Controlla la connessione” o “Riprova più tardi”). Evita di introdurre nuovi layout solo perché qualcosa è fallito due volte.

Per i dettagli di errore, mostra una ragione chiara su cui l'utente possa agire (“La tua sessione è scaduta. Effettua di nuovo l'accesso.”). Nascondi i dettagli tecnici per impostazione predefinita. Se servono, mettili dietro un'affordance “Dettagli” coerente tra le piattaforme.

Esempio: una lista “Progetti” non riesce a caricare su mobile. Entrambe le piattaforme mostrano la stessa azione primaria “Riprova”, la disabilitano durante il tentativo e dopo due fallimenti aggiungono un piccolo suggerimento sulla connessione invece di cambiare l'intero layout.

Distribuire il sistema senza rallentare i team

Tratta la coerenza degli stati come una piccola modifica di prodotto, non come un redesign. Vai per gradi e rendi l'adozione facile.

Inizia con uno snapshot veloce di quello che hai già. Non puntare alla perfezione. Cattura le variazioni comuni: skeleton vs spinner, errori full-page vs banner, schermate “nessun risultato” con tono diverso.

Un piano di rollout pratico:

• Fai l'inventario di 15–30 schermate chiave su web e mobile e raggruppa i pattern più frequenti.
• Scegli 3–4 posizionamenti canonici da supportare prima (full page, sezione, inline, toast).
• Costruisci componenti corrispondenti per web e mobile che condividano le stesse props e nomi.
• Scrivi regole d'uso brevi così le nuove schermate scelgono dal kit invece di inventarne una nuova.
• Sostituisci un'area prodotto alla volta (ricerca, inbox, fatturazione) così le release restano sicure.

Una volta che i componenti esistono, il vero risparmio di tempo è un set di regole corto che elimina il dibattito: quando uno stato blocca tutta la pagina vs solo una card, e quali azioni devono essere presenti.

Mantieni le regole concise:

• Ogni errore mostra un passo successivo chiaro (riprova, aggiorna, o contatta supporto).
• Gli stati vuoti offrono un'azione primaria (crea, importa, esplora).
• I caricamenti non fanno saltare il layout quando i dati arrivano.

Se usi un generatore di UI come Koder.ai, queste regole ripagano velocemente. Puoi chiedere di “use the state kit components” e ottenere schermate che corrispondono al tuo sistema sia su React web che su Flutter mobile con meno lavoro di pulizia.

Errori comuni che generano lavoro di rifinitura finale

Il lavoro di rifinitura finale capita spesso perché la gestione degli stati è stata sviluppata come soluzioni una tantum. Una schermata “funziona”, ma l'esperienza è diversa ogni volta che qualcosa impiega tempo, fallisce o è senza dati.

Caricamento che sembra bloccato

Gli skeleton aiutano, ma lasciarli troppo a lungo fa pensare che l'app si sia bloccata. Una causa comune è mostrare uno skeleton completo su una chiamata lenta senza indicazione che qualcosa stia ancora avanzando.

Limitane la durata: dopo una breve attesa passa a un messaggio più leggero “Ancora in caricamento…” o mostra il progresso quando possibile.

Deriva del copy tra schermate

I team spesso scrivono un messaggio nuovo ogni volta, anche quando il problema è lo stesso. “Qualcosa è andato storto”, “Impossibile recuperare” e “Errore di rete” possono descrivere un unico caso, ma risultano incoerenti e complicano il supporto.

Scegli un'etichetta per tipo di errore e riutilizzala su web e mobile, con lo stesso tono e livello di dettaglio.

Vuoto vs errore vs non ancora caricato

Un altro errore classico è mostrare lo stato vuoto prima che i dati siano finiti di caricare, o mostrare “Nessun elemento” quando il problema reale è una richiesta fallita. L'utente fa l'azione sbagliata (per esempio aggiungere contenuto quando dovrebbe riprovare).

Rendi esplicito l'ordine di decisione: prima loading, poi error se è fallita, poi empty solo quando sai che la richiesta è riuscita.

Azioni mancanti o sovraccariche

Un errore senza azione di recupero crea dead end. L'opposto è comune: tre pulsanti che competono per attenzione.

Mantienilo essenziale:

• Per gli errori, di default una sola azione primaria (di solito “Riprova”).
• Per gli stati vuoti, una chiara azione successiva.
• Usa azioni secondarie solo quando veramente necessarie.

Mismatch visivi tra piattaforme

Piccole differenze si sommano: stili di icone, padding, forme dei pulsanti. Questo è anche dove l'UI generata dall'AI può deviare se i prompt variano tra schermate.

Blocca spaziatura, set di icone e layout per i componenti di stato così ogni nuova schermata eredita la stessa struttura.

Regole pratiche per comportamento di caricamento e accessibilità

Se vuoi una gestione coerente degli stati tra web e mobile, rendi esplicite le regole “noiose”. La maggior parte dei ritocchi finali avviene perché ogni schermata inventa il proprio comportamento di caricamento, timeout ed etichette.

Regole di caricamento che sembrano veloci (anche quando non lo sono)

Per un caricamento full page scegli una predefinizione: skeleton per schermate con contenuti pesanti (liste, card, dashboard) e uno spinner solo per attese brevi dove il layout è sconosciuto.

Aggiungi una soglia di timeout così l'UI non resta appesa in silenzio. Se il caricamento supera circa 8–10 secondi, passa a un messaggio chiaro e a un'azione visibile come “Riprova”.

Per caricamenti parziali non svuotare lo schermo. Mantieni visibile il contenuto esistente e mostra un piccolo indicatore di progresso vicino alla sezione che si sta aggiornando (per esempio una barra sottile nell'header o uno spinner inline).

Per dati cache, preferisci “stale but usable”. Mostra subito il contenuto cache e aggiungi un sottile indicatore “Aggiornamento in corso” così le persone capiscono perché i dati potrebbero cambiare.

Offline è uno stato a sé. Dillo chiaramente e indica cosa funziona ancora. Esempio: “Sei offline. Puoi visualizzare progetti salvati, ma la sincronizzazione è sospesa.” Offri un solo passo successivo come “Riprova” o “Apri elementi salvati”.

Basi di accessibilità applicabili ovunque

Mantieni queste regole coerenti tra piattaforme:

• Ordine del focus: sposta il focus sul messaggio di stato e sull'azione primaria quando lo stato appare.
• Etichette per screen reader: annuncia caricamenti ed errori con testi chiari e brevi.
• Target touch: rendi i pulsanti facili da toccare su mobile, evita link inline troppo piccoli.
• Movimento: mantieni gli spinner discreti e non fare affidamento solo sull'animazione.
• Colore: non usare mai solo il colore come segnale (associane testo e icone).

Se generi UI con uno strumento come Koder.ai, incorporare queste regole in uno StateKit condiviso aiuta a mantenere ogni nuova schermata coerente di default.

Esempio: una funzione, tre stati, due piattaforme

Immagina un CRM semplice con una schermata Lista Contatti e una schermata Dettaglio Contatto. Se tratti caricamento, errore e vuoto come soluzioni one-off, web e mobile si discosteranno rapidamente. Un piccolo sistema mantiene tutto allineato anche quando l'UI viene prodotta in fretta.

Empty di primo avvio (Lista Contatti): l'utente apre Contatti e non vede nulla. Su web e mobile il titolo resta lo stesso (“Contatti”), il messaggio vuoto spiega perché (“Ancora nessun contatto”) e viene offerta un'unica azione chiara (“Aggiungi il primo contatto”). Se è richiesto un setup (per esempio collegare una casella o importare un CSV), lo stato vuoto indica quel passo esatto.

Caricamento con rete lenta: l'utente apre la pagina Dettaglio Contatto. Entrambe le piattaforme mostrano uno skeleton prevedibile che rispecchia la struttura finale della pagina (header, campi principali, note). Il pulsante indietro funziona ancora, il titolo della pagina è visibile e si evitano spinner casuali in posti diversi.

Errore server: la richiesta di dettaglio fallisce. Lo stesso pattern appare su web e mobile: un titolo breve, una frase, e un'azione primaria (“Riprova”). Se il retry fallisce di nuovo, offrire una seconda opzione come “Torna ai Contatti” così l'utente non resta bloccato.

Ciò che resta coerente è semplice:

• Posizionamento: messaggio nell'area contenuti, azioni in un punto ovvio.
• Copy: stesso tono, stesse etichette dei pulsanti (Riprova, Aggiungi contatto).
• Comportamento: stessi trigger per gli skeleton, stesse regole di retry.
• Sicurezza: disabilita azioni duplicate durante il caricamento.

Checklist rapida prima di spedire

Una release può sembrare “fatta” finché qualcuno non incontra una connessione lenta, un account nuovo o un'API instabile. Questa checklist aiuta a individuare gap dell'ultimo miglio senza trasformare QA in una caccia al tesoro.

Controlli di coerenza UI

Inizia con le liste, perché si moltiplicano. Scegli tre liste comuni (risultati di ricerca, elementi salvati, attività recenti) e verifica che usino tutte la stessa struttura per lo stato vuoto: titolo chiaro, una frase utile e un'azione primaria.

Assicurati che gli stati vuoti non appaiano mentre i dati sono ancora in caricamento. Se mostri “Niente qui” per un istante e poi lo sostituisci con contenuto, la fiducia cala rapidamente.

Controlla gli indicatori di caricamento per coerenza: dimensione, posizione e una durata minima sensata così non tremolano. Se sul web appare uno spinner in cima e su mobile uno skeleton a schermo intero per la stessa schermata, sembra un prodotto diverso.

Errori e controlli QA

Gli errori devono sempre rispondere a “e adesso?” Ogni errore necessita di un passo successivo: riprova, aggiorna, modifica filtri, effettua di nuovo l'accesso o contatta supporto.

Un rapido controllo prima di considerare la build pronta:

• Stati vuoti: stesso layout, stile di icona e tono nelle liste.
• Caricamento: mai sostituito troppo presto da vuoto; indicatori coerenti su web e mobile.
• Errori: un'azione chiara su ogni schermo o toast di errore.
• Regole di copy: wording coerente tra piattaforme (titoli, punteggiatura, verbi dei pulsanti).
• Script QA: una serie breve e ripetibile di passi che innescano stati di loading, empty ed error.

Se usi un builder AI come Koder.ai, questi controlli contano ancora di più perché le schermate si possono generare velocemente, ma la coerenza dipende sempre da un kit condiviso e da regole di copy comuni.

Prossimi passi: mantenere la coerenza man mano che l'app cresce

La coerenza è più facile quando è parte del lavoro quotidiano, non una pulizia una tantum. Ogni nuova schermata dovrebbe usare gli stessi pattern senza che qualcuno debba ricordarsi di “farla combaciare” alla fine.

Rendi il comportamento degli stati parte della definition of done. Una schermata non è completa finché non ha uno stato di caricamento, uno stato vuoto (se pertinente) e uno stato di errore con un'azione chiara.

Tieni le regole leggere, ma scrivile. Un breve documento con qualche screenshot e i pattern di copy esatti è di solito sufficiente. Tratta le nuove varianti come eccezioni. Quando qualcuno propone un nuovo design di stato, chiedi se è davvero un caso nuovo o se rientra nel kit.

Se stai rifattando molte schermate, riduci il rischio facendo a fasi: aggiorna un flusso alla volta, verifica su web e mobile, poi prosegui. In Koder.ai, snapshot e rollback possono rendere i cambi più grandi più sicuri, e la planning mode può aiutare a definire lo StateKit condiviso così le nuove schermate seguono le tue impostazioni predefinite fin dal primo giorno.

Un modo pratico per partire

Scegli un'area questa settimana dove gli stati causano spesso rifiniture finali (spesso ricerca, onboarding o feed di attività). Poi:

• Aggiungi i requisiti di stato alla checklist di acceptance per quell'area.
• Sostituisci gli stati one-off con i componenti condivisi.
• Registra 2–3 esempi (buoni e cattivi) nel documento.
• Fai una rapida revisione cross-platform (stesso significato, stesse azioni, layout simile).
• Monitora quanti ticket di polish UI apri nello sprint successivo e confronta.

Un segno concreto che funziona: meno ticket “piccoli” come “aggiungi riprova”, “lo stato vuoto sembra strano” o “lo spinner blocca la pagina”.

Mantieni chiara la proprietà

Assegna un proprietario per gli standard degli stati (un designer, un tech lead o entrambi). Non devono approvare tutto, ma devono proteggere il kit dall'essere lentamente frammentato in nuove varianti che sembrano simili, si comportano diversamente e costano tempo più avanti.