Praktische tips voor mobile & intranet usability

Afgelopen week vond de jaarlijkse Usability Week van de Nielsen Norman Group (NN/G) plaats in Amsterdam. Dat betekende een week lang inhoudelijke sessies over allerlei onderwerpen rondom gebruiksvriendelijkheid. Eén sessie duurde minimaal de hele dag. Sommige sessies besloegen zelfs meerdere dagen. Hieronder volgt een verslag van de sessies die ik mee wist te pikken, inclusief een (helaas veel te kleine) selectie uit alle aangereikte tips en adviezen.

Mobile User Experience

Volgens de subtitels (“Usability of websites and apps on mobile devices” en “Touchscreen application usability”) beloofden de twee dagen inzicht te bieden in richtlijnen voor het gebruiksvriendelijk maken van mobiele websites en apps. Dat viel helaas een beetje tegen.

Vooral de eerste sessie was redelijk globaal. Er werd overal een beetje over verteld, terwijl er wat mij betreft meer focus had mogen komen te liggen op de strategische keuzes, wanneer het gaat om het al dan niet ontwikkelen van mobiele sites en apps.

Hoewel er veel concrete tips werden gegeven, waren ze lang niet allen specifiek voor mobiele platformen. Tips als “houd het simpel”, “toon zoektips als er geen zoekresultaten zijn” en “zoek adresgegevens automatisch op met behulp van een postcode om de moeite van het invoeren klein te houden” gelden natuurlijk ook voor desktop websites. Die zaken worden hoogstens nog belangrijker wanneer het om mobiel gaat.

Een conclusie die ik uit de sessies kon trekken is, dat apps blijkbaar nog te nieuw zijn om net zo veel standaarden te kennen als desktop websites. Hopelijk gaan steeds meer apps en apparaten dezelfde methoden gebruiken (denk bijvoorbeeld aan de manier waarop je teruggaat naar je vorige stap), zodat er meer uniformiteit komt voor de gebruiker. Ik ben ook erg benieuwd welk platform gaat ‘winnen’, als het gaat om het worden van de standaard. Wat dat betreft is het natuurlijk ook erg interessant om te zien wat Windows 8 voor impact gaat hebben.

Tips uit sessie 1

• Browsen (tijd doden) en zoeken naar specifieke informatie zijn de twee belangrijkste activiteiten die men op de mobiele telefoon uitvoert. Ook zittend op de bank worden er weinig complexere activiteiten op uitgevoerd. Dit ligt anders voor tablets.
• Vragen die je jezelf moet stellen bij het bepalen van je mobiele strategie:
  • “Moeten we wel mobiel zijn?” Staat het budget het toe, hebben we genoeg bezoek/inkomsten via mobiele apparaten (vanaf 7 tot 10% kan het rendabel worden), hebben we bepaalde features op de site (communiceren met anderen, tijd doden, informatie browsen, kleine transacties afhandelen), wisselt onze content vaak en/of is deze nodig als je van huis bent?
  • “Voor welke soorten telefoons moeten we ontwikkelen?”
  • “Wat voor platform moeten we ontwikkelen en hoe?” (app, mobiele website, webapp, responsive design)
  • “Wat voor soort content en taken moeten logischerwijs mobiel beschikbaar zijn?”
