Voorbeelden van onboarding in mobiele apps: patronen voor je volgende flow

1. Laat het eerste nuttige moment leidend zijn

Stel je een app voor maaltijdplanning voor die opent met een startplan waarin iemand meteen één maaltijd kan vervangen, in plaats van met dia's over recepten en lijstjes. Die interactie maakt het product concreet. Behoud een introductie alleen als die een echte onzekerheid wegneemt.

Apples Human Interface Guidelines adviseren snelle, optionele en gerichte onboarding. NN/g raadt instructies af die mensen al doende kunnen leren, maar erkent dat inrichting, persoonlijke ervaringen en onbekende werkwijzen redenen zijn om begeleiding te bieden. Een vertrouwde notitie- of timerapp is misschien duidelijker als die direct bij de taak opent.

Bestudeer voorbeelden in de onboardingbibliotheek van ScreenKits voor ideeën over indeling en volgorde. Lees ze als visuele referenties: een screenshot kan een patroon suggereren, maar niet aantonen hoe mensen het begrepen of of het werkte.

• Beschrijf het eerste betekenisvolle resultaat in één zin.
• Vraag of de interface zelf de volgende actie begrijpelijk kan maken.
• Behoud een welkom of waardeboodschap alleen als die een echte onzekerheid wegneemt.

2. Gebruik stapsgewijze inrichting in plaats van een muur aan vragen

Stel je een hardloopapp voor die een doel, eenheden, herinneringstijd en locatie wil weten. Een stapsgewijze versie biedt een startplan, vraagt om een doel wanneer iemand het plan aanpast en laat eenheden en herinneringen in de instellingen. Als een antwoord essentieel is, leg dan op het moment zelf uit waarom.

Dit patroon is nuttig wanneer personalisatie afhangt van een paar betekenisvolle keuzes. Het is minder sterk wanneer vragen aanvoelen als een quiz zonder zichtbaar resultaat. Toon voortgang alleen als die duidelijk maakt hoeveel werk er nog is; voeg niet meerdere schermen toe om een kort formulier vriendelijker te laten lijken. Bied verstandige standaardwaarden en laat mensen die later aanpassen.

Ook het aanmaken van een account hoort bij deze afweging. Apple raadt aan pas om een account te vragen als de kernfunctionaliteit dat vereist en inloggen waar mogelijk uit te stellen, zodat mensen de app eerst kunnen begrijpen. Als registratie wel nodig is, maak dan het voordeel en de vereiste gegevens duidelijk. De verwante gids voor mobiel inloggen en registreren kan helpen dit onderdeel afzonderlijk te beoordelen.

• Noteer bij elke vraag welke productbeslissing van het antwoord afhangt.
• Verplaats optionele voorkeuren naar het moment waarop ze nuttig worden, of naar de instellingen.
• Leg verplichte accountstappen uit vanuit de taak van de gebruiker.

3. Leg een nieuwe handeling uit op het moment zelf

Denk aan een budgetapp met een ongebruikelijke manier om een transactie te splitsen. Een algemene carrousel die naar elke tab wijst, vraagt iemand instructies te onthouden voordat er een reden is om ze te gebruiken. Een contextueel patroon wacht tot de eerste transactie zichtbaar is en biedt dan een korte hint naast de splitsknop. In een interactieve oefenstap kan iemand de handeling met voorbeeldgegevens proberen voordat een echte registratie wordt aangepast.

De ontwerpkeuze draait om timing en gevolgen. Leg de unieke interactie uit wanneer die relevant wordt, plaats de instructie bij de bediening en maak de volgende actie duidelijk. Als iemand de hint sluit, zorg dan dat die later nog een vindbare hulproute heeft. Leg standaardnavigatie niet uit als de interface die zelf duidelijk zou moeten maken.

Bij complexe flows kan een kleine begeleide taak meer leren dan een rondleiding: maak een voorbeeldbord, sla een item op of bekijk een voorbeeld van een werkwijze. Houd de oefening omkeerbaar en vermeld of ze echte gegevens verandert. Apple adviseert waar mogelijk interactief leren en korte flows met noodzakelijke voorbereidende stappen.

• Bepaal welke ene handeling nieuw of makkelijk verkeerd te begrijpen is.
• Plaats de hint bij die handeling en bied een veilige manier om het meteen te proberen.
• Maak overslaan, sluiten en het later terugvinden van de uitleg eenvoudig.

4. Vraag toestemming wanneer de reden zichtbaar is

Stel je een fotodagboek voor waarin een locatie aan een item kan worden toegevoegd. Op het welkomstscherm om locatietoegang vragen maakt het verzoek abstract. Wachten tot iemand ‘Locatie toevoegen’ kiest, schept een duidelijke uitleg: de locatie kan dit item labelen en de functie werkt ook zonder toegang. Zo hoort het toestemmingsmoment bij een concreet voordeel, met een duidelijk alternatief bij weigering.

Dezelfde redenering geldt voor meldingen, camera, contacten en gezondheidsgegevens. Uitleg vóór een toestemmingsverzoek moet juist, kort en specifiek over de functie zijn. Suggereer niet dat toegang verplicht is als de kern van de app zonder die toegang werkt. Apple adviseert verzoeken alleen in de onboarding te plaatsen wanneer toegang tot privégegevens noodzakelijk is; vraag anders toestemming wanneer iemand de betreffende functie voor het eerst gebruikt.

• Verbind elk verzoek aan een actie die iemand net koos of een taak die diegene probeert af te ronden.
• Vertel wat de toestemming mogelijk maakt en wat zonder toestemming beschikbaar blijft.
• Houd het systeemverzoek gescheiden van je eigen uitleg over het voordeel.

Een praktische controlelijst

Bekijk elke stap op een kleine telefoon voordat je overgangen polijst. Geef iemand die het product niet kent een realistische eerste taak en observeer waar die aarzelt. Vergelijk waar veilig mogelijk een lichtere versie. Behandel bevindingen als bewijs over bruikbaarheid, niet als gegarandeerde zakelijke resultaten.

• Kan iemand een betekenisvolle eerste taak bereiken zonder een rondleiding te onthouden?
• Heeft elke vraag of instelstap een duidelijke, directe reden?
• Kunnen mensen optionele uitleg overslaan en later terugvinden?
• Worden toestemmingen gevraagd bij de functie die ze nodig heeft, met een eerlijke uitleg?
• Kunnen mensen dankzij standaardwaarden doorgaan zonder onnodige inrichting?
• Werkt de flow met langere tekst, ondersteunende technologie en onderbroken sessies?