INTERVIEW
Het belang van regelmatige user feedback in de ontwikkeling van het eerste proactieve mobile-only verzekeringsplatform
Titels zeggen hem niet veel, maar als ‘director’ is Joris Evendik verantwoordelijk voor de ontwikkeling van het eerste onafhankelijke mobile-only verzekeringsplatform. De app is het touchpoint van een platform dat mensen automatisch inzicht geeft in hun vaste lasten en proactief te helpen deze te verlagen. De implementatie van PSD2-technologie zal gebruikers van de app inzicht genereren over inkomsten en uitgaven. Daarnaast geeft de app de mogelijkheid om contracten te uploaden. Zo heeft de gebruiker alle verzekeringen en andere vaste contracten, zoals energie, bij elkaar op één plek. Door de markt vervolgens continu in de gaten te houden zal de app op basis van zeer gedetailleerde klantinformatie hyperrelevante aanbevelingen doen.
In een paar clicks nieuwe aanbiedingen ontvangen en een verzekering af kunnen sluiten. Of een telefoonabonnement of energiecontract bijvoorbeeld. Swift is een one-stop-shop voor al je vaste lasten. Een proactieve digitale financiële adviseur. En dat is er nog niet. Vooral omdat er nog weinig gebruikersdata beschikbaar is, is het belang van user feedback extra groot in de ontwikkeling van het platform. In dit klantverhaal leggen we uit hoe Swift werkt, op welke manier de Fibéo sprints in hun werkwijze passen en waarom ze voor Fibéo hebben gekozen.
De activiteiten van Swift en de vraag aan Fibéo:
De activiteiten van Swift en de vraag aan Fibéo: Swift werkt aan een internationaal platform en het ontwikkelteam zit in Riga. In eerste instantie zijn we zelf gaan testen via een remote testing tool. Dus testers werven, die interviews afnemen, aantekeningen maken, etc. Daar kwam heel veel waardevolle feedback uit, maar we merkten dat wanneer je als bedrijf zelf de test uitvoert, mensen al wat terughoudender zijn in de feedback die ze geven. Testers willen niet je kindje kwetsen als het ware. Het rapportcijfer bijvoorbeeld, die gebruikers aan de app geven, ligt gemiddeld een punt lager nu Fibéo de tests doet. Plus: we zijn erachter gekomen dat interviewen een vak apart is en dat volledige focus nodig heeft. Daarnaast is respondenten werven ontzettend tijdrovend.
FEEDBACK LOOP
Hoe past de feedback die jullie elke week krijgen in jullie ontwikkelproces?
We werken met een tweewekelijkse ontwikkelcyclus. Iedere twee weken releasen we. Dat zijn de sprints. Onderdeel van dat proces is de feedback van gebruikers. We proberen altijd 3 à 4 sprints vooruit te plannen. Iedere twee weken hebben we een ijkpunt waarop we kijken wat gebruikers op dat moment vinden van wat we gemaakt hebben. Als we zien dat daar hele duidelijke verbeterpunten in zitten, dan geven we dat een hogere prioriteit in de komende sprints.
Daarbij komt dat het gevaar met te veel dingen zelf doen is dat het proces an sich een doel wordt, terwijl je je eigenlijk wilt bezighouden met het doorvoeren van verbeteringen. Dat is waar het om draait. Dus volgens mij kan je beter gefocust zijn op die laatste stap en dat gaat het beste als je zeker weet dat je feedback kwalitatief goed is.
We zijn nog steeds van plan om af en toe interviews af te nemen om feeling te houden. Maar we merken dat de manier waarop de interviews opgezet worden, geanalyseerd worden en vooral de feedback en de adviezen in de Fibéo rapporten van een veel hoger niveau zijn. En we besparen dus een hoop tijd. Tijd die we hard nodig voor andere dingen.
Veel bedrijven doen user testing 1 keer per maand of 1 keer per half jaar, of alleen als ze een hele grote wijziging hebben. Maar dan mis je de controleslag. Je hebt wel een controleslag in data, maar je mist de bevestiging en ook de verfijn kans vanuit de volgende user test. Wij willen van iedere wijziging weten wat mensen ervan vinden.
Een ux-lab draaiend houden kost veel tijd. Maar een goede feedbackloop creëren is essentieel. Als je daar goed in getraind bent kan je dat veel efficiënter doen dan als je dat zelf als niet getrainde persoon gaat doen. Plus dat dat inplannen van testers op zich al lastig is. Wij hebben focus nodig, zoals ieder team nodig heeft. Dit is iets dat je heel goed kunt outsourcen omdat er meer voordelen aan zitten dat een externe partij het doet, dan nadelen.
Zo’n rapport is heel erg in your face.
Je kan zo’n rapport in vijf minuten zo’n rapport scannen en dan heb je een heel goed beeld van of je goed bezig bent of niet. Als we iets ontwikkelen dan moet de feedback goed zijn.
Uiteindelijk is onze missie het oplossen van een probleem voor gebruikers, namelijk dat ze geen inzicht hebben in hun vaste lasten, niet zo goed weten waar ze moeten beginnen. Dus we itereren net zo lang tot het wel goed is.
Dat is een hele agile werkwijze waarbij we volledig nieuwe functionaliteiten eerst in een prototype testen, vervolgens die feedback meenemen in het verbeteren van het prototype en dan dus gaan ontwikkelen, en als we het live hebben gebracht dan bouw je data op, van de gebruikers, waaruit blijkt of ze op de juiste manier interacteren met wat je hebt gemaakt, dus of ze er blij van worden en als dat positief is dan is dat goed, dan kun je door met het volgende, met de volgende module en als blijkt dat het voor verbetering vatbaar is dan ga je onderzoeken het beter kan en daar is kwalitatief onderzoek dan weer bij van doorslaggevend belang.
Zijn er sinds jullie met ons testen verrassingen tegen gekomen?
Ik heb eerder met Fibeo heb gewerkt, dus ik weet ongeveer wat ik kan verwachten. Ik vergelijking met onze analyses valt op dat we in onze eigen testen heel erg op de kleine dingen werd gelet. Dat komt omdat je zelf ook heel erg met details bezig bent, in productontwikkeling en dan ben je heel erg nieuwsgierig wat mensen over die details vinden. Dus je bent uiteindelijk op zoek naar bevestiging van je eigen aannames waardoor je (on) bewust het interview stuurt naar punten die jij dan net belangrijk vindt. Maar het is niet vanzelfsprekend dat dat ook is wat gebruikers belangrijk vinden, dus de kwaliteit van de feedback van Fibéo is beter. Het is onafhankelijker, frequenter en vooral de manier waarop het gepresenteerd wordt in een rapport is veel prettiger te verwerken voor de product managers.
Wie werken er binnen de organisatie met de Fibéo rapporten? Zodra we het rapport ontvangen dan delen we het met het kernteam, met wie we de productontwikkeling roadmap en planning bepalen. 1 keer in de twee weken komen we bij elkaar en dat zetten we het rapport op een groot scherm en dan gaan we het stukje voor stukje lezen en interpreteren. Aan de hand van wat we dan zien prioriteren we wijzigingen in de app, dus bepalen we de planning.
Fibéo’s rapporten zijn trouwens ook heel handig als je bijvoorbeeld eindverantwoordelijke ben, maar je bent niet day to day bezig met productontwikkeling. Er zijn altijd stakeholders die niet boven het proces zitten maar die wel heel graag willen begrijpen of het de goede kant op gaat met de product ontwikkeling. En de rapporten zijn daar heel erg geschikt voor.
Ik heb heel veel gezien in het verleden dat er heel veel wijzigingen werden doorgevoerd en dat er nooit statistisch bewijs kwam dat het werkte. Maar dan vonden de product owners/managers het wel een hele fijne verbetering. Het was niet aantoonbaar dat alle inspanningen die je daarvoor geleverd hebt een positieve impact hebben gehad. User testing is ook een controleproces dat heel duidelijk laat zien of je team of bedrijf de goede kant op ontwikkelt.
Waarom Fibéo. Ik ken Fibéo van eerdere projecten en Fibéo is van het kwaliteitsniveau dat we nastreven. Ik vind de korte lijnen, het informele en snelle contact in combinatie met professionaliteit bijzonder prettig. Flexibiliteit en informeel contact zijn voor ons belangrijk. Soms zijn we in die sprints zo druk zijn dat we soms een paar uur voor een interview bedenken dat iets verder uitgediept moet worden en dat is natuurlijk niet wenselijk maar dat kan dan wel. Feedback waar je blij van wordt en het zien als een verbeterkansen: wij zien Fibeo als een onderdeel van ons team.
Is er iets dat je zelf nog zou willen toevoegen? User test sprint rapporten zijn bijna zelfreflectie voor een product manager; is datgene dat ik bedacht heb eigenlijk wel goed? Of niet? En daarbij zou eigenlijk nooit een grote wijziging moeten doorvoeren, zonder daar eerst een prototype van getest te hebben. Daarom doen we één keer per maand een prototype test en drie keer per maand een productietest.