Ontwerp van inloggen en registreren op mobiel: maak de accountstap duidelijk
Een praktische gids voor het ontwerpen van inloggen en registreren in mobiele apps: van bepalen wanneer een account nodig is tot formulieren die invoerfouten goed opvangen en bruikbare herstelroutes.
Een inlogscherm is een kleine interface met grote gevolgen: het kan iemand helpen een taak te hervatten of onderbreken voordat duidelijk is waarom een account nodig is. Goed ontwerp van mobiele accountschermen begint door authenticatie als onderdeel van de productreis te zien, niet als een poort waar iedereen bij het starten doorheen moet.
De flow moet doel en keuzes begrijpelijk maken, alleen gegevens vragen die nu nodig zijn en een rustige weg vooruit bieden als er iets misgaat. De details zijn belangrijk voor zowel nieuwe bezoekers als terugkerende gebruikers die misschien vergeten zijn hoe ze eerder inlogden.
Belangrijkste inzichten
- Vraag om een account op het eerste betekenisvolle moment waarop het een duidelijk voordeel biedt of echt nodig is.
- Leg elke inlogoptie uit in vertrouwde taal en maak de route voor een nieuw account duidelijk anders dan de toegang voor terugkerende gebruikers.
- Houd formulieren gericht, geef velden duidelijke labels en laat wachtwoordmanagers en plakken werken zoals verwacht.
- Toon fouten in tekst met een bruikbare volgende stap, bewaar geldige invoer en bied herstel zonder verwijten.
Kies het moment waarop een account nuttig wordt
Begin bij de taak waarvoor iemand kwam. Als de kernervaring zonder account werkt, laat mensen dan eerst verkennen en vraag om inloggen wanneer ze een functie bereiken waarvoor opgeslagen voorkeuren, toegang op meerdere apparaten, samenwerken of een transactie nodig is. Apples Human Interface Guidelines adviseren inloggen waar mogelijk uit te stellen en het voordeel uit te leggen wanneer een account vereist is.
Een verzoek in de context is makkelijker te begrijpen dan een blokkade bij het openen. Een leesapp kan iemand bijvoorbeeld titels laten bekijken en pas om een account vragen wanneer diegene een leeslijst wil synchroniseren. Als een account vanaf het begin noodzakelijk is, zeg dan waarom voordat je velden toont. Houd de uitleg concreet en passend: ‘Maak een account om je projecten op te slaan en op een ander apparaat te openen’ is nuttiger dan ‘Sluit je aan bij onze community’.
- Scheid verplichte gegevens van optionele profielinformatie.
- Overweeg bij afrekenen als gast of een eenmalige taak of het aanmaken van een account kan wachten tot nadat de directe waarde is geleverd.
- Breng mensen na geslaagde authenticatie terug naar de actie die ze wilden afronden.
Maak inlogkeuzes duidelijk en herkenbaar
Iemand moet kunnen zien of die een account aanmaakt of terugkeert naar een bestaand account. Geef beide routes verschillende labels, maak de hoofdactie visueel duidelijk en plaats alternatieve methoden zo dat ze vergelijkbaar zijn zonder het scherm te overladen. Gebruik waar relevant namen van aanbieders en knoppen volgens de platformrichtlijnen; alleen een algemeen label ‘Doorgaan’ legt niet uit wat daarna gebeurt.
Bied alleen methoden aan die het product ondersteunt en kan blijven onderhouden. E-mail, een passkey of een platformidentiteit kunnen bij verschillende doelgroepen passen. Presenteer ze als keuzes, niet als bewijs dat één methode altijd het makkelijkst of veiligst is. Leg eventuele extra verplichte gegevens uit.
Terugkerende gebruikers herinneren zich hun inlogmethode misschien niet. Maak herstel en alternatieve inlogmethoden vindbaar en leg uit wat te doen als een e-mailadres bij een andere methode hoort. Uitleg over het koppelen van accounts kan mensen helpen toegang tot hun bestaande account te behouden.
Houd formulieren gericht en geschikt voor de hulpmiddelen van gebruikers
Vraag alleen de velden die nodig zijn om een account aan te maken of te openen. Gebruik blijvende labels in plaats van alleen placeholdertekst, kies een passend invoertype en toetsenbord en maak de volgende actie duidelijk. Als voor registratie meerdere gegevens nodig zijn, groepeer verwante velden en stel optionele voorkeuren uit totdat iemand het product bereikt.
Authenticatie moet werken met automatisch invullen en wachtwoordmanagers. Gebruik standaardveldnamen en semantiek en vermijd eigen gedrag dat het invullen van inloggegevens blokkeert. Blokkeer het plakken van wachtwoorden niet: mensen gebruiken misschien een wachtwoordmanager of ander hulpmiddel. WCAG-richtlijnen benadrukken dat browsers en wachtwoordmanagers van derden inlogvelden moeten kunnen invullen.
Gedrag verschilt soms per apparaat en wachtwoordmanager. Controleer daarom de flow op ondersteunde platforms en laat handmatige correctie toe. Bewaar na een mislukte poging waar praktisch nuttige, niet-gevoelige waarden zoals het e-mailadres.
- Gebruik een zichtbaar label zoals ‘E-mailadres’ en een duidelijk label voor het wachtwoord.
- Laat mensen waar passend een wachtwoord zichtbaar maken of controleren, maar maak die knop niet de enige manier om invoer te corrigeren.
- Plaats de hoofdknop bij de velden en geef die een specifiek label zoals ‘Account maken’ of ‘Inloggen’.
Ontwerp voor fouten, herstel en het volgende bezoek
Een nuttige foutmelding wijst het betreffende veld of de mislukte stap aan en vertelt hoe iemand verder kan. ‘Er is iets misgegaan’ is onvoldoende als een e-mailadres verkeerd is opgemaakt of een veld leeg is. WCAG 2.2-succescriterium 3.3.1 vereist dat ontdekte invoerfouten in tekst worden geïdentificeerd en beschreven; kleur of een pictogram mag niet de enige drager van de boodschap zijn.
Gebruik neutrale taal en plaats specifieke hulp dicht bij het veld. Hypothetische tekst bij een verkeerd opgemaakt adres kan bijvoorbeeld zijn: ‘Voer een e-mailadres in als [email protected].’ Bij een mislukte aanmelding kan een product zeggen: ‘We konden je met deze gegevens niet aanmelden. Controleer je e-mailadres en wachtwoord of stel je wachtwoord opnieuw in.’ Geef geen gevoelige accountinformatie prijs in foutmeldingen; kies formuleringen die passen bij de privacy- en misbruikpreventiebehoeften van het product.
Leg uit wat er gebeurt nadat iemand een reset aanvraagt, bied een weg terug naar inloggen en help mensen de eerder gebruikte methode te vinden. Toon bij latere bezoeken duidelijk dat iemand is ingelogd en bied toegang tot accountinstellingen, uitloggen en hulp. Als accounts in de app kunnen worden aangemaakt, maak het verwijderen van een account dan makkelijk vindbaar.
- Verbind een foutmelding met het veld waarop die betrekking heeft en maak haar zonder kleurherkenning waarneembaar.
- Plaats herstelacties bij het inlogformulier en laat gebruikers niet onnodig opnieuw beginnen.
- Beoordeel zowel de situatie bij eerste gebruik als die van terugkerende gebruikers, inclusief gewijzigde e-mailadressen en niet-beschikbare inlogmethoden.
Een praktische beoordeling van de accountflow
Doorloop de flow als nieuwe gebruiker, terugkerende gebruiker en iemand die toegang herstelt. Bekijk de schermen in hun context. De bibliotheek met mobiele patronen kan teams helpen vergelijken hoe formulieren invoer, labels en acties organiseren.
- Kunnen mensen nuttige productwaarde bereiken vóór het inloggen wanneer een account niet noodzakelijk is?
- Legt het scherm uit waarom een account nodig is en welke gegevens verplicht zijn?
- Kan iemand registratie, inloggen, alternatieve methoden en accountherstel onderscheiden?
- Blijven veldlabels zichtbaar en kunnen automatisch invullen en plakken inloggegevens invullen?
- Benoemen fouten het probleem in tekst, bewaren ze nuttige invoer en suggereren ze een volgende stap?
- Keert iemand na succes terug naar de oorspronkelijke taak?
Veelgestelde vragen
Moet een mobiele app een account vereisen voordat mensen kunnen rondkijken?
Alleen als de kernfunctie echt een account vereist. Als mensen het product eerst kunnen bekijken of proberen, laat dat dan toe en vraag om inloggen wanneer het een duidelijk voordeel oplevert of nodig is voor een specifieke actie.
Moeten wachtwoordvelden plakken en automatisch invullen met een wachtwoordmanager toestaan?
Ja. Gebruik herkenbare veldlabels en semantiek en blokkeer plakken of automatisch invullen niet. Deze functies helpen mensen hun favoriete hulpmiddelen voor inloggegevens te gebruiken. Het gedrag kan per apparaat en wachtwoordmanager verschillen, dus controleer de flow op ondersteunde platforms.
Wat moet een foutmelding bij inloggen bevatten?
Beschrijf het probleem in tekst, wijs het betreffende veld of de stap aan en bied een praktische volgende actie. Houd de formulering neutraal en onthul geen gevoelige accountgegevens.
