Geschatte tijd: 1-2 uur. Ik raad aan deze oefening te doen met de belangrijkste stakeholders.
Laten we beginnen met de vooronderstelling dat je de opdracht hebt gekregen om een mobiele app te maken. Het eerste wat je je moet afvragen is: “Welk probleem los ik op en voor wie los ik het op?” De antwoorden op deze samengestelde vraag zullen de basis leggen voor je ontwerp omdat ze inzichten zullen verschaffen die de kenmerken en functies van je ontwerpen kunnen sturen. Deze antwoorden zullen u ook zeker helpen beslissen wat de MVP (minimum viable product) zal zijn voor uw ontwerp.
Het kan bijvoorbeeld zijn dat u veel functies op de product roadmap hebt, maar u hoeft zich alleen te concentreren op de essentiële functies om de eerste versie van de app met succes te lanceren. U kunt beginnen met de vraag “Welke functies en functies moeten we maken zodat onze doelgroep hun doel / taak kan voltooien?”
Om deze vraag te beantwoorden, kunt u een gebruikersstroom creëren op basis van het “gelukkige pad” van uw primaire gebruiker (u kunt zich later richten op alle randgevallen). Ik raad een whiteboard aan waar je eerst alle belangrijke stappen van de gebruiker opschrijft. Als je die stappen hebt opgeschreven, kun je beginnen met het maken van high-level schetsen van deze stappen. Dit helpt je om te bepalen welke mogelijkheden de gebruiker nodig heeft bij elke stap en houdt scope creep op afstand.
Note: Probeer jezelf ervan te weerhouden om te schetsen zonder eerst de user flow op te schrijven. Onze gedachten kunnen erg creatief en van het spoor raken als we meteen in schetsen springen.
Hier ziet u hoe deze oefening eruit kan zien nadat u uw gebruikersstroom hebt uitgeschreven en er ruwe schetsen onder hebt gemaakt. Denk eraan, het hoeft niet mooi te zijn, maar het moet je ideeën voldoende overbrengen zodat je verder kunt naar de volgende stap, digitale wireframes.
Voorbeeld 1
Voorbeeld 2
Voorbeeld 3
Step two: Low-fidelity digitale wireframes
Geschatte tijd: 2-3 dagen, afhankelijk van de omvang van de MVP.
Als je eenmaal de wireflows van je MVP op een rijtje hebt, is de volgende stap het maken van iets gedetailleerdere wireframes. Je kunt een papieren prototype maken of direct overgaan op digitale wireframes (als snelheid geboden is, ga ik meestal meteen over op digitale wireframes).
Note: als je met een gevestigd merk werkt, is het misschien mogelijk om componenten van een bestaand ontwerpsysteem te gebruiken en kun je meteen overgaan op high-fidelity, stap 3, hieronder.
Ik raad aan om artboards te maken voor de belangrijkste schermen die je in je schetsoefening hebt ontdekt. Het aantal schermen dat je nodig hebt, zal toenemen naarmate je door het wireframingproces van schetsen, low-fidelity wireframes, naar high-fidelity wireframes gaat.
Voor de low-fidelity digitale wireframes gebruikt u een ontwerptool naar keuze om eenvoudige vormen te maken en basislettertypen te gebruiken om uw wireframes te maken. Er zijn ook veel UI-kits waarmee je dit proces kunt versnellen en waarmee je low-fidelity ontwerpen kunt maken die visueel wat aantrekkelijker zijn. Ik raad ook aan om een mediane artboard grootte te gebruiken die kan werken op de meeste telefoonschermen. Als je de gegevens hebt van je doelgroep en welke telefoongrootte het meest door hen wordt gebruikt, ga dan voor die schermgrootte.
Ik gebruik een artboard van 875 x 667px wanneer ik Adobe XD gebruik (of een andere ontwerptool, aangezien de meeste een vooringestelde grootte hebben ingebouwd), omdat dit de “middenweg” is van schermgroottes (vooral voor iPhone). Ik vind dat dit formaat goed werkt voor iPhone 8 en iPhone X, en ik vind dat dit ook goed werkt voor Android.
Hier een voorbeeld van low-fidelity schermen in actie:
Nadat u uw low-fidelity schermen hebt gemaakt, uw ontwerpen hebt getest met gebruikers en de handtekeningen van belanghebbenden hebt ontvangen, bent u nu klaar om de high-fidelity schermen te maken.
Stap drie: High-fidelity digitale wireframes
Geschatte tijd: meer dan 1 week. Dit hangt af van het feit of u al een ontwerpsysteem hebt of dat u het helemaal opnieuw creëert. Deze stap duurt ook langer omdat er waarschijnlijk meer schermen zullen worden toegevoegd dan in de low-fidelity fase.
In deze stap komen uw ontwerpen tot leven! Het is ook de fase waarin je ontwerpen echt beginnen te lijken op een werkende mobiele app die je kunt prototypen, testen, itereren, goedkeuring krijgen, en dan, uiteindelijk, overhandigen aan het ontwikkelteam.
Overwegingen:
- Als het product waar je aan werkt al een gevestigd merk heeft, zul je waarschijnlijk kleuren, pictogrammen en lettertypen uit de merkrichtlijnen halen.
- Als het product waar je aan werkt geen volledig gevestigde merk look and feel heeft, kun je gebruik maken van een UI-kit om je ontwerpproces te versnellen.
De volgende overweging is met welke schermen begin je? U kunt beginnen met:
- Key schermen voor elke sectie van uw hoofdnavigatie, of;
- Key user flows voor de gebruiker, of;
- Prioriteer de schermen die u ontwerpt op basis van de volgorde van het ontwikkelingsschema (dit is typisch waar ik begin, zodat ik kan werken in een agile methode, ervoor te zorgen dat schermen klaar zijn voor handoff als het ontwikkelingsteam ze nodig heeft).
In dit voorbeeld, ga ik het proces laten zien van het gebruik van een gevestigde UI kit in Adobe XD. En ik ga beginnen met het aanmelden van gebruikers en het maken van profielen, omdat ontwikkelteams waarmee ik heb gewerkt meestal beginnen met gebruikersbeheer in hun app-ontwikkelingsproces.
De UI-kit die ik heb gekozen heeft al een vastgesteld kleurenpalet, tekenstijlen, en gemeenschappelijke UI-elementen (aka componenten) die kunnen worden gekopieerd en geplakt in de wireframes.
Note: vroeg in het proces, raad ik aan om alle elementen die je van plan bent te hergebruiken in componenten (of symbolen) te veranderen. Op deze manier, als je nodig hebt om de pijl terug te veranderen van een pijl ” ← ” in een wortel “<“, kunt u wijzigen via de master component en hebben het update over alle wireframes in plaats van te kopiëren en plakken van de wijziging op elk scherm dat moet worden bijgewerkt.
Voorbeeld van kleuren, tekenstijlen en componenten:
Om het proces te beginnen, zou ik beginnen met het opbouwen van de onboarding-, aanmeldings- en gebruikersprofielschermen:
Daarnaast zou ik beginnen met het opbouwen van globale navigatie-elementen:
Daarna zou ik beginnen met het maken van high-fidelity draden voor alle gebruikersstromen voor de app, te beginnen met de flows die prioriteit hebben op basis van levering aan de ontwikkeling (of voor alle items die nog moeten worden getest door gebruikers).
Ik raad aan om aparte ontwerpbestanden te maken voor elk van de belangrijkste gebruikersstromen, zodat je gemakkelijk kunt prototypen en delen met de ontwikkeling wanneer je werkt in een agile-methode (dat wil zeggen een bestand voor het aanmelden van gebruikers en het aanmaken van accounts, een bestand voor messaging, een bestand voor de zoekervaring, enz. Bij het werken in teams, adviseer ik meestal dat een persoon verantwoordelijk is voor de master-bestand, om verwarring te verminderen. Op deze manier weet elk teamlid dat ze trekken uit de goedgekeurde, master-bestand bij het werken aan het creëren van nieuwe functies en stromen voor de app.
Bij wijze van voorbeeld, hier is een vogelvlucht van een master-bestand voor een van mijn projecten. Merk op dat ik de schermen heb gegroepeerd en gerangschikt op gebruikersstroom en ontwikkelingsprioriteit. Ik zal dit masterbestand blijven aanvullen naarmate ik de volgende reeks gebruikersstromen ontwikkel.
Enkele leidende beginselen voor het maken van betere mobiele apps
Nu u weet hoe u kunt beginnen met het wireframen van uw digitale ervaringen, is het tijd om uw ontwerpbenadering op een hoger niveau te brengen. Als je een ervaring creëert voor mobiele apparaten, op besturingssystemen als iOS en Android, zijn er enkele belangrijke overwegingen om in gedachten te houden. Hier zijn wat algemene tips (en een paar persoonlijke meningen) over het ontwerpen van mobiele apps en hoe je minder tijd kwijt bent aan het ontwerpen voor elk type apparaat op de markt. Als je op zoek bent naar meer inspiratie, kun je ook deze wireframe-voorbeelden voor websites en mobiele apps bekijken.
Ik ben er sterk van overtuigd dat een ontwerp zo alomtegenwoordig mogelijk moet zijn. Dus waar mogelijk, moedig ik een besturingssysteem agnostisch ontwerp aan. Hier is waarom:
- Als een gebruiker van een Android-telefoon overstapt op een iPhone, zou hij niet twee verschillende manieren moeten leren om een app te gebruiken die dezelfde behoefte oplost. De oplossing zou nog steeds dezelfde moeten zijn. Nu weet ik dat er verschillen kunnen zijn in gebaren en apparaatspecifieke mogelijkheden, maar ik vind dat een app dezelfde UI en gebruikersflow moet bieden, ongeacht het besturingssysteem. En belangrijke functies moeten niet te diep in contextuele menu’s worden verborgen; dat is gewoon slechte UX.
- Het is duur om twee (of meer) totaal verschillende ervaringen te ontwerpen, te ontwikkelen en te onderhouden (vooral wanneer de ervaring ongeacht het platform hetzelfde zou kunnen zijn).
- Bij het ontwerpen en onderhouden van de verschillende ervaringen, kunnen de ervaringen erg verschillend beginnen te worden. Dit kan het merk schaden en het volgen en implementeren van feedback en functies moeilijker maken.
Dus hoe maak je alomtegenwoordige ontwerpen en ben je apparaat agnostisch? Hier is hoe ik het doe:
- Behandel mijn mobiele ontwerpen alsof ik voor het mobiele web ontwerp. Mijn ontwerpen zijn responsive omdat er oneindig veel schermgroottes en pixeldichtheden zijn (deze veranderen net zo snel als bedrijven ze kunnen engineeren). Als ontwerpers hebben we geen tijd om voor elke pixeldichtheid te ontwerpen en ik denk niet dat mijn klanten voor die tijd willen betalen. Dus gebruik ik een artboard-breedte van 375, wat werkt voor de meeste moderne iPhone-modellen en Android.
- Ik ga om met de vreemde schermvorm van de iPhone X en iPhone 11 door het dev-team te vertellen om de achtergrondkleur van de header gewoon naar boven uit te breiden.
- Ik heb het geluk dat ik verschillende telefoontypen binnen handbereik heb, dus ik kan mijn ontwerpen dan testen via de XD mobiele app met behulp van een USB. Dit is handig omdat ik lettergroottes, UI-aanrakingspunten en de zichtbaarheid van scherminhoud kan testen als het toetsenbord omhoog staat. Ik kan ook de “vouw”-lijn testen en er zeker van zijn dat belangrijke inhoud, zoals CTA’s en belangrijke inhoud, zichtbaar blijft en niet van de onderkant van het scherm verdwijnt.
- Ik probeer alleen gebaren te gebruiken die universeel zijn, bijv. tikken, vegen, drukken en vasthouden. Ik denk dat we ons moeten kunnen concentreren op de beste gebruikerservaring, ongeacht het OS.
- Ik gebruik SVG’s voor alle pictogrammen en logo’s, zodat ze er geweldig uitzien op elke schermresolutie.
- Ik gebruik navigatie- en menustructuren die universeel zijn en niet te OS-specifiek.
De enige keer dat ik wireframes moet ontwerpen die apparaatspecifiek zijn, is wanneer ik een prototype maak en een native apparaatfunctie oproept, zoals de camera. Zelfs dat kan variëren van telefoon tot telefoon en OS.
De meeste van mijn klanten beginnen met iOS. We testen en valideren het ontwerp en, zodra het op de goede weg is, dan ontwikkelen we voor Android. En weet je wat? We proberen de UI helemaal niet te veranderen, of de gebruikersstromen. In plaats daarvan richten we ons op de branding, look and feel, features en functies, en user flows. Het komt allemaal terug op het belangrijkste: de kern gebruikerservaring.
