Zo vind je inspiratie voor mobiele appinterfaces en zet je die om in een ontwerpbriefing

1. Begin met een ontwerpvraag

Schrijf vóór het bekijken één zin over de persoon en het moment waarvoor je ontwerpt. Bijvoorbeeld: ‘Iemand die voor het eerst thuis kookt, wil een recept voor een doordeweekse avond kiezen en weten wat de volgende stap is.’ Benoem vervolgens de onzekerheid: is het lastigste deel keuzes scannen, een aanbeveling vertrouwen of een recept met meerdere stappen beginnen?

Die vraag begrenst je zoektocht. Bepaal welk platform, productonderdeel en welke taak ertoe doen. Verken je de ervaring bij eerste gebruik, bekijk dan onboardingvoorbeelden; gaat het om het kiezen van een abonnement, kijk dan naar betaalschermen; vergelijk voor gegevensinvoer formulierpatronen. Met ScreenKits kun je echte appschermen per categorie bekijken. Sla nuttige apps op als browserbladwijzers om tijdens de analyse naar hun schermen terug te keren.

• Voor wie ontwerp je en wat probeert die persoon te bereiken?
• Welke ontwerpkeuze is onzeker: hiërarchie, volgorde, navigatie, inhoud of feedback?
• Welke randvoorwaarden tellen mee, zoals platform, toegankelijkheid, schermgrootte of bedrijfsregels?

2. Verzamel een kleine, doelgerichte set referenties

Verzamel een handvol voorbeelden voor dezelfde taak of een nauw verwante taak. Neem meer dan één aanpak op: een directe route, een begeleide route en misschien een versie die een fout of lege staat afhandelt. Sla voor elk kandidaatvoorbeeld de app op en noteer welk scherm of moment je opnieuw wilt bekijken. Een compacte set is makkelijker te vergelijken dan een ongefilterd inspiratiebord.

Kijk over categoriegrenzen heen wanneer het onderliggende probleem hetzelfde is. Zowel een planningsapp als een boodschappenapp moet iemand misschien helpen een datum te kiezen en een wijziging te bevestigen. De nuttige overeenkomst is de beslisstructuur, niet het visuele thema. Ga er niet van uit dat een interface jouw specifieke probleem oplost omdat doelgroep of branche vergelijkbaar is.

• Kies referenties om een benoembare reden, bijvoorbeeld ‘laat zien hoe een gekozen optie de samenvatting verandert’.
• Neem verschillende oplossingen op, zodat het eerste gelikte voorbeeld niet automatisch de standaardoplossing wordt.
• Gebruik browserbladwijzers om gekozen apps bij de hand te houden terwijl je de briefing schrijft.

3. Lees de flow, niet alleen het screenshot

Een afzonderlijk scherm toont op één moment de indeling, kleur, tekst en bediening. Het vertelt niet wat eraan voorafging, wat na een tik gebeurt of of een taak slaagt. Doorloop elk relevant scherm in volgorde. Noteer instappunt, beslissing, actie, feedback en volgende status. Neem alternatieven op, zoals validatiefouten, sluiten en terugkeren om een keuze te bewerken, wanneer die statussen voor de taak belangrijk zijn.

Scheid observatie van interpretatie. ‘De hoofdactie blijft tijdens drie stappen onderaan staan’ is een observatie; ‘dit moet makkelijker in gebruik zijn’ is een onbewezen bewering. Een screenshot kan tot een hypothese inspireren, maar bewijst geen bruikbaarheid. NN/g beschrijft prototypen en gebruikerstests als manieren om mogelijke bruikbaarheidsproblemen te vinden en te leren hoe mensen met een voorgestelde interface omgaan.

4. Zet observaties om in een originele briefing

In de analyse worden referenties bruikbaar. Haal er een overdraagbaar principe uit, zoals ‘maak de gevolgen van een keuze zichtbaar vóór bevestiging’. Bepaal vervolgens hoe dat principe in jouw product moet werken, op basis van de taak, inhoud en randvoorwaarden. Kopieer geen herkenbare merkillustratie, exacte formulering of bijzondere indeling alleen omdat een voorbeeld overtuigend is.

Voor het receptenvoorbeeld kan de referentieset suggereren om tijd vroeg zichtbaar te maken en te tonen wat een gekozen filter verandert. De originele briefing kan een korte route voor maaltijdplanning, een zichtbare tijdsbeperking, duidelijke filterstatussen en een controlestap vóór het opslaan voorschrijven. Die beslissingen dienen het doel van het product; ze bouwen niet het scherm van een andere app na.

• Doelgroep en context: wie heeft dit nodig en waar of wanneer gebruikt die persoon het?
• Gebruikersdoel en succes: wat moet diegene kunnen afronden of begrijpen?
• Flow: wat zijn de hoofdstappen, beslissingen en belangrijke alternatieve statussen?
• Ontwerpprincipes: wat moet de interface duidelijk of makkelijk maken?
• Randvoorwaarden en open vragen: wat moet vaststaan en wat vraagt onderzoek?
• Evaluatieplan: welke taak geef je iemand in het prototype en wat ga je observeren?

5. Maak een prototype, controleer toegankelijkheid en verbeter

Zet de briefing om in een ruwe schets van de flow voordat je de visuele stijl uitwerkt. Maak een prototype van de belangrijkste beslissing en de feedback erop, en vraag iemand die de doelgroep vertegenwoordigt een realistische taak uit te voeren. Let op aarzeling, onverwachte keuzes en fouten. Pas de flow aan en herhaal; volgens de onderzoeksrichtlijnen van NN/g horen iteratief ontwerpen en prototypebeoordeling bij het leren, in plaats van dat een eerste versie meteen vaststaat.

Beoordeel toegankelijkheid tegelijk met dit werk. Apples Human Interface Guidelines benadrukken waarneembare, aanpasbare interacties en aandacht voor verschillende invoermethoden. Controleer tekstvergroting, contrast, grootte en afstand van bedieningselementen, duidelijke labels en of betekenis alleen van kleur afhangt. Controleer ook of de flow zich aan langere tekst aanpast en met ondersteunende technologie te begrijpen is. De toegankelijkheidsrichtlijnen van Material Design zijn een nuttige aanvulling als je product Android-conventies volgt.

• Geef een taakomschrijving in plaats van een rondleiding door de interface en observeer of mensen verder kunnen.
• Test vroeg een versie met weinig detail, zolang structurele wijzigingen nog makkelijk zijn.
• Bekijk de platformrichtlijnen die relevant zijn voor het apparaat en het ontwerpsysteem dat je ondersteunt.
• Keer alleen terug naar referenties om een vraag te onderzoeken; behandel visuele gelijkenis niet als bewijs.

Controlelijst van referentie naar briefing

Controleer vóór overdracht of de briefing een productbeslissing beschrijft en niet alleen een sfeerbord is. Iemand die de referenties niet heeft verzameld, moet de beoogde taak, voorgestelde flow, open keuzes en het plan om te leren of het ontwerp werkt kunnen begrijpen.

• De oorspronkelijke gebruiker en taak staan expliciet vermeld.
• Bij elke referentie staat welke vraag of welk patroon ze helpt onderzoeken.
• Observaties zijn gescheiden van aannames en claims over bruikbaarheid.
• De briefing beschrijft een originele flow en een onderbouwing die bij het product past.
• Toegankelijkheid, platformgedrag en belangrijke alternatieve statussen zijn opgenomen.
• Een taak voor het prototype en een plan voor beoordeling op basis van observatie zijn gedefinieerd.