UX-case study
Achteraf betalen toevoegen aan een hotelboekingsflow
Findhotel had al kamers in het aanbod die een reiziger bij het hotel betaalt in plaats van bij de checkout. Wat ontbrak, was een manier om daar tijdens het boeken voor te kiezen. Dit is de eerste versie van die keuze, en het experiment van vijf weken dat mat wat die waard was.
De keuze, waar hij uiteindelijk terechtkwam: op de kamerselectiepagina, vóór de checkout. Niet waar ik hem wilde, en de reden daarvoor staat verderop.
Probleem
Waarom dit project?
Findhotel is een kleinere speler in accommodatie en bedient de gelokaliseerde markten die Booking, Expedia en TripAdvisor doorgaans laten liggen. Een groot deel van het aanbod is restvoorraad: kamers waarvan een hotel verwacht ze niet te verkopen en die het niet zelf kan aanbieden zonder door de grotere platforms lager te worden gezet. Betalen bij het hotel in plaats van bij de checkout is een van de dingen waarmee zo'n platform zich kan onderscheiden van de partijen erboven.
De business case stond dus nooit ter discussie. Al het andere wel. Een reiziger achteraf laten betalen betekende het juiste hotelaanbod verwerven, de afhandeling van boekingen herstructureren, en dan, helemaal aan het eind, iemand een manier geven om ervoor te kiezen. Dat laatste deel is waar deze case study over gaat, en het was lastiger dan het klinkt.
Het echte probleem was dat achteraf betalen duizend kanten op kon. Iedereen had een mening over hoe het eruit moest zien en wat in een eerste versie thuishoorde. Een feature invoeren over meerdere scrumteams heen is in elke organisatie lastig; het is aanzienlijk lastiger als van die feature verwacht wordt dat hij de conversie van het hoofdproduct beweegt, want dan heeft iedereen terecht een mening. Iets moest de knoop doorhakken.
Eén ding kan deze pagina je niet vertellen: wat een reiziger zei nodig te hebben, want dat heeft niemand opgeschreven. Wat er op papier staat is de commerciële onderbouwing, en het zou oneerlijk zijn om de andere helft nu te reconstrueren.
Doelen
Gewenst resultaat
We wisten dat de feature welkom zou zijn. Wat niemand wist, was hoezeer, en om dat gat heen is de eerste versie ontworpen.
Die drie zijn één doel met drie petten op. Een minimum viable product was hier geen manier om minder werk te doen; het was de enige manier om aan een getal te komen, en een getal was het enige dat het argument voor een tweede ronde kon kopen. Alles wat ik liever had ontworpen, stond daarop te wachten.
Team & publiek
Wie bouwde dit, en voor wie?
Samenstelling van het team
Onze product owner bracht de business case en de prioriteiten in. Onze data scientist bracht de cijfers waartegen de beslissingen werden genomen, en ontwierp de A/B-test zelf, wat meer uitmaakt dan het klinkt: een test die is ontworpen door de mensen die een bepaald antwoord willen, is geen test.
Een eigen copywriter schreef de teksten. Een extern bureau vertaalde ze. Ik was de enige designer op de feature, en de developers waren een scrumteam binnen een organisatie met meerdere teams.
Mijn verantwoordelijkheden
De concurrentie benchmarken, de ideatie- en scopingsessies van het team leiden, wireframen, een prototype bouwen dat low-fidelity genoeg was om over te discussiëren, het guerrillatesten, het resultaat omzetten in een ontwikkelplan, en de high-fidelity schermen tekenen tegen het design system.
Daarna: de teksten gericht houden op wat de test mat, de build met de hand testen tegen elk afgesproken scenario, echte sessies bekijken zodra het live stond, en het geheel opschrijven voor collega's die er nooit bij waren.
Publiek
Voor wie bouwen we dit?
Eerst Engelstaligen, en die beslissing werd voor ons genomen. Het vertaalsysteem was destijds zo traag dat nieuwe teksten er in de weken die we hadden doorheen duwen niet realistisch was, en er werden sowieso meerdere verfijningsrondes verwacht.
De eerste weken van de test gingen dus alleen in het Engels live. Een Engelstalige reiziger zag de hele flow in de eigen taal. Een Koreaanse, Thaise of Deense reiziger zag de rest van de site in de eigen taal en de terminologie voor achteraf betalen in het Engels, wat werkelijk vreemd is om iemand midden in een aankoop voor te schotelen. Wat het verdedigbaar maakte, was de samenstelling van het publiek: Amerikaanse gebruikers zijn met afstand de grootste groep op het platform, dus de mensen die de feature volledig zouden zien waren ook de mensen die hem het vaakst te zien kregen.
Scope en beperkingen
Beperkingen
Drie beperkingen bepaalden dit meer dan welke ontwerpbeslissing van mij ook.
De eerste is die hierboven: teksten in twee talen midden in een checkout, voor iedereen buiten het Engels.
De tweede was de zoekpagina. Als een hotel achteraf betalen ondersteunde, hoorden de zoekresultaten dat te melden, en daar beslist een reiziger welk hotel hij opent. De zoekpagina hoorde bij een ander deel van de organisatie en kon niet op tijd worden aangepast voor de test. Het gevolg is het waard om ronduit te benoemen, want het komt aan het eind van deze pagina terug: een reiziger die op Findhotel zocht, zag in de resultaten aanbiedingen met achteraf betalen van Booking, Agoda en Expedia, en geen enkele van Findhotel, ook waar Findhotel ze wél had.
De derde was de checkoutpagina, waar een technische beperking in de architectuur alles behalve minimale wijzigingen uitsloot. Daarmee vielen verschillende ontwerpen af die ik liever had gezien, en bleef er precies één plek over waar een reiziger de keuze kon maken: de kamerselectiepagina. Iemand vragen zich aan een betaalschema te binden voordat hij de checkout heeft bereikt, is op zijn best vreemd. Het was de versie die kon worden opgeleverd, en iets meetbaars opleveren was het hele punt.
Proces
Stap voor stap
Wat volgt is één versie van één feature, niet de geschiedenis van achteraf betalen bij Findhotel. Het is de eerste, en degene die de rest moest verdienen.
Scenario's in kaart brengen
Vóór al het andere een ruwe kaart van wat een reiziger kon doen en wat er dan zou gebeuren. Geen flow van het happy path: een spreiding van de uitkomsten, inclusief die niemand wil.
De reden om dit eerst te tekenen is dat het ontwikkelplan later niet beter wordt dan dit. Scenario's vooraf in kaart brengen is hoe randgevallen ontwerpbeslissingen worden in plaats van bugs die in de laatste sprint opduiken. Het vangt niet alles, en deze ook niet.
Elke interactie, en wat daaruit volgt. De randgevallen zijn het punt van deze tekening, niet het midden.
Concurrentiebenchmark
Elke grote speler in accommodatie, en verschillende kleinere, scherm voor scherm uit elkaar gehaald. Het doel was een set bevindingen waar het team iets mee kon: waar de branche op was uitgekomen, waar de gaten zaten, en welke van onze argumenten al waren beantwoord door iemand met meer verkeer dan wij.
Het had een tweede effect dat ik niet had gepland. Het doorwerken van andermans flows riep meer vragen over de branche op dan het beantwoordde, en verschillende daarvan gingen naar andere teamleden om uit te zoeken. Daar dient kijken naar hoe anderen het doen voor: het is verkennend, en het nuttige is vaak de vraag en niet de kopie van het antwoord.
Booking.com en Expedia. De twee grootste platforms in accommodatie, en de twee die de meeste bestudering waard zijn.
Ideatie en scoping
Ik leidde de ideatiesessies, en de benchmark was de reden dat ze werkten. Een zaal vol mensen met sterke meningen over een feature is een lastige zaal; een zaal vol mensen aan wie net is laten zien wat vijf concurrenten daadwerkelijk hebben opgeleverd, is een andere. Het materiaal voerde het gesprek.
Scoping liep parallel, met de product owner en de data scientist. Twee vragen, bewust gescheiden gehouden: wat zou de ideale versie hiervan zijn, en wat is de kleinste versie die het waard is om aan iemand voor te leggen. Beide vasthouden betekende dat de schrappingen als schrappingen werden vastgelegd in plaats van verloren te gaan, en dat is wat een tweede ronde mogelijk maakt.
Wireframes, en ze testen op de gang
De wireframe werd een klikbaar prototype, en zijn taak was om twee concurrerende concepten in een vorm te gieten die iemand kon vasthouden. Een mening over een diagram is goedkoop. Een mening over iets waar je net doorheen hebt geklikt is de moeite waard, en die komt eerder.
Bewust low-fidelity, want het publiek bestond uit stakeholders en iedereen in de organisatie met belang bij de uitkomst, en een gepolijst scherm nodigt uit tot een gesprek over de politoer. Daarna guerrillatesten, om de voor de hand liggende problemen eruit te halen voordat ze iemand een sprint kosten, en om de vragen naar boven te halen die het concept opriep. Verschillende daarvan gingen terug naar het team om goed uit te zoeken.
Het scherm waar de hele feature om draait, in de vorm waarin er voor het eerst over werd gediscussieerd. Twee manieren om dezelfde kamer voor dezelfde prijs te betalen, onder elkaar, en verder niets op het scherm om over te discussiëren.
Het ontwikkelplan
Eén tekening met het happy path, de belangrijkste randgevallen en het scherm waarop elk daarvan uitkomt. Daaruit konden de product owner en de developers tickets schrijven zonder terug te hoeven komen met de vraag wat er wanneer gebeurt.
Het beslechtte ook iets wat het ontwerp niet zelf kon beslissen. Onze architectuur draaide voor deze versie op de data van Expedia, wat betekende dat we ons moesten voegen naar de regels van Expedia voor hoe een boeking na de checkout wordt verwerkt. Dus las ik die regels en tekende ze opnieuw als een beslisflow die een niet-technische collega kon volgen, wat voor de developers net zo nuttig bleek als voor de rest: het maakte zichtbaar welke deelfuncties we erfden en welke we bewust nog niet implementeerden.
Elk scherm dat moest veranderen, en wat eraan moest veranderen.
Wat er met een boeking gebeurt na de checkout, volgens de regels die we erfden. Hier bijgesneden; hij opent volledig.
High-fidelity schermen
Zodra de tickets er waren, werden de schermen getekend tegen de stijlgids en componentbibliotheek van Findhotel, zodat een front-enddeveloper een layout implementeerde in plaats van er een te interpreteren. Paddings, kleuren, marges en iconen kwamen allemaal uit het systeem. De belangrijkste schermen voor desktop en mobiel werden in Zeplin gepubliceerd zodat de developers ermee konden werken.
Handmatig testen, vóór de release
Zodra de developers iets hadden dat nog niet uit was, liep ik de scenario's die we voor die sprint hadden afgesproken met de hand door. Hier verdienen de scenariokaart en de scopingdiagrammen hun kosten terug: zonder die is "hebben we alles getest" een kwestie van geheugen.
Naast de scenario's controleerde het team dezelfde build tegen elk van deze punten, waar ze van toepassing waren. Het is een lange lijst voor zo'n kleine feature, en dat is de eerlijke vorm van een betaalkeuze uitrollen in een boekingsfunnel die al bestaat.
- Apparaat mobiel, tablet, desktop
- Browser Chrome, Safari, Firefox, Edge
- Verblijfsduur één nacht tegenover meerdere
- Kamerconfiguratie één kamer tegenover meerdere
- Ingelogd tegenover uitgelogd
- Privéaanbiedingen aanwezig, afwezig en gemengd
- Beschikbaarheid beschikbaar, uitverkocht, prijsverschil
- Btw-weergave exclusief, zoals in de VS, tegenover inclusief, zoals in Nederland
- Betaalspecificatie prijzen met belastingen en kosten voor betalen bij het hotel tegenover prijzen die alleen nu betalen kennen
- Valuta omgerekend vanaf de provider tegenover niet omgerekend
- Taal Engels tegenover Duits, dat langer is en layouts als eerste breekt
Kijken hoe het zich in het wild gedraagt
Zodra het live staat, is de vraag niet langer of het werkt maar wat mensen er daadwerkelijk mee doen. Daarvoor gebruikte ik FullStory, dat echte sessies opneemt en je laat segmenteren op gedrag of op waar iemand zit. Vond ik een probleem, een bug of een idee dat het bewaren waard was, dan schreef ik het op. Bugs glippen erdoorheen, en interfaces doen rare dingen in bepaalde browsers; zo kom je erachter welke.
Vijf sessies, bewaard omdat elk ervan iets laat zien wat de cijfers niet kunnen. Twee zitten aan de A-kant en drie aan de B-kant van de test.
Taiwan, desktop, A-kant
India, desktop, B-kant
Ohio, phablet, B-kant
Qatar, mobiel, A-kant
Spanje, tablet, B-kant
Het opschrijven voor alle anderen
De laatste stap, en de stap die het makkelijkst wordt overgeslagen. Een experiment dat alleen het eigen team begrijpt, heeft het bedrijf niets verteld.
De product owner en de data scientist schreven het leesbare verslag. Wat ik maakte, zijn de twee tekeningen hieronder: de twee kanten van de test naast elkaar, zodat een collega die nooit bij een van onze overleggen zat er langs kon scrollen en in een paar seconden precies zag wat er was veranderd.
Conclusie
Resultaten
Conversie op Expedia-aanbiedingen, de enige aanbiedingen in de test. Dat cijfer is al netto na het hogere annuleringspercentage hieronder, dus het is wat de feature waard was na de kosten van de boekingen die hij verloor.
Annuleringen op boekingen met achteraf betalen tegenover boekingen die nu zijn betaald. Geen verrassing, en niet gratis: van een boeking waarvoor iemand niet heeft betaald, loop je makkelijker weg. Het is de prijs van de conversie hierboven.
En dan het deel dat minder comfortabel is om te publiceren. Door een bug in de zoekpagina werden per hotelvermelding alleen de bovenste drie providers getoond, en de eigen aanbiedingen met achteraf betalen van Findhotel zaten daar niet altijd bij. Een onbekend deel van de reizigers in deze test kon dus niet vinden wat er werd getest.
Dat betekent dat het getal hierboven een ondergrens is en geen meting. De feature was waarschijnlijk meer waard dan 4,2%, en de eerlijke versie van die zin is dat we niet weten hoeveel meer. De zoekpagina is daarna hersteld, maar de test is nooit opnieuw gedraaid tegen een gecorrigeerde versie, dus het plafond is nog steeds ongemeten. Wat de test wél vaststelde, is een richting, en een richting was genoeg om het werk dat erna kwam te rechtvaardigen.