• Responsive design is aan te raden, wanneer je gebruikers dezelfde taken op de mobiele versie willen uitvoeren als op de desktop website en je dus niets uit een mobiele site zou kunnen weglaten. Let op: sommige Androidversies bieden de gebruiker de mogelijkheid te kiezen voor de desktop website of de mobiele site.
• Je hoeft geen rekening meer te houden met feature phones (versus smartphones), behalve wanneer je een site hebt waarop mensen de tijd doden, wanneer minimaal een derde je site via een feature phone bezoekt, of als je een sociale netwerk- of communicatiegerichte site hebt.
• Zorg voor een consistente vormgeving tussen je website, webapp en app, want men gebruikt ze vaak allemaal.
• Niet doen: de aangeboden content beperken. De gebruiker wil dezelfde content kunnen bereik als op de desktop website, alleen in een andere vorm.
• Wel doen: gebruik maken van de functies van een telefoon, zoals GPS of de camera.
• 40% Van de mobiele zoekopdrachten is lokaal. Speel hier op in en benadruk lokale content.
• Stuur bezoekers automatisch door naar de websiteversie die geschikt is voor hun apparaat. Promoot de app op de mobiele website.
• Ontwerp voor onderbrekingen: men moet op ieder moment een taak kunnen onderbreken en later weer kunnen oppakken – eventueel zelfs op een andere versie van je site.
• Plaats bij sites gericht op ‘browsing’, de zoekfunctie onderaan de pagina.
• Verberg wachtwoorden niet achter *-tekens; het is al moeilijk genoeg om ze correct in te voeren.
• Toon altijd een navigatiebalk wanneer de site veel content bevat of gericht is op browsen. Bij taakgeoriënteerde websites kan de homepage als ‘navigatie hub’ gebruikt worden. Herhaal de navigatie onderaan lange pagina’s.
• Meld het vooraf als een video niet op een mobiel apparaat af kan worden gespeeld, niet pas wanneer de gebruiker de video al heeft gedownload.
• Als je een gebruikerstest uitvoert, rekruteer dan testers die minimaal 3 maanden de telefoon gebruiken, want anders observeer je ook hoe ze er mee om leren gaan.

Tips uit sessie 2

• Momenteel komt een derde van het non-desktopbezoek via een tablet, en twee derde via mobiel. Het meest gebruikte apparaat (in de VS) is een Androidtoestel en niet een iPhone, maar het meest gebruikte platform is iOS, aangezien dit ook voor tablets wordt gebruikt.
• Gebruikers weten vaak niet welke apps ze allemaal hebben geïnstalleerd. Ze gebruiken de zoekfunctie om ze te vinden.
• Tablets worden voornamelijk gebruikt om content te consumeren, minder om dingen te doen die interactie vereisen. Tabletgebruikers hebben veel meer tijd dan smartphonegebruikers. Veel gebruikers nemen hun tablet niet mee het huis uit.
• Het verschilt per tablet welke versie van een website het meest geschikt is. De iPad ligt qua schermafmeting dicht bij laptops en hiervoor is de desktop website dus prima. Voor middelgrote en kleine tablets (zoals de Kindle Fire) is de mobiele site weer meer geschikt.
• Vertrouw bij het ontwikkelen van een app niet op de aanwezigheid van vaste knoppen, behalve de back- en de homeknop. Vanaf versie 4 van Android zijn de fysieke knoppen vervangen door virtuele knoppen en zijn de menu- en de zoekknop weg.
• Kijk uit met het gelijktrekken van je design over meerdere platforms, aangezien ieder platform bepaalde conventies heeft en bezoekers kunnen verwachten dat je app hierop aansluit.
• Focus bij het ontwikkelen van een app op 1 kernfunctie en ontwerp daar omheen. Voeg geen andere functies toe die niet gerelateerd zijn aan de kernfunctie.
• De ideale grootte om iets makkelijk met de vinger te kunnen raken, is 1×1 cm.
• Houd er rekening mee dat mensen per ongeluk op verkeerde dingen klikken. Zorg voor een back-knop.
• Pas op met gestures: gebruikers kennen ze vaak niet allemaal, dus ze moeten heel intuïtief zijn.
• Zorg dat je app zowel in landscape modus als in portrait modus te gebruiken is, maar laat gebruikers er niet continu tussen wisselen. Toon in de ene modus niet meer content of navigatie dan in de andere modus.
• Als je gebruik wil maken van de locatie van de gebruiker, vraag dan pas om toestemming als de applicatie het nodig heeft, niet bij het opstarten van de app. Dit is niet nodig bij Android phones – de gebruiker geeft al bij installatie toegang hiervoor. Zorg dat GPS via een setting in de app zelf aan/uit te zetten is.
• Toon navigatie altijd wanneer deze belangrijk is, vaak wordt gebruikt, of wanneer het standaard navigatie-items zijn. Andere navigatie mag verborgen worden achter een knop.
• Vraag niet al bij de eerste keer dat de app opstart toestemming om push messages te tonen. De app moet zich eerst bewijzen. Wees specifiek over wat voor notifications het zullen zijn. Als gebruikers het niet weten, zeggen ze doorgaans nee.
• Zorg dat het getoonde toetsenbord aansluit op de vereiste invoer in een veld. Vertrouw er niet op dat de gebruiker de next/tab knop op het toetsenbord gebruikt.

