Benennen Sie für jeden Zustand die Situation, teilen Sie sie auch assistiven Technologien mit, bewahren Sie die eingegebenen Daten und bieten Sie eine sichere Aktion an: warten, wiederholen, bearbeiten oder den Support kontaktieren.
Eine Oberfläche besteht nicht nur aus dem idealen Bildschirm mit vollständigen Daten. Der Nutzer wartet auf das Netzwerk, öffnet ein leeres Konto, verliert eine Berechtigung, gibt eine ungültige Eingabe ein oder stößt auf einen Dienstausfall. Zeigt das System nur einen Spinner, eine leere weiße Fläche oder einen technischen Code, weiß die Person nicht, ob sie warten, es erneut versuchen oder den Support kontaktieren soll.
Ein guter Zustand erklärt, was das System weiß, bewahrt sicher erledigte Arbeit und bietet einen angemessenen nächsten Schritt. Er darf keinen Erfolg versprechen, bevor der Server den Vorgang bestätigt hat, und keine internen Sicherheitsdetails preisgeben. Zustände sollten als Teil der Funktion gestaltet und bei langsamem Netzwerk, wiederholter Anfrage, Sitzungsverlust und mit assistiven Technologien getestet werden.
Das Zustandsmodell entsteht zusammen mit der User Journey
Halten Sie für jeden Bildschirm je nach Relevanz den Anfangs-, Lade-, Leer-, Teil-, Erfolgs-, Fehler-, Offline- und Nicht-berechtigt-Zustand fest. Unterscheiden Sie zwischen Nutzerfehler, Netzwerkproblem, Geschäftsregel und internem Ausfall. Jede Situation braucht einen eigenen Text und einen eigenen Weg zur Wiederherstellung. Ein universelles „Etwas ist schiefgelaufen“ verbirgt die notwendige Entscheidung.
Legen Sie fest, welche Daten erhalten bleiben können, welche Operation sicher wiederholt werden kann und wann Duplikate drohen. Bei einer Zahlung, Bestellung oder dem Absenden eines Formulars muss die Oberfläche einen Fehlschlag von einem unbekannten Ergebnis unterscheiden können. Lässt sich der Status nicht bestätigen, fordern Sie Nutzer nicht unbedacht auf, eine kritische Aktion zu wiederholen.
- Quelle und Art des entstandenen Zustands
- Daten, die erhalten bleiben sollen
- sichere Wiederholbarkeit des Vorgangs
- Verantwortlicher für die technische und inhaltliche Reaktion
Ladevorgänge sollten den Umfang anzeigen und nicht unnötig blockieren
Ein kurzer Vorgang kann lokal am jeweiligen Element angezeigt werden, ein längerer benötigt einen verständlichen Fortschritt oder zumindest die Information, was gerade geladen wird. Ein Spinner ohne Text und ohne Ende zeigt nicht, ob die Anwendung arbeitet. Ein Skeleton sollte dem späteren Layout entsprechen und keine vorgetäuschten Inhalte erzeugen, die sich nach dem Laden stark verschieben.
Sperren Sie nur Bedienelemente, die einen laufenden Vorgang widersprüchlich verändern würden. Ein Button meldet nach der Aktivierung den Status und verhindert ein unbeabsichtigtes doppeltes Absenden, der Rest der Seite kann jedoch nutzbar bleiben. Wird die erwartete Zeit überschritten, bieten Sie eine Erklärung, einen Abbruch oder einen sicheren Retry an. Kündigen Sie die Änderung an, ohne den Screenreader wiederholt zu stören.
Ein leerer Zustand erklärt, warum nichts zu sehen ist
Unterscheiden Sie zwischen einem neuen Konto ohne Daten, einer Suche ohne Ergebnis, einem aktiven Filter ohne Treffer und fehlenden Berechtigungen. Jeder Fall braucht eine andere Meldung. Zeigen Sie neuen Nutzern den ersten sinnvollen Schritt, schlagen Sie bei null Ergebnissen eine Anpassung des Filters vor und erklären Sie bei fehlender Berechtigung, an wen man sich sicher wenden kann.
Füllen Sie einen leeren Bildschirm nicht mit einer generischen Illustration ohne Informationsgehalt. Ein Beispiel kann helfen, den künftigen Inhalt zu verstehen, es muss jedoch klar gekennzeichnet sein und darf nicht wie ein echter Datensatz wirken. Die primäre Aktion sollte auch per Tastatur erreichbar sein, und ihre Bezeichnung sollte aussagen, was sie erstellt oder ändert.
- neues Konto ohne ersten Eintrag
- Filter oder Suche ohne Treffer
- durch unzureichende Berechtigung verborgener Inhalt
- Daten entfernt oder vorübergehend nicht verfügbar
Die Fehlermeldung bietet eine für den Nutzer angemessene Diagnose
Die Meldung sollte die fehlgeschlagene Aufgabe benennen, angeben, was erhalten geblieben ist, und einen möglichen nächsten Schritt aufzeigen. Eine technische Kennung kann dem Support helfen, zeigen Sie sie jedoch getrennt von der verständlichen Erklärung an. Legen Sie keine Stacktraces, Datenbanknamen, Tokens oder Sicherheitsregeln offen. Verraten Sie bei sensiblen Vorgängen nicht, ob ein bestimmtes Konto existiert.
Ist ein Retry sicher, bewahren Sie den Kontext und ermöglichen Sie ihn an derselben Stelle. Bieten Sie bei wiederholtem Fehlschlag eine Alternative und einen Kontakt mit Fallkennung an. Ein Fehler sollte nicht automatisch auf die Startseite weiterleiten und die geleistete Arbeit verwerfen. Verschieben Sie den Fokus oder kündigen Sie den Status je nach Bedeutung an, damit der Nutzer die Änderung versteht.
Erfolg, Offline-Modus und Regressionstests schließen den Zyklus ab
Bestätigen Sie einen Erfolgsstatus erst nach der verbindlichen Antwort des Systems. Geben Sie an, was geschehen ist, wo das Ergebnis zu finden ist und ob ein weiterer Schritt folgt. Ein Toast, der schnell verschwindet, reicht bei einer wichtigen Operation möglicherweise nicht aus. Kennzeichnen Sie im Offline-Modus deutlich lokal gespeicherte Änderungen und den Status ihrer späteren Synchronisierung.
Testen Sie langsame und unterbrochene Verbindungen, Timeouts, Wiederholungen, Zurück-Navigation, Neuladen, doppelte Aktivierung, Sitzungsverlust und nicht verfügbare Abhängigkeiten. Prüfen Sie Tastaturbedienung, Fokus und Screenreader-Ansagen. Protokollieren Sie technische Fehler ohne sensible Eingaben und verknüpfen Sie sie mit einem anonymen Aufgabentyp, damit das Team Ursachen behebt und nicht nur den Text.
- Speicherbestätigung aus der maßgeblichen Quelle
- sichtbares Ergebnis auch nach dem Ausblenden des Toasts
- klarer Status der lokalen und der Serverkopie
- Test der sicheren Wiederholung einer kritischen Aktion
Häufige Fragen
Wie lange darf nur ein Spinner angezeigt werden?
Eine feste Zeit gilt nicht für jede Aufgabe. Erklären Sie bei spürbarer Wartezeit, was gerade passiert, und bieten Sie nach Möglichkeit eine Fortschrittsanzeige, einen Abbruch oder eine sichere Wiederholung an.
Sollte ein Fehler einen technischen Code enthalten?
Sie kann eine sichere Referenzkennung für den Support enthalten. Sie sollte keinen internen Stack-Trace, keine sensiblen Daten und keine technischen Details anzeigen, die dem Nutzer nicht helfen.
Eignet sich ein Toast zur Bestätigung eines Erfolgs?
Bei einer kleinen, umkehrbaren Aktion kann das genügen. Bei Zahlung, Bestellung oder Absenden sollte eine dauerhafte Bestätigung mit dem Ergebnis und dem nächsten Schritt sichtbar bleiben.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
