Hypothesis. Design. Test. Repeat.
A selection of CRO and A/B testing work across checkout and search, from quick heuristic fixes to full journey redesigns.
How This Works.
Not every conversion problem needs a dashboard. Some of the most impactful changes come from a designer looking at an experience and knowing, from expertise and instinct, that something isn’t working. Others come from interrogating behavioural data until the drop-off tells you exactly where the friction is.
The tests below span both. Some were driven by Amplitude data identifying specific points of abandonment in the booking funnel. Others were heuristic calls, design decisions made on the basis of experience, user psychology and common sense. In every case, the process was the same: identify the problem, form a testable hypothesis, design the variant, measure the outcome.
I worked across these as the lead designer embedded in the search and checkout squads, owning hypothesis formation and design from brief through to handoff.
Test 01, Heuristic
Describe What You’re Selling.
The observation. The extras step in the checkout journey listed products by name only. A towel bundle, for example, had no description of what it actually contained. Users were being asked to make a purchasing decision with almost no information.
There was no data pointing at this. No funnel report flagging extras as a problem. It was a straightforward heuristic call, looking at the screen and recognising that we were asking people to spend money on something we hadn’t bothered to explain. The fix seemed obvious. That made me slightly nervous about proposing it, because obvious fixes either get dismissed as too simple or they work embarrassingly well and you wonder why nobody did it sooner.
The hypothesis. Users were not adding extras because they didn’t understand what they were buying. Adding a short product description would reduce uncertainty and increase attachment rate.
The change. A concise description added beneath each extra, explaining exactly what was included.
The result. A statistically significant uplift in extras attachment rate. One of the simplest tests on this page and one of the fastest to implement. The lesson isn’t that heuristic evaluation is better than data. It’s that data doesn’t catch everything and you still need someone who can look at a screen and know when something is wrong.
Test 02, Data Informed
Show the Drive. Not Just the Distance.
The observation. Search results were surfacing holiday parks without any indication of how long it would take to get there. The assumption baked into the design was that users thought in terms of miles or postcodes. They don’t. They think in terms of time.
The hypothesis. Surfacing actual drive times rather than distances would give users the information they needed to consider parks they might otherwise dismiss, increasing engagement with a broader set of results.
The change. Drive time introduced as a search input and displayed against results, allowing users to filter by journey time rather than proximity alone.
The result. A meaningful uplift in engagement with search results and increased consideration of parks that had previously been overlooked. Worth noting that this change also reduced a specific frustration pattern we were seeing in session recordings, users opening parks and immediately closing them when they worked out the distance. Giving them that information upfront removed a friction point that the funnel data alone wouldn’t have identified.
Test 03, Strategic Redesign
Let Users Build Their Own Break.
The observation. The search journey followed a rigid stepped approach. Users had to complete each field in a fixed sequence before seeing results. Behavioural data showed significant drop-off at early steps, with users abandoning before they had committed to specific dates or party sizes.
The stepped model made sense from a data collection perspective. It didn’t make sense from a user perspective. People planning a holiday don’t think in a fixed sequence. Some know where they want to go but not when. Some know the dates but haven’t decided on party size yet. The form was forcing a linearity that the actual decision-making process doesn’t have.
This wasn’t a quick test. It was a full redesign proposal and it had to survive a fair amount of internal scepticism before it got to a sprint. The argument against was that the stepped model had always worked well enough. The argument for was that well enough isn’t the same as good, and the data was showing us where the ceiling was.
The hypothesis. A fluid, non-linear approach allowing users to add search criteria in any order and see results update progressively would reduce early abandonment and improve result quality.
The change. Full redesign of the search journey from a stepped form into a fluid break builder model. Users could enter any combination of criteria in any order, with results personalising in real time.
The result. A significant uplift across key search metrics and a measurably improved conversion rate. The fluid architecture also created a foundation for ongoing CRO and personalisation work that the stepped model had made structurally impossible. That second-order benefit was arguably more valuable than the direct uplift.
What I’d Do Differently.
The extras test worked and it was the right call. But in hindsight I’d have pushed to run a follow-up test on description length and tone rather than treating it as done once the uplift was confirmed. A statistically significant result tells you the change was better. It doesn’t tell you how much better you could get if you kept going.
On the break builder, I’d have fought harder to get a qualitative research round in before the redesign went to sprint. The data gave us clear signal on where users were dropping. It didn’t give us any signal on how the new model would feel to use. We shipped with confidence in the hypothesis but without evidence from actual users interacting with the prototype. It worked out. It doesn’t always.