UX Case study
Improving price display through clarity
The number a traveller saw when they picked a hotel and the number they were asked for at the end were not the same, and the further they were from the United States the wider that gap ran. This is the work that took the price apart on the page instead of at the till, and the experiment that measured whether saying more about a price sells more of it.
The panel this whole page is about, in the state it ended up in. Every line under the room rate is money somebody used to meet for the first time at checkout.
Problem
A price that grew on the way to the till
Findhotel is a smaller player in accommodation. It works the localised markets the largest platforms tend to leave alone, and much of its portfolio is distress inventory: rooms a hotel expects not to sell and cannot list itself without being pushed down the rankings by the bigger sites.
Selling that inventory means winning on price, and the funnel was undermining its own strongest argument. The figure shown when somebody chose a room was not the figure they were asked for two screens later, and the data showed the loss concentrated in exactly that gap.
The gap was widest for travellers outside the United States, because that is where the extra lines live: a city tax collected by the municipality, a resort fee collected by the hotel, other local charges that vary street by street. None of it was hidden on purpose. It simply appeared late, unnamed, and all at once.
Two arguments pointed the same way for once. The business wanted the conversion rate. I wanted somebody to be able to answer the question what am I paying for and why without opening a second tab. There is not usually a project where those are the same piece of work.
Deal details, the one screen in the funnel whose entire job is to answer that question.
Goals
What the work had to do
The third one is the reason the first two were allowed to happen. Price display sits on the revenue path of every booking the company takes, so a change to it is a change nobody can be relaxed about. Being able to point at a staged rollout was what made the conversation possible at all.
Team & audience
Who did what
The product owner brought the business case and set the priorities. The data scientist supplied the numbers the decisions rested on and designed the A/B tests that measured them. A copywriter owned the wording of every label, which on a project whose subject is what words mean is not a small part of it. An outside agency translated that wording into the languages the site runs in.
Everything between the problem and the handover was mine: the benchmark, the ideation and scoping sessions, the wireframes and the prototype, the guerrilla tests, the development plan, the high-fidelity screens, the manual testing before release, the watching afterwards, and the write-up that let anybody else in the company follow what had changed.
Being the only designer on it had one useful consequence and one uncomfortable one. The useful one is that the price appeared the same way on every surface it appeared on, because there was nobody to disagree with. The uncomfortable one is that nothing I drew was ever reviewed by another designer before it was built.
The copywriter is the person I would name if asked what made the difference. Renaming one line in a table changed what the table meant, and no amount of layout would have done it.
Audience
Who we aimed at, and in what order
The first release went to American travellers arriving from Google hotel ads onto the room selection page. That was the largest and most valuable group on the site, which made it the audience worth improving and the audience worth being careful with.
The order after that was deliberate rather than alphabetical. Once a hypothesis had survived, the change went out to the rest of the English-speaking markets, and only then to the twenty-six other languages the site supported at the time. Each step was a smaller bet than the one it followed was worth, which is how a team is allowed to touch the revenue path more than once.
Worth flagging early, because it comes back at the end of this page: the group we aimed at first is not the group the result came from.
Scope and constraints
What we could reach, and what we could not
The company was organised so that the room selection page and everything after it belonged to us, and the search and landing pages did not. That is a hard boundary drawn through the middle of the problem: a traveller forms their expectation of the price on a screen we were not allowed to change, and then meets ours.
There was also no budget for moderated testing. A handful of customers were called, but the purpose of those calls was to collect what they already disliked about the current experience, not to put a prototype in front of them. So the qualitative half of this project is a benchmark and a set of session recordings rather than a study.
The first card is the one worth dwelling on, because it is the difference between a change to a screen and a change to a product. A price breakdown that is only honest at the moment of payment is not honest; it is a disclosure. So the same rows had to survive past the point where the money moves, into the screen that confirms the booking and the email that follows it.
This wireframe is where that was settled. It is the confirmation screen, carrying the identical breakdown the checkout carries, and then the two lines the checkout cannot have yet: what has already been paid, and what the property is still going to collect. Everything later in this page is downstream of that decision.
Confirmation, wireframed. The breakdown does not stop at the payment, and the currency placeholders in the small print are there because it had to be true in every market too.
Process
Nine steps, repeated every iteration
This was never one project with an end. It is a loop that has run several times, and each pass leaned on whichever of these steps the product needed most at that moment. The benchmark is the exception: it was done thoroughly once and consulted afterwards.
Mapping where a price appears
A rough diagram of the interactions a traveller can have with a price and what follows from each. It is not a complete account of every state the funnel can be in, and it was never going to be. What it buys is the edge cases you can see in advance rather than the ones a developer finds in a sprint, and a shared object to point at when somebody asks whether we thought about several rooms across several nights in a currency the provider does not use.
Benchmarking eight platforms in seven countries
This is the part of the project I would show first, and on the original page it was folded inside a collapsed panel at the very bottom. It started as one question with an obvious answer and turned out to have none: what do other platforms include in the nightly price?
Answering it honestly meant deciding who to compare against, where, and under what booking. So: Findhotel against Expedia, Booking, Agoda, Skyscanner, TripAdvisor, Airbnb and Kayak, because those are the ones the company already measured itself against. In the Netherlands, Germany, the United Kingdom, Australia, Belarus, Indonesia and Israel, because those are the markets where our own price display rules already differed.
Comparable results need a control, so every search was the same search: Park Plaza Victoria in Amsterdam, one adult, one room, for the night of 13 October 2020, a hotel chosen precisely because it carries both a city tax and a tourism fee. The searches themselves were run in September, a month out, which is roughly when somebody books a city break. A second pass asked for two nights, 13 to 15 October, in the five markets where the first pass had raised a question. Where a platform did not carry that hotel, the nearest equivalent was used and the substitution written down.
Does the platform include the general tax in the nightly rate?
Three answers were possible: yes and from the search results onwards, no and only at checkout, or it names the base rate and the total together.
Does it include the local tax in the nightly rate?
The same three, asked separately, because a city tax and a general sales tax are collected by different people and platforms treat them differently.
Fifty-six cells, two answers each. It opens full size, which is the only way a table this dense is worth anything.
The finding is in the two starred rows. Airbnb and Expedia were the only platforms that answered both questions the same way in every market, and the answer they gave was neither yes nor no: they name the base rate and the total at the same time. Everyone else, ourselves included, picked one number and hoped it was the right one for that country.
The board also records what did not work. Skyscanner's figures did not add up. TripAdvisor did not appear to sell in Belarus at all. And Belarus is only on the list because Russia was the market I wanted and a Russian VPN turned out to be genuinely difficult to obtain, which is the sort of thing a methodology section normally leaves out.
The second board: the panels themselves, side by side. The top row is one room, the bottom row is several, because that is where most of them stop making sense.
Those seven are the raw material the matrix was read off. Each is one country's whole landscape captured in a single pass, which is also why the study has a date on it: this is what these sites looked like in September 2020, and several of them have changed since.
Ideation, then scoping it down
I ran the ideation sessions, and the benchmark is what made them worth running. Walking a team through what eight competitors do to the same booking is a faster way to establish what is possible than any amount of argument, and it moves the conversation from opinions about price to observations about prices.
Scoping followed each session, with the product owner and the data scientist. Two questions, always in this order: what would the right answer look like if nothing were in the way, and what is the smallest piece of it we could put in front of real traffic next. The gap between those two answers is the roadmap.
A prototype cheap enough to argue with
The wireframes became a clickable prototype, kept deliberately rough. The audience was stakeholders and anybody in the company with a stake in the outcome, and a finished-looking screen invites a conversation about how finished it looks. A grey one invites a conversation about the price.
Then guerrilla testing, which here means grabbing whoever was available and watching them try. It does not replace a study and it was never offered as one. It catches the obvious, and it generates the questions that go back to the team as real research: what happens when the currency of the traveller is not the currency of the provider, what happens across several rooms, what happens when the fee is larger than the room.
The whole flow on a phone, banded by stage, in the form it was first argued about. It runs past checkout into the emails, booking management and cancellation, because a price that is only itemised whilst you are paying has not been explained. Every extra line also costs a scroll here, which is worth remembering when the results arrive.
Turning it into tickets
A diagram of the happy path and the edge cases that matter, each branch carrying the screen it produces. That drawing is what a product owner writes tickets from, and it is the reason a sprint can be estimated at all. It is also the artefact I go back to in step seven, when the question is whether the build does what was agreed.
Handing it to the front end
High fidelity screens, drawn against the company's style guide and component library so that a developer is assembling known parts rather than interpreting a picture. The key screens went into Zeplin in both desktop and mobile, which is where the padding, the colour and the icon come from without anybody having to ask.
Checking the build against the scenarios
Once developers had something unreleased, I worked back through the scenarios agreed for that sprint by hand. This is where the map from step one and the diagram from step five pay for themselves, because otherwise the answer to whether everything was covered is somebody's memory of a conversation.
Two recordings from production
Once it was live the question changes from whether it works to what people do with it. FullStory records real sessions and lets you segment by behaviour or by where somebody is, and anything I found worth keeping, a bug or an idea or a habit nobody had predicted, went into a document.
Two of those sessions are here because each shows something a conversion rate cannot. One is an American traveller on the B side going from room selection through to checkout. The other is a traveller in Japan opening the price breakdown on a room, which is the exact gesture this project existed to make worth making.
United States, room selection through to checkout, on the B side of the test
Japan, opening the price breakdown from the room selection page
Making the change legible to colleagues
The last step is the one that decides whether any of the others travel. The product owner and the data scientist wrote the readable account; my part was to draw the two sides against each other so that somebody who had never been in a single meeting about this could scroll once and see what moved.
Both boards below run the same journey twice, room selection on the left and checkout on the right, with the decision points drawn as diamonds and the resulting panel under each branch. Put them side by side and the whole change is three things: the fee gets its name back, what you pay now is separated from what you pay there, and a sentence says who collects it.
Conclusion
What five weeks of traffic said
Conversion, for travellers outside the United States, over a five-week test.
The effect was sharpest where people already expect a displayed price to contain the tax. What we had folded in was not tax at all: it was the accommodation fees sitting beside it.
Desktop traffic converted better. Mobile traffic converted slightly worse, on the same change, in the same weeks.
Bookings made about a week in advance improved. Last-minute bookings were slightly worse off, which is the pattern you would expect if reading takes time somebody does not have.
Now the part that is less comfortable. We aimed this at American travellers arriving from Google hotel ads, on the argument that they were the largest and most valuable group on the site. The gain came from everywhere else.
That is not a failure, but it is a result about the target rather than about the change, and it deserves to be read as one. A market where the displayed price already contains the tax has trained its travellers to expect the number on the tile to be the number they pay. Break that expectation and the correction is worth a lot. A market where tax is added at the end has trained the opposite expectation, and there was less to correct.
The mobile decrease is the other half of the same sentence. Every charge given its own line is another line, and a phone is where a line costs the most. Nobody measured which of the two effects was doing the work, so what the result really says is that clarity is not free everywhere and this project never found out where it stops paying.
What came next
By December 2020 the work had become a document rather than a screen: one map of how a price should be stated at each stage of the funnel, from the search results through room selection and deal details to checkout. Four boards, one per stage, each of them the rule rather than an example of it.
This is also where the two Findhotel projects on this site meet. The bottom of that checkout board is a choice between paying now and paying at the property, and giving somebody that choice properly is its own case study. Naming what the property collects is what made it possible to offer.
Those boards are the rules. What the original page offered next was the thing itself: a clickable prototype of the three price display logics the site was running at once, so that a reader could try them instead of reading about them.
It belongs here, beside them, and the slot is held. The file lived on Figma and that address no longer resolves, which is the ordinary fate of anything kept on somebody else's server and the reason nothing else on this page is loaded from one. It goes back in as soon as it has somewhere of its own to live.
Price display logic, V4
Prototype being rehosted
The interactive version of the four boards above.
Lessons
There is one more, and it is about where this page came from. All of the benchmark you have just read was, on the original version of this case study, folded inside a collapsed panel headed the extra bits, below the conclusion, under an admission that none of it was necessary. It was the most useful thing on the page. Work that took weeks tends to get filed as an appendix by the person who did it, because they remember it as the part before the real work started.