Interaction design 3

De sessie over interaction design omvatte maar liefst drie dagen. Omdat ik niet meerdere sessies op een dag kon volgen, pikte ik alleen de derde sessie mee, aangezien je ze ook los van elkaar mocht bijwonen.

De spreker was onderhoudend, dankzij de aangename hoeveelheid humor waarmee hij zijn presentatie had doorspekt. Hij stak zijn persoonlijke mening over sommige organisaties en software niet onder stoelen of banken – Adobe’s Photoshop moest  het meerdere malen ontgelden en het werd overduidelijk gemaakt dat Apple slecht bezig is door zijn touch screen interfaces te sterk te versimpelen en daarbij essentiële zaken zoals de scrollbar, te verbergen.

Hij bood ons ook een paar mooie inzichten, zoals dat je als interactie-ontwerper eigenlijk een goochelaar bent, die de complexe werkelijkheid via een interface met illusies (zoals een prullenbak, die natuurlijk niet echt in je apparaat zit), aan de gebruiker onttrekt. En ook goochelaars en cabaretiers doen aan gebruikerstesten: zij proberen hun trucs en grappen eerst uit op een kleiner publiek en schaven hun programma steeds weer wat bij, voordat ze in grote zalen optreden.

Tijdens een oefening moesten we met een klein groepje een papieren prototype van een app uitwerken en testen met iemand uit een andere groep. Het is confronterend hoeveel je daar van leert, ook al test je slechts 3 schermen: niet alleen hoeft je schermindeling niet goed te zijn, het hele concept waar je user scenario op gebaseerd is, kan fout blijken te zijn zodat de complete opzet opnieuw moet.

Een selectie uit de concrete tips die gegeven werden

• Het is belangrijker dat je consistent aansluit op de verwachtingen van de gebruiker, dan dat alle onderdelen van je applicatie er consistent uit zien of consistent werken.
• Als je wijzigingen doorvoert ten opzichte van een eerdere versie, zorg dan dat ze goed zichtbaar zijn. Wijzig geen handelingen die men gedachtenloos uitvoert.
• Zorg dat je bij een project betrokken wordt voordat het concept er al ligt. Daadwerkelijke efficiencyverbeteringen bereik je niet met design alleen, maar door het onderliggende concept te wijzigen (Macintosh versus MSDos>Windows).
• Mensen zijn geneigd langer te blijven/meer onderdelen van je site te ontdekken, als ze weten hoe ze weer weg kunnen. Zorg dus o.a. voor een sense of place en een undo-functie.
• Als de gebruiker moet wachten op een systeemreactie:

1. Geef binnen een tiende van een seconde feedback op een actie (klik, aanraking, etc.), bijvoorbeeld door een knop ingedrukt te tonen.
2. Toon binnen 0,5 tot 2 seconden een andere muiscursor.
3. Geef na 2 seconden een indicatie hoe lang er nog gewacht moet worden.
4. Toon na 5 seconden een voortgangsindicator. Zorg voor een bewegende indicator, zodat de gebruiker weet dat het systeem niet is vastgelopen.
5. Duurt het langer dan 10 seconden, entertain de gebruiker dan, bijvoorbeeld via het tonen van tips.
6. Bij langer dan 15 seconden wachten moet een visuele en auditieve indicatie worden gegeven wanneer het systeem klaar is.

