Konsistente Lade-, Fehler- und Leerezustände für Web und Mobile

Warum diese Zustände so schnell unordentlich werden

Lade-, Fehler- und Leerezustände sind die Bildschirme (oder kleinen UI‑Blöcke), die Menschen sehen, wenn die App wartet, etwas fehlgeschlagen ist oder einfach nichts angezeigt werden kann. Sie sind normal: Netzwerke sind langsam, Berechtigungen werden verweigert und neue Konten starten mit null Daten.

Sie werden unordentlich, weil sie meist spät und schnell ergänzt werden. Teams bauen zuerst den Happy‑Path und fügen dann überall Spinner, eine rote Fehlermeldung und einen „keine Elemente“-Platzhalter ein, wo die UI bricht. Macht man das über Dutzende Bildschirme, entsteht ein Haufen Einzellösungen.

Schnelles Iterieren verschlimmert das. Wenn UI schnell entsteht (einschließlich KI‑generierter UI), steht das Hauptlayout oft in Minuten — aber diese Zustände lassen sich leicht überspringen. Jeder neue Bildschirm bekommt einen anderen Spinner‑Stil, andere Formulierungen („Try again“ vs. „Retry“) und andere Button‑Platzierungen. Die anfängliche Geschwindigkeit verwandelt sich in Polierarbeit kurz vor dem Launch.

Nicht übereinstimmende Zustände verwirren Nutzer und kosten Teams Zeit. Menschen können nicht unterscheiden, ob eine leere Liste „keine Ergebnisse“, „noch nicht geladen“ oder „kein Zugriff“ bedeutet. QA muss eine lange Reihe winziger Variationen testen, und Fehler schleichen sich ein, weil Verhalten zwischen Web und Mobile unterschiedlich ist.

„Unordentlich“ sieht oft so aus:

• Laden verbirgt Aktionen auf dem einen Bildschirm, aber nicht auf dem anderen.
• Fehler blockieren manchmal die Seite, erscheinen manchmal als kleiner Text.
• Leerezustände nutzen unterschiedlichen Ton, Icons und nächste Schritte.
• Web und Mobile verwenden verschiedene Labels für dieselbe Aktion.

Das Ziel ist einfach: ein gemeinsamer Ansatz für Web und Mobile. Wenn dein Team Features schnell erzeugt (zum Beispiel mit einer Plattform wie Koder.ai), ist ein gemeinsames State‑Pattern noch wichtiger, weil jeder neue Bildschirm dann standardmäßig kohärent beginnt.

Die 5 Zustandsarten, die sich zuerst standardisieren lohnen

Die meisten Apps wiederholen dieselben Druckpunkte: Listen, Detailseiten, Formulare, Dashboards. Hier vervielfältigen sich Spinner, Banner und „nichts hier“-Meldungen.

Beginne damit, fünf Zustandsarten zu benennen und zu standardisieren:

• Initial loading: das erste Öffnen eines Bildschirms, bevor Daten vorliegen.
• Refreshing / updating: der Bildschirm hat bereits Daten, aber du holst neuere Daten.
• Empty baseline: es gibt tatsächlich noch nichts (neues Konto, neuer Workspace, keine erstellten Elemente).
• Zero results: Daten existieren, aber Filter oder Suche liefern nichts.
• Error: Anfragen schlagen fehl, Berechtigungen blockieren den Zugriff oder etwas bricht.

Zwei Sonderfälle verdienen eigene Regeln, weil sie sich anders verhalten:

• Offline: Zeige gecachte Inhalte, wenn möglich, und sage klar „You’re offline“.
• Slow network: Vermeide schnelle Error‑Blitze; nach kurzer Verzögerung auf „Still loading…“ (oder ähnlich) wechseln.

Über Bildschirme und Plattformen hinweg sollte die Struktur konsistent bleiben: wo der Zustand erscheint, Icon‑Stil, Ton und die Standardaktionen (Retry, Refresh, Clear filters, Create). Variieren darf der Kontext: der Bildschirmname und ein Satz, der die Worte des Nutzers verwendet.

