Usabilitytesting: doe het zelf!

We zijn verliefd op de eindgebruiker, zeggen we wel vaker bij Q42. Maar is die liefde niet vooral platonisch? We denken de eindgebruiker te kennen, maar is dat wel zo? Weten we hoe echte mensen de producten gebruiken die we als internetbureau voor onze opdrachtgevers ontwikkelen?

In sommige van onze ontwikkeltrajecten wordt al onderzoek gedaan, zoals bij de Lotto-website en de 9292-app. Als pleitbezorgers van gebruikersfeedback juichen we dat enorm toe. Maar veelal is er geen budget voor een researcher in een project. Of slechts voor een korte periode. En als er al contact is met echte eindgebruikers, is dat vaak in de vorm van een eenmalige usabilitytest, net voor de lancering van een nieuw product.

Hoe zorgen we dan dat we als developers niet voortdurend hoeven terug te vallen op ons inlevingsvermogen in de eindgebruiker? Immers, bij echte lean productontwikkeling hoort vroegtijdig en snel falen. Bij voorkeur door ideeën continu te valideren bij echte eindgebruikers. Alleen zo is het mogelijk om bij te sturen en producten te verbeteren met software-aanpassingen.

Een dergelijke consistente, structurele manier van usabilitytesting tijdens ontwikkeltrajecten is iets wat we al heel lang willen bij Q. Maar hoe organiseer je dat als internetbureau vol engineers? Hoe leer je op een snelle, laagdrempelige manier, wat een eindgebruiker van jouw product vindt, zonder steeds een onderzoeksbureau in te huren? Dan doe je het natuurlijk zelf! In deze blogpost leggen we uit hoe dit werkt bij onze Real User Mornings, oftewel: de RUM — pun intended.

Wat de RUM inhoudt
Bij Q’er Mathijs zat het al langer dwars, dat het ons tijdens de ontwikkeling van softwareproducten ontbrak aan een handige en laagdrempelige manier om gebruikersfeedback te verzamelen. Geïnspireerd door de Real World Wednesdays van het Dropbox Design Team, spande hij samen met Johan voor het opzetten van een tweemaandelijkse speeddate met vijf, steeds verschillende eindgebruikers die op onze Haagse vestiging ieder een aantal apps en websites komen reviewen onder begeleiding van Q’ers, designers en product owners. De opgedane inzichten kunnen we vervolgens gelijk verwerken dan wel samen met de product owners op de backlog plaatsen — natuurlijk met meer blije gebruikers van onze apps en websites tot gevolg.

Aanpak
Hoe pak je zoiets aan? Twee weken voor een Real User Morning organiseert Johan, die als accessibility engineer veel ervaring heeft met gebruikstesten, een introductie. Wat test je? Welke inzichten kun je opdoen? Tijdens deze voorbereiding houden we een oefensessie waarin we testscenario’s voor de speeddates bedenken en doorlopen. Uitgangspunt daarbij is steeds een feature of een flow in een app of website, zoals:

• Koop een Staatslot.
• Maak een playlist met je favoriete nummers in de Primephonic-app.
• Zoek naar je favoriete kunstwerk op de Rijksmuseum-site en bewaar een uitsnede daarvan.

Daarna rekruteren we via respondenten.nl een vijftal eindgebruikers voor de te testen projecten: gebruikers uitnodigen gaat niet alleen veel sneller via een marktonderzoeksbureau, maar geeft ook meer mogelijkheden hen op basis van hun achtergrondkennis te selecteren.

Voor de ochtend zelf zorgen we dat de respondenten welkom worden geheten door de betrokken Q’ers, dat de ruimte is voorbereid (drinken en wat lekkers, bordjes met de verschillende projecten) en dat de juiste testdevices (verschillende telefoons, tablets en laptops met muis) klaarliggen. Na een beknopte introductie beginnen de testrondes.

Voordat de eerste speeddate start, vertellen we iedere respondent kort wat er getest gaat worden. Tijdens de usabilitytest wordt er vervolgens gekeken, wat zij/hij doet en wordt gevraagd wat haar/zijn gedachtegang is. Eén Q’er stelt de vragen en de ander (Q’er, product owner dan wel designer) helpt met het observeren en opschrijven van wat er feitelijk gebeurt. Ook worden de sessies opgenomen om de resultaten te kunnen delen met andere Q’ers en stakeholders van de opdrachtgever.

Nadat de respondenten per project 15 minuten hebben getest, wordt dit deel van de ochtend afgesloten en houden de betrokken Q’ers, designers en product owners een wrap-up sessie. Per project worden de belangrijkste vijf inzichten opgeschreven en bepaald wat daarmee gedaan gaat worden. Deze learnings worden ook nog even gezamenlijk gedeeld en er wordt een korte evaluatie van de RUM gehouden.

