Lerne ein einfaches System für konsistente Lade-, Fehler- und Leerezustände in Web und Mobile, damit KI‑generierte UI stimmig bleibt und weniger Nachpolitur braucht.
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:
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 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:
Zwei Sonderfälle verdienen eigene Regeln, weil sie sich anders verhalten:
Ü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").
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:
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.
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.
Ein paar Muster decken die meisten Situationen ab. Halte sie kurz, damit sie auf kleinen Bildschirmen passen:
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.“
Setze eine Regel: jeder Fehler‑ und Leerezustand bietet einen nächsten Schritt.
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.
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.
Halte die erlaubten Aktionen eng:
Langweilige Buttons sind ein Feature. Sie machen die UI vertraut und helfen, dass generierte Bildschirme kohärent bleiben.
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.
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:
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:
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.
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.
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.
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.
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.
Ein Fehler ohne Wiederherstellungsaktion schafft Sackgassen. Das Gegenteil ist auch häufig: drei Buttons konkurrieren um Aufmerksamkeit.
Halte es knapp:
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.
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.
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".
Halte diese Regeln über Plattformen hinweg konsistent:
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.
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:
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.
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 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:
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.
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.
Wähle diese Woche einen Bereich, in dem Zustandsprobleme viele späte Fixes verursachen (oft Suche, Onboarding oder ein Aktivitäts‑Feed). Dann:
Ein konkretes Zeichen, dass es funktioniert: weniger „kleine“ Tickets wie „add retry“, „empty state looks weird“ oder „loading spinner blocks the page".
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.
Beginne damit, eine kleine Menge von Zuständen zu benennen, die überall benutzt werden: Initiales Laden, Aktualisieren/Refresh, Basis‑Leerezustand, Null Treffer und Fehler. Füge explizite Regeln für Offline und langsames Netz hinzu, damit sie nicht wie zufällige Fehler behandelt werden. Sobald das Team sich auf Namen und Trigger geeinigt hat, wird die UI über Bildschirme und Plattformen vorhersehbar.
Baue ein kleines StateKit mit drei wiederverwendbaren Bausteinen: Loading, Error und Empty. Lasse jedes Element von denselben Eingaben steuern (Titel, kurze Nachricht, eine primäre Aktion und optionale Details), damit jeder Bildschirm es einfügen kann, ohne neue UI zu erfinden. Mach die Default‑Variante so einfach wie möglich, damit Teams aufhören, Einzellösungen zu erstellen.
Nutze eine einfache Entscheidungsreihenfolge: Zeige Laden, bis die Anfrage fertig ist; zeige Fehler, falls sie fehlgeschlagen ist; und zeige Leerezustand nur nach einer erfolgreichen Antwort ohne Daten. Das verhindert den häufigen Bug, bei dem “Keine Elemente” kurz aufblitzt, bevor Inhalte erscheinen. Es hilft auch QA, weil das Verhalten überall konsistent ist.
Wähle für jeden Zustand eine Standardaktion und verwende dasselbe Label und dieselbe Platzierung über Bildschirme hinweg. Fehler bekommen meistens “Retry”, Basis‑Leerezustände “Create” (oder den nächsten Setup‑Schritt) und Null‑Treffer “Clear filters”. Wenn die primäre Aktion vorhersehbar ist, bewegen sich Nutzer schneller und Teams diskutieren weniger über Button‑Wording.
Schreibe Copy in einer gemeinsamen Vorlage: ein kurzer Titel, der die Situation benennt, ein Satz in klarer Sprache, der erklärt, was los ist, und ein eindeutiger nächster Schritt. Bevorzuge konkrete Formulierungen wie „Wir konnten deine Projekte nicht laden“ statt vager Sätze wie „Etwas ist schiefgelaufen“. Halte den Ton ruhig und konsistent, damit Web und Mobile wie ein Produkt wirken.
Behandle Offline als eigenen Zustand, nicht als generischen Fehler. Zeige gecachte Inhalte, wenn vorhanden, sage klar „You’re offline“ und erkläre, was noch funktioniert. Biete eine einzige nächste Aktion wie „Try again“, damit Nutzer nicht raten müssen.
Vermeide schnelle Error‑Blitze bei langsamen Verbindungen, indem du kurz wartest, bevor du die UI änderst. Wenn das Laden eine Schwelle überschreitet, schalte auf eine deutliche „Still loading…“‑Nachricht um und biete eine sichtbare Aktion wie „Retry“. So wirkt die App reaktiver, auch wenn das Netz langsam ist.
Nutze drei Größenvarianten: klein inline (innerhalb einer Karte oder Sektion), Standard‑Sektion und Vollseiten‑Blocking. Definiere, wann welche Variante erlaubt ist, damit Teams nicht pro Bildschirm improvisieren. Einheitlicher Abstand, Icon‑Stil und Button‑Stil über Varianten hinweg sorgen für ein konsistentes Erlebnis.
Lege ein paar grundlegende Regeln fest: verschiebe den Fokus auf die Nachricht und die primäre Aktion, wenn der Zustand erscheint; spreche Laden und Fehler mit klaren Labels an; mache Buttons auf Mobilgeräten groß genug; verlass dich nicht nur auf Farbe oder Animation. Wenn das Teil des StateKits ist, erben neue Bildschirme diese Regeln automatisch.
Führe es Bereich für Bereich ein, beginnend bei stark frequentierten Listen und Detailbildschirmen. Mach eine Inventur, wähle einige kanonische Platzierungen, und ersetze Einzellösungen durch gemeinsame Komponenten, wenn du jeden Bildschirm anfässt. Wenn du UI in Koder.ai generierst, füge eine dauerhafte Anweisung hinzu, das StateKit standardmäßig zu verwenden, damit neue Bildschirme nicht auseinanderdriften.
