Navigatiepatronen voor mobiele apps: tabs, menu's en geneste flows
Kies navigatiepatronen voor mobiele apps op basis van de frequentie van taken, de informatiestructuur, toegankelijkheidsbehoeften en hoe makkelijk mensen hun plek terugvinden.
Navigatie moet de opbouw van een app begrijpelijk maken. Mensen moeten weten welke onderdelen er zijn, waar ze zich bevinden en hoe ze verder kunnen zonder hun werk kwijt te raken. Een tabbalk, menu of geneste flow is geen stijlvoorkeur: elk toont een andere relatie tussen bestemmingen.
Begin bij de taken waarnaar mensen terugkeren en breng daarna de inhoudshiërarchie in kaart. Gebruik directe navigatie voor gelijkwaardige bestemmingen, geneste navigatie voor relaties tussen bovenliggend onderdeel en detail, en een menu of aangepaste navigatie op grotere schermen wanneer de app meer bestemmingen heeft dan een compact scherm prettig kan tonen.
Belangrijkste inzichten
- Gebruik tabs of een navigatiebalk voor een kleine groep verschillende hoofdonderdelen die mensen vaak opnieuw bezoeken.
- Gebruik geneste navigatie wanneer een bestemming duidelijk binnen een andere valt en behoud een heldere weg terug.
- Behandel menu's als een manier om een bredere lijst bestemmingen te tonen, niet als verstopplek voor essentiële taken.
- Houd labels, geselecteerde statussen, focusgedrag en het herstellen van de navigatiestatus duidelijk, zodat mensen zich kunnen oriënteren en hun weg terugvinden.
Begin bij de structuur, niet bij de component
Som de bestemmingen van de app op en groepeer ze volgens het mentale model van de gebruiker. Een bestemming als Zoeken kan naast Start staan als gelijkwaardig onderdeel; de details van een opgeslagen item horen onder Opgeslagen. Als mensen vaak tussen gelijkwaardige onderdelen moeten springen, houd die keuzes dan zichtbaar. Als ze meestal vanuit een collectie één item openen en daarna teruggaan, maakt een stapel of geneste flow die relatie op natuurlijke wijze duidelijk.
Maak onderscheid tussen bestemmingen en acties. Maken, delen, filteren en sorteren veranderen de huidige context of voeren er een handeling op uit; meestal zijn het geen plekken in de app. Plaats ze in een werkbalk, menu of contextuele bediening in plaats van elke actie tot hoofdnavigatie te maken.
- Benoem de taken die mensen herhaaldelijk uitvoeren en bepaal welke onderdelen overal bereikbaar moeten zijn.
- Teken relaties tussen bovenliggende en onderliggende onderdelen voordat je navigatiebediening kiest.
- Houd bestemmingen op hetzelfde hiërarchische niveau visueel en gedragsmatig consistent.
Vergelijk de drie patronen
Een tabbalk of navigatiebalk maakt enkele hoofdbestemmingen zichtbaar en laat mensen snel wisselen. Dit werkt wanneer de bestemmingen gelijkwaardig zijn en elk label zonder uitleg herkenbaar is. Laat het huidige onderdeel geselecteerd. Stop geen ongerelateerde acties in de balk en laat belangrijke bestemmingen niet verdwijnen in een overloopmenu.
Een navigatiemenu kan een grotere, gegroepeerde lijst bestemmingen bevatten en soms wisselen tussen accounts of werkruimten. Een tijdelijk menu bespaart schermruimte, maar vraagt een extra stap om te openen en te kiezen en bedekt tijdelijk de inhoud. Op compacte telefoons kunnen veelgebruikte bestemmingen daardoor verstopt aanvoelen. De huidige Android-richtlijnen van Material 3 geven voor drie tot vijf bestemmingen op compacte schermen de voorkeur aan een navigatiebalk en passen de navigatie aan grotere vensters aan; oudere Material-richtlijnen die vanaf vijf bestemmingen menu's aanraden, zijn geen universele huidige grens.
Bij geneste navigatie opent een lijst, kaart of link een onderliggende weergave, met een titel en terugknop die de route bewaren. Ze past bij categorieën, instellingen, productdetails en taken met meerdere stappen. Diepe nesting wordt frustrerend als de hiërarchie verborgen is, teruggaan onvoorspelbaar werkt of gebruikers herhaaldelijk terug moeten om een gelijkwaardig onderdeel te bereiken. Voeg zoeken, snelkoppelingen of een duidelijkere hoofdstructuur toe als mensen vaak tussen takken wisselen.
| Patroon | Past wanneer | Let op |
|---|---|---|
| Tabs / navigatiebalk | Enkele gelijkwaardige onderdelen verdienen frequente, directe toegang | Te veel bestemmingen, onduidelijke pictogrammen, verborgen overloopmenu, verloren status per tab |
| Navigatiemenu | Mensen hebben een geordende lijst met veel of gegroepeerde bestemmingen nodig | Essentiële onderdelen achter een menu, lange scrolllijst, problemen met focus of sluiten |
| Geneste navigatie | Mensen gaan van een bovenliggende collectie naar een verwant detail of taak | Onduidelijke locatie, onvoorspelbaar teruggaan, te veel niveaus, verloren ingevoerde gegevens |
Kies op basis van taakfrequentie en schermgrootte
Vraag hoe vaak mensen tijdens een gewone sessie tussen onderdelen wisselen. Een compacte, vaste groep vaak gebruikte bestemmingen is geschikt voor een zichtbare balk. Als iemand zich meestal op één taak of een detail concentreert, houd de navigatie dan rustiger en geef inhoud ruimte. Een menu kan werken voor minder vaak gebruikte onderdelen, maar controleer of mensen die kunnen vinden en zonder te gissen kunnen terugkeren.
Houd rekening met venstergrootte, oriëntatie en platformconventies. Apples huidige Human Interface Guidelines beschrijven de tabbalk op iPhone als hoofdnavigatie en ondersteunen op iPad een aanpasbare weergave als tabbalk of zijbalk. Material 3 noemt het compacte patroon een navigatiebalk en biedt andere navigatievormen naarmate de beschikbare breedte groeit. Deze patronen dienen hetzelfde doel maar zijn niet dezelfde componenten; volg de plaatsing, het gedrag en de aanpassing van het eigen platform in plaats van de navigatie van het ene platform op het andere te kopiëren.
Maak oriëntatie en herstel betrouwbaar
Alleen pictogrammen maken navigatie lastiger te leren en kunnen onduidelijk zijn voor schermlezers. Geef bestemmingen korte zichtbare labels, maak de geselecteerde status semantisch herkenbaar en zorg voor toegankelijke namen en bruikbare tikzones. Controleer contrast in geselecteerde en niet-geselecteerde staten, grotere tekst, vertalingen en weergave van rechts naar links. Test waar ondersteund met VoiceOver of TalkBack en met toetsenbord- of schakelaarbediening; de focus moet voorspelbaar bewegen als een menu opent, een bestemming wordt gekozen of een weergave sluit.
De weg terug hoort bij navigatie. Houd het gedrag van Terug en Sluiten gescheiden: Terug volgt de hiërarchie terug, Sluiten verlaat een tijdelijke of modale weergave. Bewaar een bruikbare positie en ingevoerde gegevens wanneer iemand tussen hoofdonderdelen wisselt of van details terugkeert. Als een bestemming leeg of tijdelijk niet beschikbaar is, behoud dan haar plek en leg de status uit in plaats van de navigatie stilzwijgend te verwijderen of uit te schakelen. Maak bij een destructieve of kostbare taak de weg terug duidelijk voordat de gebruiker bevestigt.
Een praktische navigatiecontrole
Doorloop de app met een echte taak en herhaal dit met toegankelijkheidsfuncties ingeschakeld. Noteer of mensen het huidige onderdeel kunnen herkennen, een vaak gebruikte bestemming kunnen bereiken en na een verkeerde afslag kunnen herstellen. Vergelijk dezelfde route op een compacte telefoon en in een groter venster; een aangepaste indeling moet de informatiearchitectuur behouden terwijl de bediening van vorm verandert.
Gebruik de schermbibliotheek om echte voorbeelden van apponderdelen en flows te vergelijken en beoordeel ze daarna op basis van de taken in jouw product. Het sterkste patroon houdt zijn structuur begrijpelijk terwijl de app groeit en maakt de weg terug na een onderbreking duidelijk.
- Kan een nieuwe gebruiker de hoofdonderdelen uitleggen op basis van alleen hun labels?
- Kunnen mensen makkelijk tussen gelijkwaardige bestemmingen wisselen, met een duidelijk zichtbare selectie?
- Tonen detailschermen een betekenisvolle titel en een voorspelbare weg terug?
- Blijven context en toegankelijkheidsfocus logisch behouden bij het openen en sluiten van een menu?
- Blijven labels, tikzones, contrast en geselecteerde statussen bruikbaar met grotere tekst en ondersteunende technologie?
- Kan iemand terugkeren zonder conceptinvoer, scrollpositie of een nuttige plek in de hiërarchie kwijt te raken?
- Past de structuur zich aan een groter scherm aan zonder concurrerende hoofdnavigatie te verdubbelen?