• Maak wizards niet te lang en te sequentieel. De gebruiker moet tussentijds af kunnen haken en later weer verder kunnen gaan.
• Als je eerste Paper Prototyping-test succesvol was, heb je de test niet goed opgezet. Zorg voor uitdagende testscenario’s en taken die de grenzen van de applicatie opzoeken.
• Test liever met een globale papieren schets dan een precieze schets op een computer, want het kost minder tijd om ze te maken en de eerste versies zijn toch nooit goed.
• De eerste testsessie hoeft niet per se met de doelgroep plaats te vinden, omdat je naar grote struikelblokken zoekt waar je collega’s (maar geen ontwerpers of ontwikkelaars) ook wel tegenaan zullen lopen.
• Test niet alleen beginners. Gevorderde gebruikers lezen doorgaans geen instructies en zullen dus ook vastlopen.

Application Usability 2

Ook dit onderwerp besloeg meerdere sessies, maar ze waren wel duidelijk losgekoppeld van elkaar. Deel twee ging in op de workflow van gebruikers en hoe je je applicatie daar op af moet stemmen. Het was redelijk theoretisch en bestond uit de behandeling van losse aspecten, zoals de keuze tussen een ‘deductive’ of ‘inductive’ interface en het testen met gebruikers. Ik had echter gehoopt op de toelichting van een methode, over hoe je van de lessen die je tijdens het observeren van gebruikers hebt geleerd, stapsgewijs komt tot een applicatie die goed is afgestemd op die gebruikers.

Maar ook hier liepen we weer met een hoop tips naar buiten

• Bepaal of je een native applicatie of een hosted applicatie bouwt. Native apps zijn doorgaans meer voorspelbaar, hosted apps zijn flexibeler.
• Als een cloud applicatie de desktop simuleert, stijgen de verwachtingen van de gebruiker. Bijvoorbeeld dat data niet verloren gaat wanneer ze zonder op te slaan naar een andere pagina navigeren en dat de back-button van de browser gewoon werkt.
• Bepaal of je een deductive of inductive interface nodig hebt. Een deductive interface is geschikt voor gevorderde gebruikers, omdat hij vrijheid biedt over hoe de applicatie gebruikt wordt. Inductive interfaces begeleiden de gebruiker meer en bieden een duidelijke chronologie (een extreem voorbeeld is de wizard), maar kunnen de gebruiker beperken of irriteren.
• De grootste ontwerpfouten in applicaties:
  • Gebruiken van niet-standaard controls
  • Inconsistentie
  • Geen indicatie van speelruimte die de gebruiker heeft
  • Geen feedback geven
  • Slechte foutmeldingen
  • Cancel/reset-knop op webformulieren
  • Gebruikers in een app ‘dumpen’ zonder introductie
  • Geen default waarden instellen
  • Vragen om reeds bekende gegevens
  • Niet aangeven hoe informatie gebruikt zal worden
  • Features op basis van systemen in plaats van de gebruikersbehoeften