Wat testen we tijdens een RUM
Onze Real User Mornings zijn laagdrempelige, korte testsessies die regelmatig op consistente wijze worden gehouden. Ze zijn daarom bij uitstek geschikt om snel iteratieve feedback te krijgen en te valideren of bepaalde aannames kloppen. Denk daarbij aan:

• Begrijpen gebruikers de geteste feature of flow?
• Is de copy eenduidig?
• Snappen gebruikers de onboarding van een app?

Zo bleek tijdens het testen van de Primephonic-app, dat veel mensen afhaakten, doordat de login direct aan het begin was geplaatst. Zij wilden eerst de app bekijken, voordat ze moesten inloggen — iets wat ons onderbuikgevoel ook al had aangegeven, maar waarvoor we tot nu toe geen bewijs hadden.

Bij de website van het Rijksmuseum hadden testers juist moeite met de copy. Die bevatte veel museaal jargon dat verder niet werd uitgelegd, zoals ‘bloktijden’. Voor zulke issues raken teamleden op een gegeven moment blind — totdat meerdere gebruikers hen daarop wijzen. Het is redelijk eenvoudig om dit op te lossen door dergelijke teksten meer vanuit de bezoeker te schrijven.

Deze manier van feedback verzamelen is dus heel geschikt om onduidelijkheden en verwarrende situaties naar boven te halen. Bij de vraag om een groot pakket te versturen, selecteerden alle testers van onze PostNL-app bijvoorbeeld voor ‘brievenbuspakket’, terwijl het betreffende pakket helemaal niet door een brievenbus zou passen. Dergelijke missers zijn vaak makkelijk aan te passen vanwege hun beperkte impact. Het is ook bij uitstek een methode om (onontdekte) gebruikersvragen en -problemen te signaleren, waarbij nog niet duidelijk is, of het om structurele issues gaat. In dat geval kan bijvoorbeeld kwantitatief onderzoek meer helderheid bieden.

Grotere issues met veel impact moeten dus geprioriteerd worden voor een later moment of verder onderzoek. Met de RUM gaan we niet de diepte in. Het is geen A/B-test noch een methode om belangrijke productbeslissingen te nemen.

Meerwaarde
De speeddates blijken voor ons heel goed te werken en binnen de teams veel enthousiasme op te leveren. Het is niet alleen een uitstekende remedie tegen niets doen — wat vaak voorkomt als er geen researcher of onderzoeksbureau kan worden ingeschakeld. Onze Real User Morning biedt vooral een snelle en laagdrempelige methode om er achter te komen of we het juiste aan het bouwen zijn door ons werk frequent en structureel te onderwerpen aan de blik van de eindgebruiker.

Deze donderdagochtenden helpen ons zo om vroegtijdig verwarrende features en content te identificeren — en daarna de oplossing te valideren tijdens een volgende sessie. Uiteindelijk besparen we zo geld. Immers, een voltooide feature ombouwen kost altijd meer tijd dan vroeg in het proces een aanpassing doen.

De uren die we in de Real User Morning steken, betalen zich dan ook dubbel en dwars uit. Helemaal in vergelijking met een onderzoeksbureau waarmee een dergelijke testfrequentie snel in de papieren gaat lopen. Dat betekent echter niet, dat we uitgebreide usabilitytests door een onderzoeksbureau nu overbodig achten. Integendeel. De RUM biedt juist een mooie aanvulling door beter zicht te geven op de onderdelen waar kwalitatief onderzoek of A/B-testing waardevol is.

Dankzij de RUM is het vragen van feedback aan gebruikers niet meer een extraatje maar echt geïntegreerd in het ontwikkelproces. Door het in huis halen kunnen alle teamleden makkelijk aanhaken, waardoor er ook minder ruis ontstaat bij het evalueren van de uitkomsten. De RUM heeft zodoende binnen Q42 nog meer bewustzijn gecreëerd voor gebruiksonderzoek.

Nadelen en uitdagingen
Hoe positief we ook zijn, onze aanpak is niet geschikt voor alle issues tijdens productontwikkeling. Of er een product/market fit is, haal je er niet uit, evenmin als missende of gewenste features.

Ook kan het soms lastig zijn daadwerkelijk in actie te komen naar aanleiding van dergelijke tests. Zeker omdat het initiatief van de RUM bij ons als engineers vandaan komt: de prioriteit ligt voor een product owner niet altijd bij de gevonden issues. Als haar managementteam besluit een gebruiksonderzoek te doen, is prioritering vaak veel makkelijker.

Het is dus een uitdaging van onze aanpak om ervoor te zorgen dat de product owner daadwerkelijk aan de slag gaat met de uitkomsten. De resultaten evalueren en omzetten naar praktische en concrete oplossingen helpt daarbij, al is dat geen eenvoudige opgave, zeker bij complexere issues.

