De term 'bruikbaarheidshygiëne' werd voor het eerst geïntroduceerd door Google in de context van de basisbeginselen die moeten worden aangepakt om frustratie bij de gebruiker te voorkomen.

In dit artikel zullen we kijken naar zes belangrijke gebieden van mobiel ontwerp waar u speciale aandacht aan moet besteden, om een ​​positieve gebruikerservaring te creëren.

1. Zorg dat inhoud toegankelijk is wanneer de gebruiker geen internetverbinding heeft

Volgens recent onderzoek van Google geeft 34% van de gebruikers de voorkeur aan een app via een mobiele website wanneer ze een slechte internetverbinding hebben. Wanneer ze een app openen, verwachten ze daar veel inhoud te zien, ongeacht of ze verbonden zijn met internet of niet. Het is essentieel om essentiële inhoud toegankelijk te maken, zelfs als er weinig of geen gegevensverbinding is. Als de inhoud er niet is, raken gebruikers gefrustreerd en schakelen ze over naar een andere app die de informatie die ze willen zien, beter kan cachen.

Hieronder ziet u een voorbeeld van hoe Apple Maps (links) en Google Maps (rechts) hun cache gebruiken. Google Maps onthoudt de laatste locatie en bevat een indrukwekkend aantal kaartdetails in de cache, terwijl Apple Maps absoluut niets laat zien. Er valt niet veel goeds te zeggen over de offline ervaring van Apple Map.

001

2. Ontwerp voor elk native mobiele platform

Een grote factor in het laten schijnen van de mobiele UX van uw app is de gebruikersinterface. Tegenwoordig willen de meeste ontwikkelaars hun apps op meerdere platforms distribueren. Terwijl u uw app plant voor meerdere platforms, moet u er rekening mee houden dat elk platform zijn eigen visuele taal heeft: een reeks conventies en stijlen die moeten worden gevolgd.

Er zijn bijvoorbeeld algemene elementen, zoals een statusbalk en een koptekst, die op alle pagina's van uw ontwerp worden weergegeven. Het verschil tussen de twee platforms lijkt vrij onbelangrijk - enigszins afwijkende grootte, verschillende uitlijning van de titeltekst (op Android, de tekst links uitgelijnd, terwijl die voor iOS gecentreerd is) en lettertypen (Roboto op Android, San Francisco op iOS), maar je moet geen van deze instellingen wijzigen als u wilt dat de app native is.

002

Hetzelfde geldt voor knoppen en andere bedieningselementen - keuzerondjes, selectievakjes, velden, schakelaars - alle functionele componenten moeten een native gevoel geven. Als u elementen van het ene platform naar het andere repliceert, loopt u het risico de gebruikerservaring en conversie in gevaar te brengen. De verschillen zijn klein genoeg om met één ontwerp vooruit te gaan, maar deze subtiele verschillen zijn essentieel voor een native look.

003

Als u elementen van de gebruikersinterface in uw app wilt aanpassen, moet u dit zorgvuldig aanpassen aan uw merknaam en niet volgens de conventies van een ander platform.

3. Niets in uw app moet een doodlopende weg zijn

Het ontwerpen van een UX is ontwerpen voor flow en flow gaat in de meeste gevallen over het vooruitgaan om een ​​doel te bereiken. Vermijd het maken van doodlopende pagina's in uw apps omdat dead-ends verwarring creëren, gebruikers blokkeren op weg naar het doel en leiden tot aanvullende en onnodige acties. Neem een ​​voorbeeld van een foutstatusscherm van Spotify. Het helpt gebruikers simpelweg de context niet te begrijpen en helpt hen niet om het antwoord op de vraag te vinden: "Wat kan ik eraan doen?"

004

4. Repliceer de webervaring niet met apps

Gebruikers verwachten bepaalde interactiepatronen en interface-elementen in mobiele apps. Wat we op internet ontwerpen, voelt vaak onhandig aan in een mobiele app - niet noodzakelijk omdat er iets mis is, maar omdat het gewoon verschilt van wat onze gebruikers verwachten te zien. Een veelgebruikt voorbeeld is het gebruik van tekst met onderstreepte links, die sterk samenhangen met webpagina's. Hieronder ziet u een voorbeeld van een inlogformulier van de TD Bank-app voor iOS. Het lijkt absoluut alsof ze ontwerpen voor mobiel internet, niet voor een mobiele app: links zijn onderstreept en er staat zelfs een copyright-melding in de gebruikersinterface.

Apps gebruiken knoppen, geen koppelingen.

005

5. Onderbreek geen gebruikers met verzoeken om de app te beoordelen

Niemand wil echt onderbroken worden, laat staan ​​iets dat nutteloos is terwijl ze midden in iets belangrijks zitten. Desondanks onderbreken apps vaak gebruikers door hen te vragen een beoordeling achter te laten. Het ergste van alles is wanneer deze dialoog gebruikers in het midden van de taak onderbreekt of direct nadat de app is gestart.

006

U moet voorkomen dat u gebruikers onderbreekt om hen te vragen uw app te beoordelen als ze deze onlangs hebben gedownload of slechts een paar keer hebben gebruikt. Er is niets mis met het vragen om een ​​beoordeling, maar onthoud dat je eerst je gebruikers een geweldige ervaring wilt geven. Wacht tot ze terugkerende gebruikers blijken te zijn en vind een moment in je app dat het minst opdringerig is. Wissen, een Taken-app voor iOS is een goed voorbeeld: deze toont het dialoogvenster "Beoordeel de app" nadat de gebruiker de resterende taken uit een lijst heeft gewist. Dit is een geweldig moment in de app: gebruikers voelen zich goed omdat ze net hun takenlijst hebben gewist en zullen de app eerder gunstig beoordelen.

007

6. Neem geen gebruikers naar de browser

Houd gebruikers altijd in de app. Als uw app een specifieke functie of inhoud mist, probeert u een in-app-browser te gebruiken; maar raak de browser van de smartphone niet aan, anders zullen gebruikers hun track verliezen en niet terugkeren naar de app. Dit zal het verlaten en de conversie verminderen.

008

Wanneer een gebruiker op de koppeling "Wachtwoord vergeten?" In de Facebook-app klikt, vraagt ​​de app de gebruiker om de browser te starten om deze actie uit te voeren.