• Zorg voor een gemakkelijk eerste gebruik. Beginners hebben hulp nodig, gevorderden moeten willen terugkomen, en mensen zijn gewoontedieren: als ze eenmaal een bepaalde manier van werken hebben aangeleerd, zullen ze het zo blijven doen in plaats van alsnog een meer efficiënte methode aan te leren.
• Het eerste gebruik kan worden vergemakkelijkt door introductieschermen of tips, die door gevorderde bezoekers kunnen worden uitgezet of die alleen tijdens het eerste bezoek verschijnen. Plaats ook wat voorbeelddata in de applicatie.
• Zorg dat het gevolg van een actie duidelijk is. Herlaad niet de complete pagina; daardoor wordt het moeilijker de verschillen tussen voor en na te zien.
• ‘Design Charrettes’ is een methode voor het snel verkrijgen van goede ideeën. Houd eerst een groepsdiscussie waarin het doel, de gebruikers en hun taken worden besproken. Laat daarna iedereen individueel een schets maken, die daarna gezamenlijk worden besproken en waar de beste ideeën uit worden gehaald.
• Laat een wizard aansluiten bij het conceptuele model van de gebruiker (bijvoorbeeld in welke volgorde iets wordt gedaan), onthoud de invoer wanneer gebruikers heen en weer bladeren, vervolg de wizard automatisch na opnieuw opstarten en plaats de volgende/vorige-knoppen altijd op dezelfde plek.
• Gebruikers wachten liever aan het eind van een taak op het systeem, dan halverwege.
• Gebruik alleen schuifbalken om een waarde te selecteren, als de selectie niet zo heel precies hoeft te zijn.
• Laat de gebruiker niet zelf op refresh klikken om te zien of er iets gebeurd is.
• Maak onderscheid tussen notifications (vereisen geen actie) en alerts (actie nodig). Zorg dat niet cruciale alerts niet net zo veel aandacht trekken als cruciale alerts.
• Pas op met switchen tussen verschillende modussen. Gebruikers begrijpen ze vaak niet, weten niet dat ze erin zitten, hoe ze er weer uit kunnen komen, waarom een bepaald commando niet beschikbaar is, etc. Zorg o.a. dat een andere modus er visueel anders uitziet.
• Observeer gebruikers, vraag hen niet hoe ze een bepaalde taak uitvoeren of hoe ze denken dat het beter kan. Ze zijn niet in staat om het goed te omschrijven of om een goede oplossing te bedenken. Ze zeggen het ene en doen het andere. Observeer bij voorkeur in de daadwerkelijke werkomgeving – daar hebben mensen spiekbriefjes, moeten ze documenten erbij pakken, of worden ze gestoord tijdens de taak.
• Een applicatie moet zowel voor beginnende als gevorderde gebruikers geschikt zijn. Maak bijvoorbeeld gebruik van een ‘tip of the day’, sneltoetsen, en bied naast enkele voorgeprogrammeerde opties de mogelijkheid om zelf alle instellingen te kiezen. Definieer verschillende rollen / toegangsniveaus met meer of minder opties. Denk eraan dat dezelfde persoon wat betreft de ene taak een beginner kan zijn, maar een gevorderde wat betreft een andere taak.
• Customization: de gebruiker past zelf zijn instellingen aan. Personalization: het systeem probeert in te schatten wat de gebruiker wil.
• Wanneer de applicatie internationaal moet worden gebruikt, reserveer dan 30%-50% extra ruimte in de user interface voor vertalingen waarbij de woorden langer worden, zowel wat betreft de UI-teksten als wat betreft de control labels. Bedenk dat sommige tekens niet (makkelijk) beschikbaar zijn op andere toetsenborden.
• Houd rekening met accessibility richtlijnen, ten behoeve van mensen met problemen op het gebied van motoriek, cognitie (bv. slecht geheugen), zicht (kleurenblindheid!) of gehoor.

Intranet usability

Voor deze sessie gold hetzelfde als voor de sessies over mobile usability: er werden wel nuttige adviezen over het ontwikkelen of verbeteren van een intranet gegeven, maar een groot deel daarvan waren algemene usability richtlijnen die ook voor websites gelden (vul formulieren vast voor zo ver mogelijk in, toon waar je bent in de site, etc.). Naast de vele tips, kregen we ook een rapport met enkele intranet usability onderzoeken, zodat we zelf onderzoek kunnen doen naar ons eigen intranet en de resultaten kunnen vergelijken, om meer budget, tijd, mensen en/of belangstelling ervoor te verkrijgen.

Specifieke tips voor je intranet waren onder andere:

• Als je overweegt om nieuwe intranetsoftware aan te schaffen, vraag dan om demoversies en voer hier gebruikerstesten mee uit, om een goede keuze te kunnen maken.
• Ook goede intranetten kunnen verslechteren, omdat organisaties continu veranderen.
• Blijf je intranet continu promoten.
• Zorg voor enkele ‘killer apps’: onderdelen die er voor zorgen dat men het intranet gaan gebruiken.
• In tegenstelling tot websites, mag je op intranetsites wel het bedrijfsnieuws prominent op de homepage plaatsen.
• Dwing gebruikers niet om meerdere wachtwoorden te onthouden. Log ze bijvoorbeeld automatisch in op het intranet wanneer ze op hun computer inloggen.
• Als je een gebruiker automatisch uitlogt na het verlopen van de sessie, toon dan een ander scherm dan het normale inlogscherm. Leg uit wat er gebeurd is en waarom.
• Naast een intranetbrede zoekfunctie, mogen er ook specifieke zoekfuncties zijn. Bijvoorbeeld een zoekfunctie voor medewerkers of gedeelde werkdocumenten.
• Plaats op persoonlijke profielpagina’s ook informatie over wie de manager en/of secretaresse is en op welke dagen de persoon bereikbaar is, aan welke projecten hij werkt, wat zijn plek in het organogram is en eventueel welke talen hij spreekt.
• Kies liever voor een menu-indeling op basis van taak in plaats van op basis van afdeling.
• Plaats content liever in html-vorm, niet als .doc of .pdf.
• Laat gebruikers helpen bij het aanvullen en onderhouden van de content. Zo blijft alles meer up-to-date en creëer je betrokkenheid. Door o.a. content te controleren, goede aanwijzingen te geven bij velden en training te geven, help je de gebruikers goede content aan te leveren. Denk ook aan het toevoegen van velden voor een einddatum en review datum, waarna de content automatisch wordt verwijderd, of de auteur een seintje krijgt dat de inhoud mogelijk moet worden herzien.
• Geef auteurs feedback over wat er niet goed gaat, maar ook welke content populair of succesvol is.
• Gebruik call-to-actions om lezers te stimuleren comments achter te laten. Anonieme comments horen niet thuis op een intranet.
• Ook op een intranet is bedrijfsjargon ongewenst.
• Ga na of je ook een mobiel intranet nodig hebt. Vragen die daarbij een rol spelen:
  • Hebben de medewerkers een smartphone? Zakelijk of privé? Hebben ze een limietloze internetbundel?
  • Is de content nodig wanneer men onderweg is? Zo ja, welke?
  • Welke gebruikers moet je ondersteunen en welke apparaten?
  • Moet je voor een app of mobiele site kiezen?
  • Is het veilig genoeg om alle documenten mobiel toegankelijk te maken?
  • Moet je data lokaal op de telefoon opslaan, of via een (mogelijk traag) netwerk laden?

Conclusie

Alle sessies hadden goede sprekers, met een hoop inhoudelijke tips en veel voorbeelden uit de praktijk, zowel in de vorm van screenshots als filmpjes uit gebruikerstesten. Vooral die laatsten spraken erg aan en maakten de stof minder droog. Ook werden er tijdens iedere sessie wel één of meerdere opdrachten gegeven, die je met een klein groepje moest uitvoeren. De overkoepelende boodschap kwam eigenlijk altijd neer op: test, test, test.

Ondanks de hopen informatie die tijdens de dagen over ons werden uitgestort, was het algehele gevoel (van mij, maar ook van de meeste andere deelnemers die ik sprak), dat het goede sessie waren, maar dat ze inhoudelijk nog wat diepgaander hadden mogen zijn. Zeker voor het geld dat je betaalt om erbij te mogen zijn. Diverse mensen merkten op dat ze dan liever een minder (extreem!) luxe lunch en tussendoortjes zouden willen, als daarmee de prijs omlaag kan. Eigenlijk is die reactie wel bijzonder. Want objectief gezien werden er echt wel veel praktische, direct bruikbare tips gegeven. Is het gewoon een teken dat veel deelnemers tot de categorie ‘gevorderd’ in het vakgebied behoren? Of wellicht wekt de naam ‘Nielsen & Norman’ en de bijbehorende prijs, dermate hoge verwachtingen, dat ze bijna niet kunnen worden waargemaakt?

Wat mij betreft is de Usability Week nog steeds aan te raden, vooral voor mensen die nog niet zo heel veel weten van het vakgebied. Want het is absoluut niet zo’n congres waar je alleen maar komt om te netwerken en/of salespraatjes aan te horen, maar juist om bruikbare, inhoudelijke kennis op te doen.