Przycisk w makiecie zwykle pokazuje jeden stan: domyślny. W prawdziwym produkcie ten sam przycisk jest najeżdżany, ustawiany za pomocą klawiatury, wciskany, wyłączany, gdy formularz jest niekompletny i ładowany podczas wysyłania żądania. Każdy z nich jest stanem interfejsu użytkownika i każdy wymaga projektu.
Pomaga oddzielić dwie grupy. Stany interakcji pochodzą od użytkownika: najechanie, skupienie, naciśnięcie i wyłączenie. Stany danych pochodzą z systemu: ładowanie, brak, dane częściowe, błąd i sukces. Na przykład ekran listy wymaga projektu na czas ładowania, gdy nie ma żadnych elementów, gdy ma jeden element, gdy jest ich setki i gdy żądanie kończy się niepowodzeniem.
Na szczególną uwagę zasługują stany skupienia. Osoby korzystające z klawiatury lub urządzenia przełączającego korzystają z widocznego wskaźnika ostrości, aby wiedzieć, gdzie się znajdują. Usunięcie konturu fokusu przeglądarki bez zastąpienia jest jednym z najczęstszych błędów dostępności.
Zmiana między stanami jest również częścią projektu. Krótkie, wyraźne przejście od domyślnego do wciśniętego potwierdza dotknięcie. Stan ładowania, który płynnie przechodzi w sukces, mówi ludziom, że ich działanie zadziałało. Nagłe skoki lub zbyt wolna animacja sprawiają, że interfejs wydaje się zawodny.
Praktycznym sposobem uniknięcia brakujących stanów jest sporządzenie ich listy dla każdego komponentu przed zaprojektowaniem lub modelowanie komponentu jako maszyny stanów: zbioru stanów i zdarzeń, które przemieszczają się między nimi. ExodeUI, który wykonujemy, działa w ten sposób. Projektujesz każdy stan i przejścia między nimi w jednym pliku, a Twój kod wysyła zdarzenia, które przełączają stany w prawdziwej aplikacji.