Eine Schaltfläche in einem Mockup zeigt normalerweise einen Status an: den Standardzustand. Im realen Produkt wird dieselbe Schaltfläche mit der Maus bewegt, mit einer Tastatur fokussiert, gedrückt, deaktiviert, während ein Formular unvollständig ist, und geladen, während eine Anfrage gesendet wird. Jeder davon ist ein UI-Status und jeder benötigt ein Design.
Es hilft, zwei Gruppen zu trennen. Interaktionszustände kommen vom Benutzer: Hover, Fokus, gedrückt und deaktiviert. Datenzustände kommen vom System: Laden, leer, Teildaten, Fehler und Erfolg. Ein Listenbildschirm benötigt beispielsweise ein Design dafür, wann er geladen wird, wenn er keine Elemente enthält, wenn er ein Element enthält, wenn er Hunderte enthält und wenn die Anfrage fehlschlägt.
Fokuszustände verdienen besondere Aufmerksamkeit. Personen, die eine Tastatur oder ein Switch-Gerät verwenden, sind auf eine sichtbare Fokusanzeige angewiesen, um zu wissen, wo sie sich befinden. Das ersatzlose Entfernen des Browser-Fokus-Umrisses ist einer der häufigsten Fehler bei der Barrierefreiheit.
Auch der Wechsel zwischen den Zuständen ist Teil des Designs. Ein kurzer, deutlicher Übergang von „Standard“ zu „Gedrückt“ bestätigt das Tippen. Ein Ladezustand, der reibungslos in Erfolg übergeht, zeigt den Menschen, dass ihre Aktion funktioniert hat. Abrupte Sprünge oder zu langsame Animationen führen dazu, dass sich die Benutzeroberfläche unzuverlässig anfühlt.
Eine praktische Möglichkeit, fehlende Zustände zu vermeiden, besteht darin, sie vor dem Entwurf für jede Komponente aufzulisten oder die Komponente als Zustandsmaschine zu modellieren: eine Reihe von Zuständen und die Ereignisse, die sich zwischen ihnen bewegen. ExodeUI, das wir herstellen, funktioniert auf diese Weise. Sie entwerfen jeden Zustand und die Übergänge zwischen ihnen in einer Datei, und Ihr Code sendet die Ereignisse, die den Zustand in der echten App wechseln.