Un pulsante in un mockup di solito mostra uno stato: quello predefinito. Nel prodotto reale lo stesso pulsante viene posizionato con il mouse, focalizzato con una tastiera, premuto, disabilitato mentre un modulo è incompleto e caricato mentre viene inviata una richiesta. Ognuno di questi è uno stato dell'interfaccia utente e ognuno necessita di una progettazione.
Aiuta a separare due gruppi. Gli stati di interazione provengono dall'utente: passaggio del mouse, focus, premuto e disabilitato. Gli stati dei dati provengono dal sistema: caricamento, vuoto, dati parziali, errore e successo. Una schermata di elenco, ad esempio, necessita di un design per quando viene caricata, quando non ha elementi, quando ha un elemento, quando ne ha centinaia e quando la richiesta fallisce.
Gli stati focus meritano un'attenzione speciale. Le persone che utilizzano una tastiera o un dispositivo di commutazione dipendono da un indicatore di messa a fuoco visibile per sapere dove si trovano. La rimozione del contorno del focus del browser senza una sostituzione è uno degli errori di accessibilità più comuni.
Anche il cambiamento tra stati fa parte del progetto. Una breve e chiara transizione da predefinita a premuta conferma il tocco. Uno stato di caricamento che si trasforma facilmente in successo indica alle persone che la loro azione ha funzionato. Salti improvvisi o animazioni troppo lente rendono l'interfaccia inaffidabile.
Un modo pratico per evitare stati mancanti è elencarli per ciascun componente prima della progettazione o modellare il componente come una macchina a stati: un insieme di stati e gli eventi che si muovono tra di essi. ExodeUI, che realizziamo, funziona in questo modo. Progetti ogni stato e le transizioni tra di essi in un unico file e il tuo codice invia gli eventi che cambiano stato nell'app reale.