Tot slot kan een nadeel van onze aanpak zijn, dat we ons eigen vlees keuren. Doordat we zelf vaak trots zijn op de producten die we maken, zou ons oordeel onzuiver kunnen zijn. We voorkomen dit door extra aandacht te besteden aan het neutraal stellen van vragen in de training vooraf. En natuurlijk door het meermaals uitvoeren van de Real User Mornings. Op die manier bouwen we ondubbelzinnige bewijslast op — wat de noodzaak om een usabilitybureau in te schakelen alleen maar evidenter maakt.

Wat we geleerd hebben tot nu toe
Een van de redenen om zelf structureel in huis te testen is omdat we graag op een snelle en laagdrempelige manier willen leren hoe we door ons ontwikkelde producten beter kunnen maken. Door naast Q’ers ook designers en product owners erbij te halen, zijn alle disciplines betrokken en hoeven we weinig kennis over te dragen. Met het organiseren van de RUM’s ontzorgen we bovendien product owners die de testresultaten kunnen terugkoppelen binnen hun organisatie om stakeholders te overtuigen van de noodzakelijke verbeteringen.

Tijdens de RUM word je in ongeëvenaard tempo met je neus op de feiten gedrukt. Er is altijd een gat tussen jouw idee of ontwerp en de ervaring van een echte eindgebruiker. Het format van de RUM zorgt ervoor dat je die waarheid snel en vaak te horen krijgt, waardoor je direct concrete actie kunt ondernemen om jouw app te verbeteren. (Vincent de Boer, product owner Primephonic)

Nu we een aantal gebruiksochtenden hebben georganiseerd, zijn daarom niet alleen wij zelf maar ook de betrokken product owners erg enthousiast over onze aanpak. Daarbij hebben wij vooral deze inzichten opgedaan:

• Het is natuurlijk een bekend mantra maar het is echt waar: hoe vroeger je een product test, des te beter.
• De laagdrempeligheid maakt het voor iedereen behapbaar. Structureel en iteratief testen is daarmee een krachtiger middel dan af en toe een usabilitybureau inhuren — wat overigens nog steeds meerwaarde heeft, zoals hierboven aangegeven.
• Het is essentieel dat de product owner en eventueel designer bij de tests aanwezig zijn. Zeker een PO moet het ongemak, de pijn van foute keuzes voelen om de testresultaten verder uit te kunnen dragen in zijn of haar organisatie. Het louter doorvertellen van testresultaten is echt minder effectief, hebben we gemerkt.
• Maak opnames van de tests. Niet alleen voor als een product owner er niet bij kan zijn, maar ook om haar/hem bewijslast mee te geven naar stakeholders.
• Focus op een beperkt aantal verbeterpunten en zorg dat ze worden afgestemd met de product owner. Eenvoudige issues kunnen direct worden opgepakt, meer complexe verbeterpunten moeten op de backlog worden gezet.
• En als laatste: het is gewoon leuk! Niet alleen doordat we samen op een laagdrempelige en structurele manier werken aan het valideren van aannames en het verbeteren van producten. Maar ook omdat we leren, hoe buitenstaanders onze producten gebruiken en hoe je op een goede manier test.

De opzet van onze RUM is expres zo, dat elke Q’er mee kan doen. Alhoewel wij geen designers, UX’ers of researchers zijn, kunnen we binnen een dergelijk framework prima achterhalen, hoe echte gebruikers onze producten ervaren.

More RUM’s to follow
Nu we enkele RUM’s achter de rug hebben (onder andere met blinde en slechtziende testers), zijn we nog steeds erg enthousiast. Aanstichters Mathijs en Johan hebben inmiddels een draaiboek met een uitgebreid stappenplan opgesteld. Zodoende kunnen andere Q’ers hen aflossen in het organiseren van onze speeddates: door de organisatie te rouleren spreiden we de kennis en maken we onze Real User Morningy steeds beter. Alle verbeterpunten worden bovendien in het draaiboek verwerkt voor een volgende keer.

Kortom: wij zijn buitengewoon blij met de gekozen aanpak. De RUM blijkt voor ons een perfecte oplossing om op een laagdrempelige en frequente wijze gebruikersfeedback te verzamelen en zo onze producten continu te verbeteren. Door het usabilitytesten in huis te halen en echt te integreren in het ontwikkelproces kunnen we nóg gerichter en sneller bouwen aan de juiste software voor onze klanten.

En onze liefde voor de eindgebruiker? Die is er alleen maar door gegroeid!

Meer tips over hoe je zelf gebruikstesten organiseert? Lees de blogposts van Dropbox en Nielsen Norman Group, vraag Johan om ons draaiboek met alle stappen of luister naar onze Q42 podcast waarin experts Miel de Zwart van Valsplat en onze eigen Roelf-Jan vertellen hoe je op een laagdrempelige manier test tijdens productontwikkeling.