Un designer principiante progetta una schermata: la versione "perfetta", con contenuto ideale, utente loggato, tutto caricato. Poi lo sviluppatore la implementa e scopre dopo 2 giorni che il design funziona solo per il 5% degli scenari reali. Mancano tutti gli altri: quando non ci sono dati, quando c'è un errore, quando sta caricando, quando l'utente è offline, quando un'azione è andata a buon fine.
I "stati del design" — design states — sono la risposta metodica a questo problema. Invece di progettare una schermata, progetti tutte le configurazioni possibili di quella schermata, ciascuna con il suo trattamento visivo e il suo messaggio. Questo articolo copre i 5 stati classici codificati da Scott Hurff nel suo libro Designing Products People Love e i 2 stati che quasi tutti dimenticano ma che nel 2026 sono diventati essenziali.
Cosa imparerai leggendo:
- Cosa sono i stati del design e perché sono importanti
- I 5 stati classici: ideal, empty, error, partial, loading
- I 2 stati dimenticati: success/celebrative e offline
- Come progettare ogni stato con esempi
- Come integrarli nel workflow di design
Cosa sono i stati del design
Ogni schermata di qualsiasi prodotto digitale esiste in più stati possibili, a seconda del contesto dell'utente e dei dati disponibili. Una lista di ordini ha uno stato per "nessun ordine", uno per "ordini presenti", uno per "caricamento", uno per "errore di rete", uno per "filtro che non ha risultati". Sono tutte "la stessa schermata" ma visualmente e funzionalmente diverse.
Il design "completo" di una schermata è l'insieme di tutti questi stati. Ignorarne uno significa lasciare un vuoto nel prodotto — uno scenario che, quando accade nella realtà, produce un'esperienza rotta (schermo bianco, messaggio tecnico incomprensibile, caricamento infinito).
Scott Hurff nel 2015 ha codificato i 5 stati principali come la base di un design robusto. Sono diventati una parte standard del vocabolario UX moderno.
1. Ideal State
Lo stato ideale è quello che ogni designer ama: contenuto ricco, utente loggato, tutto caricato, nessun errore. È la schermata perfetta come appare nei mockup per il cliente.
Caratteristiche:
- Tutti i dati disponibili
- Layout visualmente ottimale
- Contenuto in quantità e qualità ideale
Esempio pratico: la timeline di Twitter (X) quando segui 100 persone attive — ci sono sempre nuovi tweet, immagini, interazioni. La schermata "vive" e mostra il prodotto nel suo meglio.
Errore tipico: progettare solo questo stato. Il 70% degli utenti reali non è mai nello stato ideale — sono nuovi, hanno pochi dati, stanno esplorando. Il design deve funzionare anche per loro.
2. Empty State
Lo stato vuoto è la schermata quando non ci sono dati da mostrare. È il caso del nuovo utente che ha appena installato l'app, dell'utente esperto che ha cancellato tutto, del filtro che non produce risultati.
L'empty state è il più sottovalutato dei 5 stati perché nella realtà dei prodotti di consumo rappresenta il primo impatto per la maggior parte degli utenti. Un buon empty state:
- Spiega cosa manca ("Non hai ancora ordini")
- Propone un'azione concreta per uscirne ("Scopri il catalogo →")
- Illustra visivamente il concetto con un'illustrazione o un'icona
- Educa se il prodotto è nuovo per l'utente, mostrando cosa c'è da aspettarsi
Esempio pratico: quando apri Notion per la prima volta, l'empty state ti mostra un template pre-compilato come esempio. Invece di una pagina bianca terrorizzante, vedi subito un esempio di cosa puoi fare.
Casi da gestire separatamente:
- Nuovo utente (mai avuto dati): tono educativo, invito all'onboarding
- Utente esperto (ha cancellato tutto): tono neutro, non paternalistico
- Filtro/ricerca senza risultati: propone di rimuovere filtri o modificare la query
- Errore vs. vuoto legittimo: chiaro distinguere i due casi
3. Error State
Lo stato di errore è quello che si verifica quando qualcosa va storto: server giù, form invalido, risorsa non trovata, azione fallita. È il momento più critico dell'UX perché l'utente si sente tradito.
Un error state fatto bene:
- Dice cosa è successo in linguaggio umano, non tecnico
- Spiega perché è successo (quando utile)
- Propone cosa fare per risolvere (riprova, contatta supporto, torna indietro)
- Non colpevolizza l'utente per errori del sistema
Esempio cattivo: "Error 500: Internal Server Error" Esempio buono: "Qualcosa non ha funzionato dalla nostra parte. I nostri server stanno avendo un problema — ci stiamo lavorando. Riprova tra qualche minuto."
Per errori di form:
- Errore specifico per campo, non generico per la pagina
- Messaggio che dice esattamente cosa correggere
- Visibile accanto al campo, non in cima alla pagina
- Rosso + icona + testo, non solo colore (accessibilità)
Leggi la guida sull'UX login per esempi specifici su form di autenticazione.
4. Partial State
Lo stato parziale è quello in cui alcuni dati ci sono e altri no. È il caso del profilo utente che ha inserito nome ma non foto, del form compilato a metà, dell'app che ha alcuni contenuti ma mancano altri.
È lo stato più frequente nella realtà quotidiana — più comune dello stato ideale — eppure quello meno progettato consapevolmente.
Come progettarlo bene:
- Segnala cosa manca con segnali visivi (badge "profilo incompleto", progress bar)
- Propone di completare con azioni inline ("Aggiungi una foto profilo →")
- Non rompere il layout: la schermata deve funzionare anche con buchi
- Placeholder significativi per le parti mancanti (non semplici vuoti grigi)
Esempio pratico: LinkedIn mostra una progress bar "Profilo al 65%" quando mancano sezioni, con suggerimenti contestuali per completare. Trasforma uno stato parziale in una motivazione all'azione.
5. Loading State
Lo stato di caricamento copre il tempo tra un'azione dell'utente e il risultato visibile. È uno degli elementi più critici per la percezione di velocità di un prodotto.
Principi di un buon loading state:
- Feedback immediato: entro 100ms dal click deve apparire qualcosa (anche solo un cambio di stato del bottone)
- Indicazione di progresso quando possibile (1/5, 2/5, 3/5...)
- Skeleton screen invece di spinner per caricamenti di layout (riduce la percezione di attesa)
- Tempo massimo: sopra i 3-4 secondi serve comunicare attivamente (invece del solo spinner)
- Fallback dopo 10+ secondi: qualcosa è andato storto, passa all'error state
Skeleton screen vs spinner:
Lo spinner è adatto per azioni specifiche e brevi ("invio messaggio..."). Il skeleton screen — una versione grigia della pagina con i riquadri degli elementi ancora da caricare — è molto migliore per caricamento di layout complessi, perché dà immediatamente un senso di struttura. Facebook, LinkedIn, YouTube usano skeleton screen ovunque.
Per approfondire il tema delle animazioni nei loading state leggi la guida alle animazioni UI.
Lo stato dimenticato #1: Success / Celebrative State
Oltre ai 5 classici, c'è uno stato che quasi nessuno progetta esplicitamente: il success state, il momento in cui un'azione è andata a buon fine in modo significativo.
Non tutti i "successi" richiedono celebrazione — un messaggio inviato non merita un'animazione ogni volta. Ma azioni importanti (checkout completato, obiettivo raggiunto, corso finito, achievement sbloccato) sono momenti in cui il prodotto dovrebbe riconoscere il traguardo dell'utente.
Come progettare un success state celebrativo:
- Visivo forte e distintivo: animazione, confetti, grafica, colore brand saturo
- Conferma esplicita: "Ordine confermato", "Pagamento riuscito", "Profilo completato al 100%"
- Prossimo passo suggerito: "Visualizza l'ordine", "Condividi il risultato", "Inizia il prossimo corso"
- Brevità: 2-3 secondi, non 15. La celebrazione non deve bloccare il flusso
Esempio pratico: Duolingo dopo aver completato una lezione mostra un'animazione celebrativa breve con progresso esperienza e streak. Rinforza il comportamento senza rallentare eccessivamente.
Da usare con parsimonia: un success state celebrativo ogni volta che si salva un campo è fastidioso. Riservato ai veri momenti di successo.
Lo stato dimenticato #2: Offline State
Dal 2020, con l'esplosione dei prodotti progressive web e delle app native mobile, l'offline state è diventato essenziale. Gli utenti possono perdere connessione in qualsiasi momento — e il prodotto deve saper reagire.
Come progettare l'offline state:
- Rilevamento automatico: sapere quando l'utente è offline (browser API
navigator.onLine) - Banner persistente: "Sei offline — i tuoi cambiamenti verranno sincronizzati quando torni online"
- Cache intelligente: mostrare i contenuti già scaricati, disabilitare quelli che richiedono rete
- Azioni in coda: permettere all'utente di continuare a lavorare; sincronizzare al ripristino
- Transizione fluida: quando la connessione torna, informare e sincronizzare senza interrompere il flusso
Esempio pratico: Google Docs permette di continuare a scrivere offline, mostra un badge "Modifiche non salvate", e sincronizza automaticamente appena la connessione riappare. L'utente non perde mai il lavoro.
Nei prodotti 2026-ready, l'offline state è parte integrante del design fin dall'inizio, non un aggiunta successiva.
Come integrare i 7 stati nel workflow di design
Tre tecniche per non dimenticare nessuno stato durante il design:
1. Lista di controllo per ogni schermata
Alla fine di ogni schermata progettata, compila una checklist:
- Ideal state
- Empty state
- Error state (rete, server, validazione)
- Partial state
- Loading state (skeleton + actions)
- Success state (se applicabile)
- Offline state (se applicabile)
Se uno stato non è applicabile, annota perché. Mai saltare per distrazione.
2. Frame separato in Figma per ogni stato
Invece di un solo frame "Schermata X", crea una griglia di frame per gli stati. Renderli tutti visibili simultaneamente aiuta a vedere discrepanze visive tra loro e a mantenerli coerenti.
3. Test con utenti degli stati critici
Quando fai usability test, forzati a testare almeno l'empty state (come nuovo utente) e almeno un error state (interrompendo la connessione durante il test). Sono gli stati che nella vita reale fanno la differenza tra un prodotto che regge e uno che crolla al primo imprevisto.
Domande frequenti
Quanti stati devo progettare per ogni schermata?
Il minimo sono i 5 classici (ideal, empty, error, partial, loading). Nei prodotti moderni aggiungi offline e success celebrativo dove rilevante. Alcuni prodotti hanno stati aggiuntivi specifici (es. "modalità manutenzione", "stato bloccato per policy"), da gestire caso per caso.
Posso saltare l'empty state se il mio prodotto "non sarà mai vuoto"?
No. Anche prodotti con contenuti garantiti hanno empty state: filtri che non producono risultati, ricerche senza match, sezioni che l'utente non ha ancora esplorato. Progettare l'empty state come "improbabile" significa scoprire troppo tardi che era frequente.
Skeleton screen o spinner, cosa è meglio?
Lo skeleton screen è migliore per caricamenti di layout complessi (dashboard, liste, pagine con più elementi). Lo spinner è adatto per azioni specifiche brevi (invio form, upload file). Usarli insieme nei rispettivi contesti è la scelta corretta.
Come comunico l'error state agli sviluppatori?
Documenta ogni possibile errore con: messaggio che l'utente vedrà, condizione che lo attiva, comportamento del bottone di recovery. Figma + Notion per la documentazione funziona bene. Gli sviluppatori devono sapere esattamente cosa mostrare in ogni caso.
Gli stati del design riguardano anche le interfacce conversazionali?
Sì, con adattamenti. Un chatbot ha uno stato "sta pensando" (equivalente a loading), uno stato "non ho capito" (error), uno stato "cosa vuoi sapere?" (empty state se nuovo utente). Il principio è universale anche se la manifestazione cambia.
Gli stati del design sono parte del design system?
Sì, i design system maturi includono componenti per ogni stato standard: empty state template, error state template, loading skeleton predefiniti. Questo garantisce coerenza e velocità tra prodotti diversi della stessa azienda.
Prossimi passi
Progettare gli stati è una delle discipline più pratiche del UX Design, quella che più separa i design "da portfolio" da quelli "production-ready". Per approfondire:
- Leggi le animazioni UI che vivono spesso negli stati di transizione
- Studia i principi di usabilità applicabili agli stati di errore
- Approfondisci il wireframe che dovrebbe includere tutti gli stati fin dall'inizio
Nel Corso di Interaction Design di CorsoUX esercitiamo la progettazione sistematica degli stati con casi pratici reali, con feedback dei mentor che verificano la copertura di tutti gli scenari.
