25 sep 2025·7 min
Consistente laad-, fout- en lege toestanden op web en mobiel
Leer een eenvoudig systeem voor consistente laad-, fout- en lege toestanden op web en mobiel, zodat AI-gegenereerde UI coherent blijft en minder late polish nodig heeft.
Leer een eenvoudig systeem voor consistente laad-, fout- en lege toestanden op web en mobiel, zodat AI-gegenereerde UI coherent blijft en minder late polish nodig heeft.
Laad-, fout- en lege staten zijn de schermen (of kleine UI-blokken) die mensen zien als de app wacht, iets is mislukt of er gewoon niets te tonen is. Ze zijn normaal: netwerken zijn traag, permissies worden geweigerd en nieuwe accounts starten met nul data.
Het wordt rommelig omdat ze meestal laat en snel worden toegevoegd. Teams bouwen eerst het gelukkige pad en plakken dan ergens een spinner, een rode melding en een “geen items” placeholder wanneer de UI breekt. Doe dat over tientallen schermen en je krijgt een stapel losse oplossingen.
Snelle iteratie maakt het erger. Wanneer UI snel wordt gemaakt (ook AI-genereerde UI), kan de hoofdlay-out in minuten klaar zijn, maar deze staten zijn gemakkelijk over te slaan. Elk nieuw scherm krijgt een andere spinnerstijl, andere bewoordingen (“Probeer het opnieuw” vs “Retry”) en andere knopplaatsing. De snelheid die je aanvankelijk won, verandert in polishwerk vlak voor lancering.
Mismatchende staten verwarren gebruikers en kosten teams tijd. Mensen kunnen niet zien of een lege lijst “geen resultaten” betekent, “nog niet geladen” of “je hebt geen toegang”. QA moet een lange staart van kleine variaties testen en bugs glippen door omdat het gedrag verschilt tussen web en mobiel.
“Rommelig” ziet er vaak zo uit:
Het doel is simpel: één gedeelde aanpak voor web en mobiel. Als je team snel features genereert (bijvoorbeeld met een platform zoals Koder.ai), is een gedeeld state-patroon nog belangrijker omdat elk nieuw scherm standaard coherent begint.
De meeste apps herhalen dezelfde pijnpunten: lijsten, detailpagina's, formulieren, dashboards. Daar vermenigvuldigen spinners, banners en “niets hier” berichten zich.
Begin met het benoemen en standaardiseren van vijf statustypen:
Twee speciale gevallen verdienen eigen regels omdat ze zich anders gedragen:
Over schermen en platforms, houd de structuur consistent: waar de staat verschijnt, het pictogram-stijl, de toon en de standaardacties (Retry, Refresh, Clear filters, Create). Wat kan variëren is de context: de schermnaam en een zin die de woorden van de gebruiker gebruikt.
Voorbeeld: als je zowel een weblijst als een mobiele lijst genereert voor “Projects”, moeten ze hetzelfde zero-results-patroon delen. Het actielabel kan nog steeds bij het platform passen (“Clear filters” vs “Reset”).
Als elk scherm zijn eigen spinner, error-kaart en lege boodschap uitvindt, eindig je met een dozijn licht verschillende versies. De snelste oplossing is een kleine “state kit” die elk feature kan gebruiken.
Begin met drie herbruikbare componenten die overal werken: Loading, Error en Empty. Houd ze expres saai. Ze moeten makkelijk te herkennen zijn en niet concurreren met de hoofd-UI.
Maak de componenten voorspelbaar door een kleine set inputs te definiëren:
Bepaal daarna het uiterlijk. Kies één keer spacing, typografie, pictogramgrootte en knopstijl en behandel het als regel. Als de pictogramgrootte en knopstijl hetzelfde blijven, stoppen gebruikers met opmerken en gaan ze het state-UI vertrouwen.
Houd varianten beperkt zodat de kit niet verandert in een tweede designsysteem. Drie groottes dekken meestal: klein (inline), standaard (sectie) en volledige pagina (blocking).
Als je schermen genereert in Koder.ai, voorkomt een eenvoudige instructie als “use the app StateKit for loading/error/empty with default variant” drift. Het vermindert ook late cleanup over React web en Flutter mobiel.
Copy is onderdeel van het systeem, niet decoratie. Zelfs met consistente layout maken ad-hoc formuleringen schermen toch anders voelen.
Kies een gedeelde stem: kort, specifiek, kalm. Zeg wat er is gebeurd in eenvoudige termen en vertel vervolgens wat de gebruiker nu kan doen. De meeste schermen hebben maar één duidelijke titel, één korte uitleg en één voor de hand liggende actie nodig.
Een paar berichtpatronen dekken de meeste situaties. Houd ze kort zodat ze op kleine schermen passen:
Vermijd vage tekst zoals “Something went wrong” alleen. Als je echt de oorzaak niet weet, zeg wat je wel weet en wat de gebruiker nu kan doen. “We couldn’t load your projects” is beter dan “Error.”
Stel één regel: elke fout- en lege staat biedt een vervolgstap.
Dit is nog belangrijker bij AI-genereerde UI, waar schermen snel verschijnen. Templates houden copy consistent zodat je niet tientallen éénmalige berichten herschrijft tijdens de eindpolish.
Wanneer state-schermen verschillende acties voorstellen van het ene naar het andere scherm, twijfelen gebruikers. Teams eindigen dan vaak met knoppen en copy die vlak voor lancering worden aangepast.
Bepaal welke actie bij elke staat hoort en houd plaatsing en label consistent. De meeste schermen hebben één primaire actie. Als je een tweede toevoegt, moet die het hoofdpad ondersteunen, niet ermee concurreren.
Houd de toegestane acties beperkt:
Saaie knoppen zijn een feature. Ze maken de UI vertrouwd en helpen gegenereerde schermen coherent te blijven.
Toon “Retry” alleen wanneer retry realistisch kan werken (timeouts, onstabiel netwerk, 5xx). Voeg een korte debounce toe zodat herhaalde taps geen verzoeken spammen, en schakel de knop naar een loading-state terwijl je opnieuw probeert.
Na herhaalde mislukking, behoud dezelfde primaire knop en verbeter de secundaire hulp (bijvoorbeeld een “Check connection” tip of “Try again later”). Vermijd het introduceren van nieuwe layouts alleen omdat iets twee keer faalde.
Voor foutdetails, toon een duidelijke reden waar gebruikers iets mee kunnen doen (“Your session expired. Sign in again.”). Verberg technische details standaard. Als je ze nodig hebt, verstop ze achter een consistente “Details” affordance op alle platforms.
Voorbeeld: een “Projects” lijst laadt niet op mobiel. Beide platforms tonen dezelfde primaire “Retry” actie, schakelen deze uit tijdens retryen en voegen na twee mislukkingen een kleine connectietip toe in plaats van de gehele knoplay-out te veranderen.
Behandel state-consistentie als een kleine productwijziging, niet als een redesign. Ga incrementeel en maak adoptie makkelijk.
Begin met een snelle snapshot van wat je al hebt. Streef niet naar perfectie. Leg de algemene variaties vast: spinners vs skeletons, volledige-pagina fouten vs banners, “geen resultaten”-schermen met verschillende toon.
Een rollout-plan dat praktisch blijft:
Zodra de componenten bestaan, is de echte tijdbesparing een korte regelset die discussie wegneemt: wanneer blokkeert een staat de hele pagina vs alleen een kaart, en welke acties moeten aanwezig zijn.
Houd de regels kort:
Als je een AI UI-generator gebruikt zoals Koder.ai, betalen deze regels zich snel terug. Je kunt prompten met “use the state kit components” en schermen krijgen die op zowel React web als Flutter mobiel bij je systeem passen met minder cleanup.
Laat polishwerk ontstaat meestal omdat state-handling als one-offs is gebouwd. Een scherm “werkt”, maar de ervaring voelt elke keer anders wanneer iets tijd kost, faalt of geen data heeft.
Skeletons helpen, maar ze te lang laten staan doet mensen denken dat de app vastloopt. Een veelvoorkomende oorzaak is het tonen van een volledige skeleton op een trage call zonder signaal dat er nog beweging is.
Time-box het: na een korte vertraging schakel je over naar een lichtere “Still loading…” boodschap of toon je voortgang wanneer dat kan.
Teams schrijven vaak elke keer een nieuw bericht, ook al gaat het om hetzelfde probleem. “Something went wrong”, “Unable to fetch” en “Network error” kunnen één geval beschrijven, maar voelen inconsistent en bemoeilijken support.
Kies één label per fouttype en hergebruik het op web en mobiel, met dezelfde toon en detailniveau.
Een andere klassieke fout is het tonen van een lege staat voordat data klaar is, of “No items” tonen wanneer het echte probleem een mislukte request is. De gebruiker kiest dan de verkeerde actie (zoals content toevoegen) terwijl ze hadden moeten retryen.
Maak de beslisvolgorde expliciet: loading eerst, dan error als het faalde, en pas empty wanneer je weet dat het verzoek succesvol was.
Een fout zonder herstelactie creëert doodlopende wegen. Het tegenovergestelde komt ook voor: drie knoppen die om aandacht strijden.
Houd het strak:
Kleine verschillen tellen op: pictogramstijlen, padding, knopvormen. Dit is ook waar AI-genereerde UI kan afdrijven als prompts per scherm variëren.
Vergrendel spacing, pictogramset en layout voor state-componenten zodat elk nieuw scherm dezelfde structuur erft.
Als je consistente state-handling over web en mobiel wilt, maak dan de “saaie” regels expliciet. De meeste late polish ontstaat omdat elk scherm zijn eigen laadgedrag, timeouts en labels uitvond.
Voor een volledige pagina laad, kies één standaard: skeletons voor content-rijke schermen (lijsten, kaarten, dashboards) en een spinner alleen voor korte wachttijden waar de layout onbekend is.
Voeg een timeout-drempel toe zodat de UI niet stil blijft hangen. Als laden langer duurt dan ongeveer 8–10 seconden, schakel dan naar een duidelijke boodschap en een zichtbare actie zoals “Retry.”
Voor gedeeltelijke loads, blank de pagina niet. Houd bestaande content zichtbaar en toon een kleine voortgangsindicator nabij de sectie die bijgewerkt wordt (bijv. een dunne balk in de header of een inline spinner).
Voor gecachte data, geef de voorkeur aan “stale but usable.” Toon gecachte inhoud direct en voeg een subtiele “Refreshing…” indicator toe zodat mensen begrijpen waarom data kan veranderen.
Offline is een eigen staat. Zeg het duidelijk en zeg wat nog werkt. Bijvoorbeeld: “You’re offline. You can view saved projects, but syncing is paused.” Bied één volgende stap aan zoals “Try again” of “Open saved items.”
Houd deze consistent over platforms:
Als je UI genereert met een tool zoals Koder.ai, helpt het inbedden van deze regels in een gedeelde state kit om elk nieuw scherm standaard consistent te houden.
Stel je een eenvoudige CRM voor met een Contacten-lijstscherm en een Contact-detailscherm. Als je loading-, error- en lege staten als one-offs behandelt, lopen web en mobiel snel uiteen. Een klein systeem houdt dingen afgestemd, zelfs als UI snel wordt geproduceerd.
Eerste keer lege staat (Contacten-lijst): de gebruiker opent Contacten en ziet nog niets. Op zowel web als mobiel blijft de titel hetzelfde (“Contacts”), legt de lege boodschap uit waarom (“No contacts yet”) en is één duidelijke vervolgstap beschikbaar (“Add your first contact”). Als setup vereist is (zoals inbox koppelen of CSV importeren), wijst de lege staat naar die exacte stap.
Langzaam netwerk laden: de gebruiker opent een Contact-detailpagina. Beide platforms tonen een voorspelbare skeleton-layout die overeenkomt met de uiteindelijke pagina-structuur (header, sleutelvelden, notities). De terug-knop werkt nog steeds, de paginatitel is zichtbaar en je vermijdt willekeurige spinners op verschillende plekken.
Serverfout: het details-request faalt. Zelfde patroon op web en mobiel: een korte kop, één zin en een primaire actie (“Retry”). Als retry opnieuw faalt, bied dan een tweede optie zoals “Go back to Contacts” zodat de gebruiker niet vastzit.
Wat consistent blijft is simpel:
Een release kan “klaar” lijken totdat iemand een trage verbinding, een nieuw account of een wankele API raakt. Deze checklist helpt laatste gaten te vinden zonder van QA een speurtocht te maken.
Begin bij lijstschermen, want die vermenigvuldigen zich. Kies drie veelvoorkomende lijsten (zoekresultaten, opgeslagen items, recente activiteit) en controleer of ze allemaal dezelfde lege-state-structuur gebruiken: een duidelijke titel, één behulpzame zin en één primaire actie.
Zorg dat lege staten nooit verschijnen terwijl data nog wordt geladen. Als je even “Nothing here yet” flitst en daarna inhoud verschijnt, verliest gebruikersvertrouwen snel.
Controleer laadindicatoren op consistentie: grootte, plaatsing en een redelijk minimale duur zodat ze niet flikkeren. Als web een topbalk-spinner toont maar mobiel een full-screen skeleton voor hetzelfde scherm, voelt het als twee verschillende producten.
Fouten moeten altijd beantwoorden op “wat nu?” Elke fout heeft een vervolgstap nodig: retry, refresh, filters aanpassen, opnieuw inloggen of support contacteren.
Een korte controle voordat je de build klaar noemt:
Als je een AI-builder als Koder.ai gebruikt, zijn deze checks extra belangrijk omdat schermen snel worden gegenereerd maar consistentie nog steeds afhangt van een gedeelde kit en gedeelde copy-regels.
Consistentie is het makkelijkst wanneer het onderdeel is van dagelijks werk, niet een eenmalige opschoning. Elk nieuw scherm zou dezelfde patronen moeten gebruiken zonder dat iemand zich hoeft te herinneren “maak het hetzelfde” aan het einde.
Maak state-gedrag onderdeel van je definition of done. Een scherm is niet af totdat het een loading-state, een lege state (indien van toepassing) en een error-state met een duidelijke actie heeft.
Houd de regels lichtgewicht, maar schrijf ze op. Een kort document met een paar screenshots en de exacte copy-patronen is meestal genoeg. Behandel nieuwe varianten als uitzonderingen. Als iemand een nieuw state-ontwerp voorstelt, vraag dan of het echt een nieuwe situatie is of dat het in de kit past.
Als je veel schermen refactort, beperk risico door gecontroleerd te werken: update één flow tegelijk, verifieer op web en mobiel en ga door. In Koder.ai kunnen snapshots en rollback grotere veranderingen veiliger maken, en planning mode kan helpen de gedeelde state kit te definiëren zodat nieuw gegenereerde schermen vanaf dag één je defaults volgen.
Kies deze week één gebied waar state-problemen vaak late fixes veroorzaken (vaak zoekresultaten, onboarding of een activity feed). Doe dan:
Een concreet teken dat het werkt: minder “kleine” tickets zoals “add retry”, “empty state looks weird” of “loading spinner blocks the page.”
Wijs één eigenaar aan voor state-standaarden (een designer, een tech lead of beiden). Ze hoeven niet alles goed te keuren, maar ze moeten de kit beschermen tegen langzaam splitsen in nieuwe varianten die er vergelijkbaar uitzien maar anders werken en later tijd kosten.
Begin met het benoemen van een kleine set staten die je overal gebruikt: initial loading, refreshing, empty baseline, zero results en error. Voeg expliciete regels toe voor offline en trage netwerken zodat ze niet als willekeurige fouten worden behandeld. Zodra het team akkoord is met namen en triggers, wordt de UI voorspelbaar over schermen en platforms.
Bouw een kleine StateKit met drie herbruikbare onderdelen: Loading, Error en Empty. Laat elk onderdeel werken met dezelfde inputs (titel, korte boodschap, één primaire actie en optionele details) zodat elk scherm het kan gebruiken zonder nieuwe UI te bedenken. Maak de standaardvariant het makkelijkst in gebruik zodat teams stoppen met het maken van one-offs.
Gebruik een eenvoudige besluitvolgorde: toon loading totdat het verzoek klaar is, toon vervolgens error als het mislukt is, en toon pas empty nadat een succesvolle respons geen data heeft teruggegeven. Dit voorkomt de veelvoorkomende bug waarbij “Geen items” kort verschijnt voordat inhoud laadt. Het helpt ook QA omdat het gedrag overal consistent is.
Kies één standaardactie per staat en hergebruik hetzelfde label en dezelfde plaatsing over schermen. Fouten krijgen doorgaans “Retry”, lege baselines krijgen “Create” (of de volgende setup-stap) en zero results krijgen “Clear filters”. Als de primaire actie voorspelbaar is, bewegen gebruikers sneller en discussies over knoptekst nemen af.
Schrijf copy in een gedeeld sjabloon: een korte titel die de situatie benoemt, één zin die het in eenvoudige taal uitlegt, en één duidelijke vervolgstap. Geef de voorkeur aan specifieke boodschappen zoals “We konden je projecten niet laden” boven vage meldingen als “Iets ging mis.” Houd de toon rustig en consistent zodat web en mobiel aanvoelen als één product.
Behandel offline als een eigen staat, niet als een algemene fout. Toon gecachte inhoud als die beschikbaar is, zeg duidelijk “You’re offline”, en leg uit wat er nog werkt. Bied één vervolgstap aan zoals “Try again” zodat de gebruiker niet hoeft te raden.
Wacht kort voordat je een foutflits toont op een trage verbinding. Als het laden een drempel overschrijdt, schakel dan over naar een duidelijke “Still loading…”-stijlboodschap en bied een zichtbare actie zoals “Retry”. Dit maakt de app responsief, zelfs bij slechtere netwerken.
Gebruik drie groottevarianten: klein inline (in een kaart of sectie), standaard sectie en volledige pagina (blocking). Definieer wanneer elke variant toegestaan is zodat teams niet voor elk scherm iets anders bedenken. Het vastzetten van dezelfde marges, pictogramstijl en knopstijl over varianten zorgt voor een consistente ervaring.
Neem een paar regels op: verplaats de focus naar het bericht en de primaire actie wanneer de staat verschijnt, kondig laden en fouten aan met duidelijke labels, en zorg dat knoppen makkelijk te raken zijn. Vertrouw niet alleen op kleur of animatie om status te communiceren. Als dit in de StateKit zit, erft elk nieuw scherm deze toegankelijkheidsregels automatisch.
Rol het in per productgebied, te beginnen met veelgebruikte lijsten en detailschermen. Maak een inventaris, kies een paar canonieke plaatsen en vervang éénmalige staten door gedeelde componenten telkens wanneer je een scherm aanraakt. Als je UI genereert in Koder.ai, voeg dan een vaste instructie toe om de StateKit standaard te gebruiken zodat nieuwe schermen niet afdwalen.