Om te kunnen boeken bij sneleentaxi moet javascript aan staan.

User Experience verbeteringen op sneleentaxi.nl

Van idee naar uitvoering, enkele voorbeelden uit onze verbeteringen aan het platform.

In dit artikel neem ik je mee naar een aantal veranderingen die we hebben doorgevoerd op onze nieuwe site sneleentaxi.nl, het boekingsplatform voor taxi's in héél Nederland. In dit artikel ga ik met name in op User Experience.

Mocht je de eerste post hebben gemist, lees dan zeker even het eerste artikel hier terug. In totaal zijn er enkele honderden aanpassingen gedaan, van op het eerste gezicht nietszeggend tot enorm ingrijpende veranderingen. Hieronder enkele grote winnaars van deze aanpassingen.

Mobiele boekingsmodule aangepast

User Experience verbeteringen op sneleentaxi.nlUser Experience verbeteringen op sneleentaxi.nl

Inlogknop toegevoegd: in het oude design diende je eerst het hamburger menu uit te klappen voordat je kon inloggen. Hierdoor ging een groot gedeelte van onze users die een account hadden aan deze stap voorbij, en kwamen ze er later in het bestelproces pas achter dat zij nog niet waren ingelogd. We moesten hen dan confronteren met een 'foutmelding' dat hun e-mailadres reeds bekend was, met opnieuw de vraag om in te loggen. Iets dat de boekingservaring minder prettig maakte. We hopen die stap nu vaker voor te zijn.

Tekstuele aanpassingen: we hebben de teksten op de website overal aangepast. We willen meer inspelen op het gemak en op de ervaring. Een vraag over waar je heen wil gaan leeft meer bij onze doelgroep dan een loze tekst over 'je taxirit'. Ook de kop is aangepast.

Kleurgebruik: in onze nieuwe versie wordt de combinatie paars/groen vooral gebruikt. Daardoor is ook de knop "Bereken mijn ritprijs" groen gemaakt en tevens gecentreerd tekstgebruik om hem nog meer te laten opvallen.

Andere placeholders: in plaats van het harde gebruik in de vorige versie van de 'van' en 'naar' hebben we gekozen om dit volledig met placeholders te vervangen, voor een veel rustigere ervaring binnen het boekingsproces. Binnenkort starten we een nieuwe a-b test omdat uit onze analyses hier toch af en toe problemen door ontstaan en mensen direct in het eerste veld het adres invoeren waar zij naar toe willen.

Verwijderen van chatfunctionaliteiten op mobiel: eerder is er gekozen om support via de chat op mobiele schermen niet te ondersteunen. De plaatsing van deze gele 'chatknop' was altijd problematisch, omdat deze de boekingsknop in de weg zit. We willen support hierin iets meer ontlasten en denken dat het op mobiel dusdanig eenvoudig is geworden om te boeken, dat binnen deze eerste stap van het boekingsproces een chatfunctie nog teveel afleidt.

Ondanks dat we veel hogere conversie hebben weten te realiseren met het vernieuwde design, zijn er nog genoeg kansen om deze nog verder te verbeteren. We zullen deze boekingsmodule blijven testen en optimaliseren.

Verbetering in conversie van het drukken op de knop 'bereken mijn ritprijs' t.o.v. de oude situatie: 33%

Het reduceren van het aantal bevestigingen bij een retourrit:

Aangezien wij onze chauffeurs zo optimaal mogelijk inzetten, is het doorgaans eerder regel dan uitzondering dat bij het boeken van een retour-rit onze passagiers twee vervoerders krijgen toegewezen. De vervoerder van de heenrit is dus meestal verschillend t.o.v. de vervoerder van de terugrit.

Voorheen stuurden wij hiervoor twee aparte e-mails. Technologisch een stuk eenvoudiger, aangezien we na een succesvolle veiling direct vervoerder en reiziger met elkaar konden koppelen. In de praktijk echter niet altijd even duidelijk voor onze reizigers, aangezien diverse e-mailprogramma's dezelfde soort mails wel eens wil rangschikken en een vergelijkbare mail dus soms 'weggestopt' wordt door het mailprogramma.

User Experience verbeteringen op sneleentaxi.nl

Gevolg was dat reizigers dachten dat ze door dezelfde vervoerder zowel heen- als teruggebracht werden en ze niet altijd de juiste telefoonnummers tot hun beschikking hadden. Reizigers en vervoerders liepen elkaar soms mis (sorry nog daarvoor! :)). Iets wat natuurlijk enorm veel druk legt op onze support afdeling, tot ergenis bij reizigers leidt en de vraag over wie de rekening ging betalen niet altijd even makkelijk te beantwoorden was.

In de nieuwe versie wachten wij met het versturen van een bevestiging tot beide partners de rit hebben geaccepteerd. We sturen nog maar één mail met daarin de gegevens van beide vervoerders. Technologisch gezien ingewikkelder dan het klinkt. Er zijn zoveel uitzonderingssituaties waar we rekening mee moeten houden met het sturen van de juiste informatie. Bijvoorbeeld bij iemand die een retourtje heeft geboekt en een wijziging wordt aanvraagt voor twee ritten. Het is heel goed mogelijk dat de vervoerder van de heenreis binnen een paar minuten reageert dat deze wijziging akkoord is, maar de vervoerder van de terugreis hier pas na 30 uur op reageert. In de tussentijd dienen we de klant wel op de hoogte te houden, zonder de reiziger te veel mails te sturen. En dus is timing van de mails enorm belangrijk, wat we afvangen door de juiste tijd te wachten tot alle informatie beschikbaar is.