Beispiel: Wenn du sowohl eine Web‑Liste als auch eine Mobile‑Liste für „Projects“ erzeugst, sollten sie dasselbe Null‑Ergebnis‑Pattern teilen. Das Aktionslabel kann weiterhin zur Plattform passen („Clear filters“ vs. „Reset").

Baue ein kleines StateKit statt Einzellösungen

Wenn jeder Bildschirm seinen eigenen Spinner, Fehler‑Card und leere Nachricht erfindet, endest du mit einem Dutzend leicht unterschiedlicher Versionen. Die schnellste Lösung ist ein kleines „StateKit“, das jede Funktion einsetzen kann.

Beginne mit drei wiederverwendbaren Komponenten, die überall funktionieren: Loading, Error und Empty. Halte sie absichtlich unspektakulär. Sie sollen leicht erkennbar sein und nicht mit der Haupt‑UI konkurrieren.

Mach die Komponenten vorhersehbar, indem du eine kleine Menge an Eingaben definierst:

• Title (kurz und spezifisch)
• Message (ein oder zwei Sätze)
• Primary action label
• Primary action handler (retry, refresh oder nächster Schritt)
• Optionale Details (Fehlercode, sekundäre Aktion)

Dann fixiere das Aussehen. Entscheide einmal über Abstände, Typografie, Icon‑Größe und Button‑Stil und behandle es als Regel. Wenn Icon‑Größe und Button‑Typ gleich bleiben, hören Nutzer auf, die Zustands‑UI wahrzunehmen, und fangen an, ihr zu vertrauen.

Behalte Varianten begrenzt, damit das Kit nicht zu einem zweiten Designsystem wird. Drei Größen decken normalerweise alles ab: klein (inline), default (Sektion) und Vollseite (blocking).

Wenn du Bildschirme in Koder.ai generierst, verhindert eine einfache Anweisung wie „use the app StateKit for loading/error/empty with default variant“, dass Zustände auseinanderdriften. Es reduziert auch späte Aufräumarbeit für React Web und Flutter Mobile.

Schreibe Zustands‑Texte, die konsistent bleiben

Copy ist Teil des Systems, nicht Dekoration. Selbst wenn das Layout konsistent ist, wirken improvisierte Formulierungen wie Playdough: jede Seite fühlt sich anders an.

Wähle eine gemeinsame Stimme: kurz, spezifisch, ruhig. Sage, was passiert ist, in einfachen Worten, und sag dem Nutzer, was als Nächstes zu tun ist. Die meisten Bildschirme brauchen nur einen klaren Titel, eine kurze Erklärung und eine offensichtliche Aktion.

Verwende Vorlagen, damit Teams aufhören zu improvisieren

Ein paar Muster decken die meisten Situationen ab. Halte sie kurz, damit sie auf kleinen Bildschirmen passen:

• Netzwerk: „Can’t connect“ + „Check your internet and try again.“ + Aktion: „Retry"
• Timeout: „Taking longer than expected“ + „The request timed out.“ + Aktion: „Try again"
• Berechtigung: „Permission needed“ + „Allow access to continue.“ + Aktion: „Open settings"
• Nicht gefunden: „Nothing here“ + „This item may have been removed.“ + Aktion: „Back"
• Validierung: „Fix one thing“ + „Add a valid email address.“ + Aktion: „Save"

Vermeide vage Texte wie „Something went wrong“ allein. Wenn du die Ursache wirklich nicht kennst, sage, was du weißt, und was der Nutzer jetzt tun kann. „We couldn’t load your projects“ ist besser als „Error.“

Mach die nächste Aktion vorhersehbar

Setze eine Regel: jeder Fehler‑ und Leerezustand bietet einen nächsten Schritt.

• Wenn der Nutzer sich erholen kann, biete „Retry“ oder „Refresh“ an.
• Wenn der Zustand leer aufgrund von Filtern ist, schlage „Clear filters“ vor.
• Wenn der Nutzer blockiert ist (Berechtigung), sag ihm genau, wo er das ändern kann.

Das ist bei KI‑generierter UI besonders wichtig, wo Bildschirme schnell erscheinen. Vorlagen halten die Copy konsistent, sodass du nicht Dutzende einzelner Nachrichten in der Schlussphase umschreiben musst.

Mach Aktionen vorhersehbar: Retry, Refresh und nächste Schritte

Wenn Zustandsbildschirme unterschiedliche Aktionen vorschlagen, zögern Nutzer. Teams enden dann damit, Buttons und Copy kurz vor dem Launch zu ändern.

Entscheide, welche Aktion zu jedem Zustand gehört, und halte Platzierung und Label konsistent. Die meisten Bildschirme sollten eine primäre Aktion haben. Wenn du eine zweite hinzufügst, sollte sie den Hauptpfad unterstützen, nicht konkurrieren.

Eine kleine Aktionskarte, die skaliert

Halte die erlaubten Aktionen eng:

• Loading: normalerweise keine Aktion (optional „Cancel“ für lange, vom Nutzer gestartete Tasks).
• Empty: „Create“, wenn der Nutzer etwas hinzufügen kann; „Adjust filters“, wenn Filter das leere Ergebnis verursachen.
• Error: „Retry“ für temporäre Fehler; „Refresh“ für veraltete Daten; „Contact support“ nur für blockierte Workflows.
• Success with no data change: „Back“ oder „Done."

Langweilige Buttons sind ein Feature. Sie machen die UI vertraut und helfen, dass generierte Bildschirme kohärent bleiben.

Regeln für Retry und Fehlerdetails

Zeige „Retry“ nur, wenn ein erneuter Versuch realistisch helfen kann (Timeouts, instabiles Netz, 5xx). Füge ein kurzes Debounce hinzu, damit wiederholte Taps keine Anfragen spammen, und wechsle den Button in einen Ladezustand während des Retries.

Nach wiederholtem Fehlschlag behalte den gleichen primären Button bei und verbessere die sekundäre Hilfe (zum Beispiel einen „Check connection“‑Tipp oder „Try again later“). Vermeide, nur weil etwas zweimal fehlgeschlagen ist, ein neues Layout einzuführen.

Bei Fehlerdetails zeige einen klaren Grund, mit dem Nutzer etwas anfangen können („Deine Sitzung ist abgelaufen. Bitte melde dich erneut an.“). Verstecke technische Details standardmäßig. Wenn du sie brauchst, verstaue sie hinter einer einheitlichen „Details“‑Affordance über Plattformen hinweg.

Beispiel: Eine „Projects“‑Liste lädt auf dem Handy nicht. Beide Plattformen zeigen dieselbe primäre „Retry“‑Aktion, deaktivieren sie während des Retries und fügen nach zwei Fehlern einen kleinen Verbindungs‑Hinweis hinzu, statt das gesamte Button‑Layout zu ändern.

Rolle das System aus, ohne Teams zu verlangsamen

Behandle Zustandskonsistenz wie eine kleine Produktänderung, nicht wie ein Redesign. Geh inkrementell vor und mache die Einführung einfach.

Beginne mit einer schnellen Bestandsaufnahme dessen, was du schon hast. Ziel ist nicht Perfektion. Erfasse die häufigen Varianten: Spinner vs. Skeletons, Vollseiten‑Fehler vs. Banner, „no results“‑Screens mit unterschiedlichem Ton.

Ein praktischer Rollout‑Plan:

• Inventory 15 bis 30 Schlüsselbildschirme über Web und Mobile und gruppiere die Muster, die du am häufigsten siehst.
• Wähle 3 bis 4 kanonische Platzierungen, die du zuerst unterstützen wirst (Vollseite, Sektion, Inline, Toast).
• Baue passende Komponenten für Web und Mobile, die dieselben Props und Namen teilen.
• Schreibe kurze Nutzungsregeln, damit neue Bildschirme aus dem Kit wählen statt eine neue Version zu erfinden.
• Ersetze einen Produktbereich nach dem anderen (Suche, Inbox, Billing), damit Releases sicher bleiben.

Sobald die Komponenten existieren, ist der eigentliche Zeitgewinn eine kurze Regelmenge, die Debatten entfernt: wann ein Zustand die ganze Seite blockiert vs. nur eine Karte, und welche Aktionen vorhanden sein müssen.

Halte die Regeln kurz:

• Jeder Fehler zeigt einen klaren nächsten Schritt (retry, refresh oder contact support).
• Leerezustände bieten eine primäre Aktion (create, import oder explore).
• Ladezustände springen nicht im Layout, wenn Daten eintreffen.

Wenn du einen AI UI‑Generator wie Koder.ai nutzt, rechnen sich diese Regeln schnell. Du kannst danach fragen „use the state kit components“ und bekommst Bildschirme, die dein System sowohl auf React Web als auch auf Flutter Mobile mit weniger Nacharbeit matchen.

Häufige Fehler, die späte Polierarbeit erzeugen

Späte Polierarbeit entsteht meist, weil Zustandsbehandlung als Einzellösungen gebaut wurde. Ein Bildschirm „funktioniert“, aber das Erlebnis fühlt sich jedes Mal anders an, wenn etwas Zeit braucht, fehlschlägt oder keine Daten vorliegen.

Laden, das sich festgefahren anfühlt

Skeletons helfen, aber sie zu lange stehen zu lassen, lässt Leute denken, die App sei eingefroren. Ein häufiger Grund ist, ein volles Skeleton bei einem langsamen Call zu zeigen, ohne Zeichen, dass sich etwas bewegt.

Zeitlich begrenzen: nach kurzer Verzögerung in eine leichtere „Still loading…“‑Nachricht wechseln oder Fortschritt anzeigen, wenn möglich.

Copy‑Drift über Bildschirme

Teams schreiben oft jedes Mal eine neue Nachricht, selbst wenn das Problem gleich ist. „Something went wrong“, „Unable to fetch“ und „Network error“ können denselben Fall beschreiben, wirken aber inkonsistent und machen Support schwerer.

Wähle ein Label pro Fehlertyp und verwende es auf Web und Mobile mit demselben Ton und Detaillierungsgrad.

Leere vs. Fehler vs. noch nicht geladen

Ein klassischer Fehler ist, einen Leerezustand zu zeigen, bevor Daten fertig geladen sind, oder „No items“ zu zeigen, wenn eigentlich die Anfrage fehlgeschlagen ist. Der Nutzer unternimmt die falsche Aktion (z. B. Inhalte hinzufügen, obwohl er retryen sollte).

Mache die Entscheidungsreihenfolge explizit: zuerst Loading, dann Error, und nur wenn die Anfrage erfolgreich war, Empty.

Fehlende oder überfrachtete Aktionen

Ein Fehler ohne Wiederherstellungsaktion schafft Sackgassen. Das Gegenteil ist auch häufig: drei Buttons konkurrieren um Aufmerksamkeit.

Halte es knapp:

• Bei Fehlern: eine primäre Aktion (meist „Retry").
• Bei Leerezuständen: ein klarer nächster Schritt.
• Sekundäre Aktionen nur, wenn wirklich nötig.

Visuelle Unstimmigkeiten zwischen Plattformen

Kleine Unterschiede summieren sich: Icon‑Stile, Padding, Button‑Formen. Das ist auch der Punkt, an dem KI‑generierte UI abweichen kann, wenn Prompts pro Bildschirm variieren.

Sperre Abstand, Icon‑Set und Layout für Zustandskomponenten, damit jeder neue Bildschirm dieselbe Struktur erbt.

Praktische Regeln für Ladeverhalten und Barrierefreiheit

Wenn du konsistente Zustandsbehandlung über Web und Mobile willst, mache die „langweiligen“ Regeln explizit. Die meisten späten Polierarbeiten passieren, weil jeder Bildschirm sein eigenes Ladeverhalten, Timeouts und Labels erfindet.

Lade‑Regeln, die schnell wirken (auch wenn sie es nicht sind)

Für Vollseiten‑Laden wähle eins als Default: Skeletons für inhaltsreiche Bildschirme (Listen, Karten, Dashboards) und einen Spinner nur für kurze Wartezeiten, in denen das Layout noch unbekannt ist.

Füge eine Timeout‑Schwelle hinzu, damit die UI nicht lautlos hängt. Dauert das Laden länger als etwa 8–10 Sekunden, schalte auf eine klare Nachricht und eine sichtbare Aktion wie „Retry“ um.

Bei Teil‑Laden: blende den Screen nicht aus. Lass vorhandene Inhalte sichtbar und zeige einen kleinen Fortschrittsanzeiger in der Nähe der Sektion, die aktualisiert wird (z. B. eine dünne Leiste im Header oder ein Inline‑Spinner).

Bei gecachten Daten bevorzuge „stale but usable“. Zeige gecachte Inhalte sofort und füge einen dezenten „Refreshing…“‑Hinweis hinzu, damit Leute verstehen, warum sich Daten ändern können.

Offline ist ein eigener Zustand. Sage es klar und was noch funktioniert. Beispiel: „You’re offline. You can view saved projects, but syncing is paused." Biete eine einzige nächste Aktion wie „Try again" oder „Open saved items".

Barrierefreiheits‑Basics, die du überall anwenden kannst

Halte diese Regeln über Plattformen hinweg konsistent:

• Fokusreihenfolge: Verschiebe den Fokus auf die Zustandsnachricht und die primäre Aktion, wenn der Zustand erscheint.
• Screenreader‑Labels: Mache Laden und Fehler mit klaren, kurzen Texten hörbar.
• Tap‑Ziele: Buttons auf Mobilgeräten groß genug machen, keine winzigen Inline‑Links.
• Bewegung: Spinner zurückhaltend verwenden und nicht allein auf Animation setzen.
• Farbe: Verwende Farbe nie als einziges Signal (kombiniere mit Text und Icons).

Wenn du UI mit einem Tool wie Koder.ai generierst, hilft es, diese Regeln in ein geteiltes StateKit zu integrieren, damit jeder neue Bildschirm standardmäßig konsistent ist.

Beispiel: eine Funktion, drei Zustände, zwei Plattformen

Stell dir ein einfaches CRM mit einer Kontakte‑Liste und einer Kontakt‑Detailseite vor. Behandelst du Laden, Fehler und Leerezustände als Einzellösungen, driften Web und Mobile schnell auseinander. Ein kleines System hält alles in Einklang, auch wenn UI schnell entsteht.

Erstmaliger Leerezustand (Kontakte‑Liste): Der Nutzer öffnet Kontakte und sieht noch nichts. Auf Web und Mobile bleibt der Titel gleich („Contacts“), die Leermeldung erklärt warum („No contacts yet“) und ein klarer nächster Schritt wird angeboten („Add your first contact"). Wenn ein Setup nötig ist (Inbox verbinden oder CSV importieren), verweist der Leerezustand genau auf diesen Schritt.

Langsame Netzwerkverbindung: Der Nutzer öffnet eine Kontakt‑Detailseite. Beide Plattformen zeigen ein vorhersehbares Skeleton‑Layout, das der finalen Seitenstruktur entspricht (Header, wichtige Felder, Notizen). Die Zurück‑Taste funktioniert weiterhin, der Seitentitel ist sichtbar und du vermeidest zufällige Spinner an verschiedenen Stellen.

Serverfehler: Die Detailanfrage schlägt fehl. Dasselbe Muster erscheint auf Web und Mobile: kurze Headline, ein Satz und eine primäre Aktion („Retry"). Scheitert Retry erneut, biete eine zweite Option wie „Go back to Contacts“, damit der Nutzer nicht festhängt.

Was konsistent bleibt, ist einfach:

• Platzierung: Nachricht im Inhaltsbereich, Aktionen an einer offensichtlichen Stelle.
• Copy: ein Ton, gleiche Button‑Labels (Retry, Add contact).
• Verhalten: gleiche Trigger für Skeletons, gleiche Retry‑Regeln.
• Sicherheit: doppelte Aktionen während des Ladens deaktivieren.

Schnelle Checkliste vor dem Release

Ein Release kann „fertig“ wirken, bis jemand eine langsame Verbindung, ein frisches Konto oder eine flaky API trifft. Diese Checkliste hilft, letzte Lücken zu finden, ohne QA in eine Schatzsuche zu verwandeln.

UI‑Konsistenzprüfungen

Beginne mit Listenscreens, weil sie sich vervielfältigen. Wähle drei gängige Listen (Suchergebnisse, gespeicherte Elemente, letzte Aktivitäten) und verifiziere, dass alle dieselbe Leerezustands‑Struktur nutzen: klarer Titel, ein hilfreicher Satz und eine primäre Aktion.

Stelle sicher, dass Leerezustände nie erscheinen, während Daten noch geladen werden. Wenn du kurz „Nothing here yet" zeigst und dann Inhalte nachlädst, sinkt das Vertrauen schnell.

Prüfe Ladeindikatoren auf Konsistenz: Größe, Platzierung und eine sinnvolle Mindestdauer, damit sie nicht flackern. Wenn Web oben einen Balken‑Spinner zeigt, Mobile aber ein Vollseiten‑Skeleton für denselben Screen, wirkt es wie zwei Produkte.

Fehler‑ und QA‑Checks

Fehler sollten immer beantworten: „Was jetzt?“ Jeder Fehler braucht einen nächsten Schritt: retry, refresh, Filter ändern, erneut anmelden oder Support kontaktieren.

Ein kurzer Check, bevor der Build als fertig gilt:

• Leerezustände: gleiche Layouts, Icon‑Stil und Ton über Listenscreens.
• Laden: nie zu früh durch Leere ersetzen; Indikatoren stimmen über Plattformen überein.
• Fehler: eine klare nächste Aktion in jedem Fehlerbildschirm oder Toast.
• Copy‑Regeln: konsistente Wortwahl über Plattformen (Titel, Interpunktion, Verbformen auf Buttons).
• QA‑Skript: ein kurzer, wiederholbarer Satz von Schritten, der Laden, Leere und Fehler auslöst.

Wenn du einen AI‑Builder wie Koder.ai nutzt, sind diese Checks besonders wichtig, weil Bildschirme schnell generiert werden können, aber Konsistenz weiterhin vom geteilten Kit und Copy‑Regeln abhängt.

Nächste Schritte: Konsistenz erhalten, während die App wächst

Konsistenz ist am einfachsten, wenn sie Teil der täglichen Arbeit ist, nicht ein einmaliges Aufräumen. Jeder neue Bildschirm sollte dieselben Muster nutzen, ohne dass jemand sich daran erinnern muss „mach es gleich".

Mach Zustandsverhalten Teil der Definition of Done. Ein Bildschirm ist nicht fertig, bis er einen Ladezustand, einen Leerezustand (wenn zutreffend) und einen Fehlerzustand mit einer klaren Aktion hat.

Halte die Regeln leichtgewichtig, aber schriftlich. Ein kurzes Dokument mit ein paar Screenshots und den genauen gewünschten Copy‑Mustern reicht meist. Behandle neue Varianten als Ausnahmen. Wenn jemand ein neues State‑Design vorschlägt, frage, ob es wirklich ein neuer Fall ist oder ob es ins Kit passt.

Wenn du viele Bildschirme refaktorieren musst, reduziere Risiko mit kontrollierten Schritten: einen Flow nach dem anderen aktualisieren, auf Web und Mobile prüfen und dann weitermachen. In Koder.ai können Snapshots und Rollback größere Änderungen sicherer machen; der Planning Mode hilft, das StateKit zu definieren, damit neu generierte Bildschirme deine Defaults von Anfang an nutzen.

Ein praktischer Weg zur Umsetzung

Wähle diese Woche einen Bereich, in dem Zustandsprobleme viele späte Fixes verursachen (oft Suche, Onboarding oder ein Aktivitäts‑Feed). Dann:

• Füge State‑Anforderungen zur Akzeptanzcheckliste für diesen Bereich hinzu.
• Ersetze Einzellösungen durch deine geteilten Komponenten.
• Dokumentiere 2–3 Beispiele (gut und schlecht).
• Mache eine kurze plattformübergreifende Überprüfung (gleiche Bedeutung, gleiche Aktionen, ähnliches Layout).
• Messe, wie viele UI‑Polier‑Tickets du im nächsten Sprint erstellst und vergleiche.

Ein konkretes Zeichen, dass es funktioniert: weniger „kleine“ Tickets wie „add retry“, „empty state looks weird“ oder „loading spinner blocks the page".

Eigentum klar halten

Bestimme einen einzelnen Eigentümer für State‑Standards (Designer, Tech‑Lead oder beides). Sie müssen nicht jede Entscheidung genehmigen, sollten aber das Kit davor schützen, langsam in neue, leicht unterschiedliche Varianten zu splitten, die später Zeit kosten.