UX-case study
Prijsweergave verbeteren door duidelijkheid
Het getal dat een reiziger zag bij het kiezen van een hotel en het getal dat aan het eind werd gevraagd waren niet hetzelfde, en hoe verder van de Verenigde Statussen, hoe groter dat verschil. Dit is het werk dat de prijs uit elkaar haalde op de pagina in plaats van bij de kassa, en het experiment dat mat of meer vertellen over een prijs er ook meer van verkoopt.
Het paneel waar deze hele pagina over gaat, in de staat waarin het is beland. Elke regel onder het kamertarief is geld dat iemand vroeger pas bij de checkout voor het eerst tegenkwam.
Probleem
Een prijs die groeide op weg naar de kassa
Findhotel is een kleinere speler in accommodatie. Het bedient de gelokaliseerde markten die de grootste platforms meestal met rust laten, en een groot deel van het aanbod is restvoorraad: kamers waarvan een hotel verwacht ze niet te verkopen en die het zelf niet kan aanbieden zonder door de grotere sites in de ranglijst omlaag geduwd te worden.
Die voorraad verkopen betekent winnen op prijs, en de funnel ondermijnde zijn eigen sterkste argument. Het bedrag dat werd getoond bij het kiezen van een kamer was niet het bedrag dat twee schermen later werd gevraagd, en de data lieten zien dat het verlies zich precies in dat gat concentreerde.
Het gat was het grootst voor reizigers buiten de Verenigde Statussen, want daar zitten de extra regels: een toeristenbelasting die de gemeente int, een resortfee die het hotel int, andere lokale heffingen die per straat verschillen. Niets ervan was met opzet verborgen. Het verscheen simpelweg laat, zonder naam, en allemaal tegelijk.
Twee argumenten wezen voor één keer dezelfde kant op. De business wilde de conversie. Ik wilde dat iemand de vraag waar betaal ik voor en waarom kon beantwoorden zonder een tweede tabblad te openen. Er is niet vaak een project waarin die twee hetzelfde werk zijn.
Aanbiedingsdetails, het enige scherm in de funnel dat als enige taak heeft die vraag te beantwoorden.
Doelen
Wat het werk moest doen
De derde is de reden dat de eerste twee mochten gebeuren. Prijsweergave ligt op het omzetpad van elke boeking die het bedrijf aanneemt, dus een wijziging daaraan is een wijziging waar niemand ontspannen over kan doen. Kunnen wijzen op een gefaseerde uitrol was wat het gesprek überhaupt mogelijk maakte.
Team & publiek
Wie deed wat
De product owner bracht de business case en stelde de prioriteiten. De data scientist leverde de cijfers waarop de beslissingen rustten en ontwierp de A/B-tests die ze maten. Een copywriter had de bewoording van elk label in handen, en bij een project waarvan het onderwerp is wat woorden betekenen is dat geen klein deel. Een extern bureau vertaalde die bewoording naar de talen waarin de site draait.
Alles tussen het probleem en de overdracht was van mij: de benchmark, de ideatie- en scopingsessies, de wireframes en het prototype, de guerrillatests, het ontwikkelplan, de high-fidelity schermen, het handmatig testen vóór de release, het meekijken daarna, en de verslaglegging waarmee iedereen in het bedrijf kon volgen wat er was veranderd.
De enige designer erop zijn had één nuttig gevolg en één ongemakkelijk gevolg. Het nuttige is dat de prijs er op elk oppervlak waar hij verscheen hetzelfde uitzag, want er was niemand om het mee oneens te zijn. Het ongemakkelijke is dat niets van wat ik tekende ooit door een andere designer is beoordeeld voordat het werd gebouwd.
De copywriter is de persoon die ik zou noemen als iemand vraagt wat het verschil maakte. Eén regel in een tabel hernoemen veranderde wat de tabel betekende, en geen enkele hoeveelheid opmaak had dat gedaan.
Publiek
Op wie we mikten, en in welke volgorde
De eerste release ging naar Amerikaanse reizigers die via Google hotel ads op de kamerselectiepagina binnenkwamen. Dat was de grootste en meest waardevolle groep op de site, wat hen zowel het publiek maakte dat het verbeteren waard was als het publiek waarmee je voorzichtig moest zijn.
De volgorde daarna was bewust in plaats van alfabetisch. Zodra een hypothese overeind was gebleven, ging de wijziging naar de overige Engelstalige markten, en pas daarna naar de zesentwintig andere talen die de site destijds ondersteunde. Elke stap was een kleinere gok dan wat de vorige had opgeleverd, en zo mag een team het omzetpad meer dan één keer aanraken.
Nu alvast vermelden, want het komt aan het eind van deze pagina terug: de groep waarop we het eerst mikten is niet de groep waar het resultaat vandaan kwam.
Scope en beperkingen
Wat we konden bereiken, en wat niet
Het bedrijf was zo georganiseerd dat de kamerselectiepagina en alles daarna van ons waren, en de zoek- en landingspagina's niet. Dat is een harde grens dwars door het midden van het probleem: een reiziger vormt zijn verwachting van de prijs op een scherm dat wij niet mochten veranderen, en komt daarna het onze tegen.
Er was ook geen budget voor begeleid testen. Een handvol klanten is gebeld, maar het doel van die gesprekken was verzamelen wat ze al niet beviel aan de huidige ervaring, niet om ze een prototype voor te leggen. De kwalitatieve helft van dit project is dus een benchmark en een set sessieopnamen in plaats van een studie.
De eerste kaart is degene om bij stil te staan, want het is het verschil tussen een wijziging aan een scherm en een wijziging aan een product. Een prijsopbouw die alleen eerlijk is op het moment van betalen is niet eerlijk; het is een mededeling. Dezelfde regels moesten dus voorbij het punt waar het geld beweegt overleven, tot in het scherm dat de boeking bevestigt en de mail die daarop volgt.
In dit wireframe is dat beslecht. Het is het bevestigingsscherm, met exact dezelfde opbouw als de checkout, en daarna de twee regels die de checkout nog niet kan hebben: wat er al is betaald, en wat het hotel nog gaat innen. Alles verderop op deze pagina volgt uit die beslissing.
Bevestiging, als wireframe. De opbouw stopt niet bij de betaling, en de valutaplaceholders in de kleine lettertjes staan er omdat het ook in elke markt waar moest zijn.
Proces
Negen stappen, elke iteratie herhaald
Dit was nooit één project met een einde. Het is een lus die meerdere keren heeft gedraaid, en elke ronde leunde op de stappen die het product op dat moment het hardst nodig had. De benchmark is de uitzondering: die is één keer grondig gedaan en daarna geraadpleegd.
In kaart brengen waar een prijs verschijnt
Een ruw schema van de interacties die een reiziger met een prijs kan hebben en wat er uit elk daarvan volgt. Het is geen volledige weergave van elke staat waarin de funnel kan verkeren, en dat zou het ook nooit worden. Wat het oplevert zijn de randgevallen die je vooraf kunt zien in plaats van die een developer in een sprint vindt, en een gedeeld object om naar te wijzen wanneer iemand vraagt of we hebben nagedacht over meerdere kamers over meerdere nachten in een valuta die de aanbieder niet gebruikt.
Acht platforms in zeven landen benchmarken
Dit is het deel van het project dat ik als eerste zou laten zien, en op de oorspronkelijke pagina zat het weggevouwen in een ingeklapt paneel helemaal onderaan. Het begon als één vraag met een voor de hand liggend antwoord en bleek er geen te hebben: wat nemen andere platforms op in de nachtprijs?
Die eerlijk beantwoorden betekende beslissen met wie je vergelijkt, waar, en onder welke boeking. Dus: Findhotel tegen Expedia, Booking, Agoda, Skyscanner, TripAdvisor, Airbnb en Kayak, want dat zijn de partijen waaraan het bedrijf zich al spiegelde. In Nederland, Duitsland, het Verenigd Koninkrijk, Australië, Belarus, Indonesië en Israël, want dat zijn de markten waar onze eigen regels voor prijsweergave al verschilden.
Vergelijkbare resultaten hebben een controle nodig, dus elke zoekopdracht was dezelfde zoekopdracht: Park Plaza Victoria in Amsterdam, één volwassene, één kamer, voor de nacht van 13 oktober 2020, een hotel dat juist is gekozen omdat er zowel toeristenbelasting als een toeristenheffing op zit. De zoekopdrachten zelf zijn in september uitgevoerd, een maand vooruit, ongeveer wanneer iemand een stedentrip boekt. Een tweede ronde vroeg om twee nachten, 13 tot 15 oktober, in de vijf markten waar de eerste ronde een vraag had opgeroepen. Waar een platform dat hotel niet had, is het dichtstbijzijnde equivalent gebruikt en is de vervanging genoteerd.
Neemt het platform de algemene belasting op in het nachttarief?
Drie antwoorden waren mogelijk: ja en al vanaf de zoekresultaten, nee en pas bij de checkout, of het noemt het basistarief en het totaal samen.
Neemt het de lokale belasting op in het nachttarief?
Dezelfde drie, apart gevraagd, want toeristenbelasting en algemene omzetbelasting worden door verschillende partijen geïnd en platforms behandelen ze verschillend.
Zesenvijftig cellen, twee antwoorden elk. Hij opent op volle grootte, en dat is de enige manier waarop een tabel die zo dicht is iets waard is.
De bevinding zit in de twee rijen met een ster. Airbnb en Expedia waren de enige platforms die beide vragen in elke markt hetzelfde beantwoordden, en het antwoord dat ze gaven was noch ja noch nee: ze noemen het basistarief en het totaal tegelijkertijd. Alle anderen, wijzelf inbegrepen, kozen één getal en hoopten dat het voor dat land het juiste was.
Het bord legt ook vast wat niet werkte. De cijfers van Skyscanner klopten niet. TripAdvisor leek in Belarus helemaal niets te verkopen. En Belarus staat alleen op de lijst omdat Rusland de markt was die ik wilde en een Russische VPN echt moeilijk bleek te krijgen, en dat is het soort ding dat een methodologiesectie normaal weglaat.
Het tweede bord: de panelen zelf, naast elkaar. De bovenste rij is één kamer, de onderste rij zijn er meerdere, want daar houden de meeste ervan op te kloppen.
Die zeven zijn het ruwe materiaal waaruit de matrix is afgelezen. Elk is het hele landschap van één land, in één ronde vastgelegd, en dat is ook waarom de studie een datum draagt: zo zagen deze sites eruit in september 2020, en verschillende ervan zijn sindsdien veranderd.
Ideatie, daarna terugbrengen tot de scope
Ik leidde de ideatiesessies, en de benchmark is wat ze de moeite waard maakte. Een team meenemen langs wat acht concurrenten met dezelfde boeking doen is een snellere manier om vast te stellen wat mogelijk is dan welke discussie ook, en het verschuift het gesprek van meningen over prijs naar waarnemingen over prijzen.
Na elke sessie volgde de scoping, met de product owner en de data scientist. Twee vragen, altijd in deze volgorde: hoe zou het juiste antwoord eruitzien als niets in de weg stond, en wat is het kleinste stuk daarvan dat we hierna voor echt verkeer kunnen zetten. Het gat tussen die twee antwoorden is de roadmap.
Een prototype dat goedkoop genoeg is om over te discussiëren
De wireframes werden een klikbaar prototype, bewust ruw gehouden. Het publiek waren stakeholders en iedereen in het bedrijf met een belang bij de uitkomst, en een scherm dat er af uitziet nodigt uit tot een gesprek over hoe af het eruitziet. Een grijs scherm nodigt uit tot een gesprek over de prijs.
Daarna guerrillatesten, wat hier betekent: pakken wie beschikbaar is en kijken hoe ze het proberen. Het vervangt geen studie en het is ook nooit als zodanig gepresenteerd. Het vangt het voor de hand liggende, en het levert de vragen op die als echt onderzoek terugkomen bij het team: wat gebeurt er als de valuta van de reiziger niet de valuta van de aanbieder is, wat gebeurt er bij meerdere kamers, wat gebeurt er als de kostenpost groter is dan de kamer.
De hele flow op een telefoon, in banen per fase, in de vorm waarin er voor het eerst over is gediscussieerd. Hij loopt voorbij de checkout door naar de mails, boekingsbeheer en annulering, want een prijs die alleen is uitgesplitst terwijl je betaalt, is niet uitgelegd. Elke extra regel kost hier ook een stukje scrollen, en dat is het waard te onthouden wanneer de resultaten binnenkomen.
Het omzetten in tickets
Een schema van het happy path en de randgevallen die ertoe doen, waarbij elke tak het scherm draagt dat eruit voortkomt. Uit die tekening schrijft een product owner tickets, en zij is de reden dat een sprint überhaupt geschat kan worden. Het is ook het artefact waar ik in stap zeven op terugval, wanneer de vraag is of de build doet wat is afgesproken.
Het overdragen aan de front-end
High-fidelity schermen, getekend tegen de stijlgids en componentbibliotheek van het bedrijf, zodat een developer bekende onderdelen samenstelt in plaats van een plaatje te interpreteren. De belangrijkste schermen gingen in Zeplin in zowel desktop als mobiel, en daar komen de padding, de kleur en het icoon vandaan zonder dat iemand het hoeft te vragen.
De build tegen de scenario's controleren
Zodra developers iets hadden dat nog niet uit was, liep ik met de hand de scenario's terug die voor die sprint waren afgesproken. Hier verdienen de kaart uit stap één en het schema uit stap vijf zichzelf terug, want anders is het antwoord op de vraag of alles is gedekt iemands herinnering aan een gesprek.
Twee opnamen uit productie
Zodra het live is, verandert de vraag van of het werkt naar wat mensen ermee doen. FullStory neemt echte sessies op en laat je segmenteren op gedrag of op waar iemand is, en alles wat ik het bewaren waard vond, een bug of een idee of een gewoonte die niemand had voorspeld, ging in een document.
Twee van die sessies staan hier omdat elk iets laat zien wat een conversiecijfer niet kan. De ene is een Amerikaanse reiziger aan de B-kant die van kamerselectie doorloopt naar de checkout. De andere is een reiziger in Japan die de prijsopbouw van een kamer opent, en dat is precies het gebaar dat dit project de moeite waard moest maken.
Verenigde Statussen, van kamerselectie tot checkout, aan de B-kant van de test
Japan, de prijsopbouw openen vanaf de kamerselectiepagina
De verandering leesbaar maken voor collega's
De laatste stap bepaalt of de andere stappen ergens komen. De product owner en de data scientist schreven het leesbare verslag; mijn deel was de twee kanten tegenover elkaar tekenen zodat iemand die nooit bij één vergadering hierover was geweest, één keer kon scrollen en zien wat er was veranderd.
Beide borden hieronder doorlopen dezelfde reis twee keer, kamerselectie links en checkout rechts, met de beslismomenten getekend als ruiten en het resulterende paneel onder elke tak. Zet ze naast elkaar en de hele verandering is drie dingen: de kostenpost krijgt zijn naam terug, wat je nu betaalt wordt gescheiden van wat je daar betaalt, en een zin vertelt wie het int.
Conclusie
Wat vijf weken verkeer zeiden
Conversie, voor reizigers buiten de Verenigde Statussen, over een test van vijf weken.
Het effect was het scherpst waar mensen al verwachten dat een getoonde prijs de belasting bevat. Wat wij hadden meegenomen was helemaal geen belasting: het waren de accommodatiekosten die ernaast stonden.
Desktopverkeer converteerde beter. Mobiel verkeer converteerde iets slechter, bij dezelfde wijziging, in dezelfde weken.
Boekingen die ongeveer een week vooruit werden gemaakt verbeterden. Lastminuteboekingen waren iets slechter af, en dat is het patroon dat je verwacht als lezen tijd kost die iemand niet heeft.
Nu het deel dat minder comfortabel is. We richtten dit op Amerikaanse reizigers die via Google hotel ads binnenkwamen, met het argument dat zij de grootste en meest waardevolle groep op de site waren. De winst kwam van overal elders.
Dat is geen mislukking, maar het is een resultaat over het doelwit in plaats van over de verandering, en het verdient het ook zo gelezen te worden. Een markt waar de getoonde prijs de belasting al bevat, heeft haar reizigers geleerd te verwachten dat het getal op de tegel het getal is dat ze betalen. Breek die verwachting en de correctie is veel waard. Een markt waar belasting aan het eind wordt toegevoegd heeft de tegenovergestelde verwachting aangeleerd, en daar viel minder te corrigeren.
De daling op mobiel is de andere helft van dezelfde zin. Elke heffing een eigen regel geven is weer een regel, en op een telefoon kost een regel het meest. Niemand heeft gemeten welk van de twee effecten het werk deed, dus wat het resultaat werkelijk zegt is dat duidelijkheid niet overal gratis is en dat dit project nooit heeft uitgezocht waar ze ophoudt zich terug te betalen.
Wat daarna kwam
Tegen december 2020 was het werk een document geworden in plaats van een scherm: één kaart van hoe een prijs in elke fase van de funnel moet worden weergegeven, van de zoekresultaten via kamerselectie en aanbiedingsdetails tot de checkout. Vier borden, één per fase, elk daarvan de regel in plaats van een voorbeeld ervan.
Dit is ook waar de twee Findhotel-projecten op deze site elkaar raken. Onderaan dat checkoutbord staat een keuze tussen nu betalen en bij het hotel betalen, en iemand die keuze fatsoenlijk geven is een eigen case study. Benoemen wat het hotel int is wat het mogelijk maakte die keuze aan te bieden.
Die borden zijn de regels. Wat de oorspronkelijke pagina daarna bood was het ding zelf: een klikbaar prototype van de drie logica's voor prijsweergave die de site tegelijk draaide, zodat een lezer ze kon uitproberen in plaats van erover te lezen.
Het hoort hier, ernaast, en de plek wordt vrijgehouden. Het bestand stond op Figma en dat adres bestaat niet meer, wat het gewone lot is van alles wat op de server van iemand anders staat en de reden dat niets anders op deze pagina van zo'n server wordt geladen. Het gaat er weer in zodra het een eigen plek heeft om te wonen.
Logica voor prijsweergave, V4
Prototype wordt opnieuw gehost
De interactieve versie van de vier borden hierboven.
Lessen
Er is er nog één, en die gaat over waar deze pagina vandaan komt. De hele benchmark die je zojuist hebt gelezen zat, in de oorspronkelijke versie van deze case study, weggevouwen in een ingeklapt paneel met de kop the extra bits, onder de conclusie, met de bekentenis dat niets ervan nodig was. Het was het nuttigste op de pagina. Werk dat weken kostte wordt door degene die het deed vaak als bijlage weggezet, omdat hij het zich herinnert als het deel vóór het echte werk begon.