'Niet alleen de ontwikkeltijd berekenen, maar vooral ook nadenken wat het doet met de schaalbaarheid van het platform.'

Het geeft een inkijkje in hoe eenvoudig sommige ideeën lijken, maar hoe ingewikkeld deze te integreren zijn. We ontwierpen dit soort processen met behulp van Lucid Charts (UML diagram). Uiteindelijk is de situatie er een stuk prettiger op geworden voor de reiziger, maar bij ons aan de achterkant een stuk complexer. Met elke nieuwe functionaliteit moeten wij meer unittests schrijven, zodat ook deze blijven werken in alle nieuwe omstandigheden. Door deze toe te voegen, dienen we niet alleen de ontwikkeltijd te berekenen - maar vooral ook goed af te wegen wat het voor de rest van het platform betekent, en hoe complexiteit schaalbaarheid in de weg staat. In dit geval een voor ons onmisbare feature, maar wel één waarvan we ons bewust zijn van de nadelen.

Reductie van foutmarge van ritten die door verwarring van twee mails resulteerden in een contactmoment of zelfs tot een no-show : 44%

Het eeuwige gevecht met Google Suggestions API

Om het invoeren van adressen zo eenvoudig mogelijk te maken, gebruiken wij de API van Google. Een keuze die niet zonder gevolgen is voor de rest van het boekingsproces. Ondanks alle data van Google zijn de adressen die zij teruggeeft niet altijd accuraat. Nieuwe postcodes zijn niet altijd even snel toegevoegd, en ook komen er soms adressen terug met onjuiste postcodes of andere gekke uitzonderingen die het voor ons lastig maken om te valideren of een adres juist is of niet.

Voorheen deden wij altijd een extra validatie op deze gegevens. We gebruikten hiervoor de API van postcode.nl die ons vertelde dat een adres simpelweg niet bestaat, terwijl Google hier geen melding van maakte. Hierdoor kwamen onze reizigers geregeld in een padstelling terecht, want hun ingevulde adres kon niet gevalideerd worden en we gaven een error melding terug tot het juiste adres ingevoerd was. Wanneer dit een thuisadres was, lukte het de reiziger vaak nog wel om met behulp van de juiste postcode of kleine aanpassing van wat gegevens alsnog het goede adres in te voeren. Als het adres voor de reiziger echter ook een 'nieuw' adres was (bijvoorbeeld een populaire bestemming als "Cruise Terminal Amsterdam") en Google gaf een foutmelding terug, bleek dit een extreem grote conversie-killer. Onze bezoekers gaven bij deze foutmelding gemiddeld na een minuut of 18 (och, arme zielen) toch wel op, en kozen voor een van onze concurrenten.

User Experience verbeteringen op sneleentaxi.nl

We zaten echter wel met ons handen in het haar. Hoe gaan we precies om met het invoeren van 'onjuiste' adressen? En wat waren nou exact 'onjuiste adressen'? We besloten om de laatste vraag eens goed in kaart te brengen en vooral goed te loggen op welke adressen mensen afhaakten. In de praktijk bleek het echt een kakafonie aan ingevoerde zaken te zijn.

Voorbeelden waren bijvoorbeeld een flatgebouw waar mensen op nummer 212 woonden, terwijl postcode.nl ons terugkoppelde dat het officiële nummer 1 was (1-512, maar 1 was leidend voor het adres). Maar ook adressen die écht afwijken van een standaard invoer, zoals jacht 'Het Witte Kolos' - in de Havenstraat, waar geen nummer ingevoerd werd.

Na lang soebatten bleek de oplossing eenvoudiger dan het volledig automatiseren van onze ideeën. In een digitale wereld waarin je alleen maar aan schaalbaarheid en 'correctheid' van gegevens denkt, is het soms goed om even na te gaan of het doel de middelen nog wel heiligt. Iemand opperde om gewoon eens een weekje deze adrescheck los te laten, en de chauffeurs gewoon de letterlijke input terug te geven - ook al zou deze volgens alle databases niet altijd kloppen. Mocht er iets misgaan dan zal de chauffeur altijd wel contact opnemen met onze klant - of met ons - en vaak begrijpt een chauffeur wel dat 'Schiphol Passengers Terminal' (die compleet andere postcodes terug kan geven als Luchthaven Schiphol zelf) ook Schiphol betekent.

We gaven het een week een kans en in die gehele week ging er eigenlijk niet één invoer mis. Vergeleken met het aantal afhakers van boekingen in onze vorige versies een enorme verademing, en de druk op support werd niet eens aangesproken - al hadden we hier wel rekening mee gehouden. Soms is het dus even goed om bepaalde validaties los te laten, aangezien de techniek nog niet zover is dat alle adressen juist zijn.

Verhoging van conversies ten opzichte van de strenge check op de stap waarin wij nogmaals een echte validatie doen aan het juiste adres : 8%

In een volgende post op 29 augustus ga ik dieper in over de keuze van onze tooling en enkele integraties die we hebben verstevigd, en degene die we letterlijk overboord hebben gegooid. Ik vind het erg leuk om te horen of deze voorbeelden je helpen bij je eigen onderneming of aanzetten tot het anders nadenken over zaken.