Travelata.ru — Tour Builder
Travelata is Russia’s largest online tour aggregator — 2.5 million monthly users. The platform bundles flights, hotels, insurance, and transfers from dozens of tour operators into single packages. With razor-thin margins, even small improvements in the booking funnel directly impact revenue
Tour Builder is a new interface that unifies scattered tour parameters into a single decision-making flow. Through funnel analysis and early user conversations, I identified tour selection as the highest-impact friction point and drove the product from research through shipping across 4 platforms
ROLE
Lead Product Designer —
sole designer on the product, collaborating with the Head of Product, developers, QA, and analysts
PLATFORMS
Desktop, Mobile Web, iOS, Android
TIMELINE
9 weeks end-to-end
Lead Product Designer —
sole designer on the product, collaborating with the Head of Product, developers, QA, and analysts
PLATFORMS
Desktop, Mobile Web, iOS, Android
TIMELINE
9 weeks end-to-end
Impact
+7.5% final conversion, 18% faster checkout, $ 88K additional annual revenue. First implementation of its kind in the Russian travel market
Context
The travel aggregation market is uniquely challenging. Travelata integrated with dozens of tour operators, each running legacy systems with different data formats and pricing logic. Prices fluctuated every 15 minutes based on currency rates, demand, and room availability.
The booking flow was rigid: homepage → search results → hotel page → tour page → checkout. No shopping cart. No way to save progress. One wrong choice or price change meant starting over.
During the pandemic, user behaviour shifted — people became more price-sensitive and needed faster decisions in an increasingly volatile market
The booking flow was rigid: homepage → search results → hotel page → tour page → checkout. No shopping cart. No way to save progress. One wrong choice or price change meant starting over.
During the pandemic, user behaviour shifted — people became more price-sensitive and needed faster decisions in an increasingly volatile market
The original flow forced users through multiple pages to compare key parameters
Problem
Through funnel analysis, I pinpointed the hotel-to-tour page transition as the critical drop-off point.
On the hotel page, users saw dates, meals, and operators. But flights, transfers, and insurance lived on the tour page. Comparing options meant jumping back and forth — while prices shifted underneath them. Users lost track of what they’d compared, cognitive load grew with every transition, and decision-making slowed.
The fragmented experience made users feel like they’d lost control of the selection process
On the hotel page, users saw dates, meals, and operators. But flights, transfers, and insurance lived on the tour page. Comparing options meant jumping back and forth — while prices shifted underneath them. Users lost track of what they’d compared, cognitive load grew with every transition, and decision-making slowed.
The fragmented experience made users feel like they’d lost control of the selection process
Critical tour information was split across two separate pages, breaking the comparison flow
Research
I designed a qualitative study focused on decision-making patterns: detailed technical flow analysis, user interviews, and mapping where expectations diverged from reality. Quantitative data we already had — analytics showed clear drop-offs, and frontline support regularly surfaced user complaints about the booking flow. What we didn’t understand was why users dropped off and how they actually made decisions. That’s what the interviews needed to answer.
Key patterns:
Operator blindness
Most users chose by dates, meals, flights, and price — not by operator
Context collapse
Page transitions broke mental context; users forgot what they’d compared.
Volatility anxiety
15-minute price changes created pressure and paralysis simultaneously.
Loss of control
Critical information on different screens eroded trust and confidence.
Operator blindness
Most users chose by dates, meals, flights, and price — not by operator
Context collapse
Page transitions broke mental context; users forgot what they’d compared.
Volatility anxiety
15-minute price changes created pressure and paralysis simultaneously.
Loss of control
Critical information on different screens eroded trust and confidence.
Hypothesis
If we consolidate key tour parameters into a single interface and reduce transitions, users will decide faster and convert higher
If we consolidate key tour parameters into a single interface and reduce transitions, users will decide faster and convert higher
Early concept consolidating flight selection, meals, and dates in one view
Design & Solution
I explored several approaches, treating dates, meals, and flights as a unified decision — not separate steps. Two rounds of testing (internal for feasibility, 5 external users for validation) confirmed the direction
The ideal solution was to consolidate everything on one page. But legacy code from dozens of tour operator integrations couldn’t handle real-time sync of all parameters simultaneously. No refactoring budget.
I evaluated three approaches: full consolidation (technically impossible), keeping the status quo (unacceptable given the data), and a middle path. I proposed the compromise: keep nights and meals on the hotel page, but unify all flights from different operators on the tour page.
Why flights first? Research showed that flight comparison caused the most back-and-forth between pages — users needed to see departure times, airlines, and layovers side by side, which was impossible in the old flow. Nights and meals, while important, were simpler decisions that didn’t require cross-page comparison. This eliminated the highest-friction transitions while respecting technical reality.
This was the hardest design decision in the project — giving up the ideal solution while ensuring the MVP still delivered meaningful impact.
I evaluated three approaches: full consolidation (technically impossible), keeping the status quo (unacceptable given the data), and a middle path. I proposed the compromise: keep nights and meals on the hotel page, but unify all flights from different operators on the tour page.
Why flights first? Research showed that flight comparison caused the most back-and-forth between pages — users needed to see departure times, airlines, and layovers side by side, which was impossible in the old flow. Nights and meals, while important, were simpler decisions that didn’t require cross-page comparison. This eliminated the highest-friction transitions while respecting technical reality.
This was the hardest design decision in the project — giving up the ideal solution while ensuring the MVP still delivered meaningful impact.
Early prototypes tested different ways to structure the selection hierarchy
The MVP unified flight selection from different tour operators while keeping nights and meals on the hotel page
The operator problem
After launch, negative feedback surfaced from a segment I’d underestimated: users who chose by operator reputation, not parameters. I’d optimised for the majority but broken the experience for an important minority.
I addressed this quickly: added operator names back for visibility, implemented flight filters by operator/time/airline, and refined UI copy. Small changes that made the product work for both segments.
After launch, negative feedback surfaced from a segment I’d underestimated: users who chose by operator reputation, not parameters. I’d optimised for the majority but broken the experience for an important minority.
I addressed this quickly: added operator names back for visibility, implemented flight filters by operator/time/airline, and refined UI copy. Small changes that made the product work for both segments.
Post-feedback iteration added operator visibility and filtering options
Results
Core impact (Tour Builder):
- +7.5% increase in final conversion across all platforms
- 18% reduction in time from flight selection to checkout
- +$ 88,000 in additional annual revenue
- +1.2% yearly revenue from expanding tours to 6 participants
- 0.82% savings on payment processing fees
What's Next
After the MVP success, I explored two directions for evolving the Tour Builder:
In-page builder
Сonsolidate all parameters (nights, meals, flights) directly on the hotel page. Users configure everything without leaving the room selection interface — the most streamlined version of the original concept.
Dedicated builder page
А separate configuration interface where users adjust all parameters before browsing matching options. More flexibility for complex scenarios and new travel types like trains and accommodation-only bookings.
Both concepts addressed the core limitation of the MVP: the split between hotel and tour pages that we couldn’t resolve due to technical constraints
In-page builder
Сonsolidate all parameters (nights, meals, flights) directly on the hotel page. Users configure everything without leaving the room selection interface — the most streamlined version of the original concept.
Dedicated builder page
А separate configuration interface where users adjust all parameters before browsing matching options. More flexibility for complex scenarios and new travel types like trains and accommodation-only bookings.
Both concepts addressed the core limitation of the MVP: the split between hotel and tour pages that we couldn’t resolve due to technical constraints
A separate builder interface where users adjust all settings before browsing flight options
Users configure all tour parameters directly on the hotel page without additional navigation
What worked
Starting with a testable hypothesis kept the team aligned. Quick iterations and A/B testing delivered results despite severe constraints. The research patterns (operator blindness, context collapse) gave the team a shared language for decisions
What I'd do differently
I caught the operator-focused segment too late. Earlier research segmentation — separating "parameter-driven" vs "trust-driven" users — would have surfaced this before launch. I now build segment mapping into my research phase as a default step
Key lesson
Designing within heavy constraints forces sharper prioritisation. The MVP tradeoff wasn’t a compromise — it was a strategic choice that delivered 80% of the value at 30% of the technical cost. Understanding edge cases early prevents costly fixes later