hero · marketplace
From dead ends to dynamic choice
How I designed the multi-provider architecture for a travel platform with 90,000+ activities, and discovered through a hands-on data audit that the real problem wasn't the UI, it was the data.
specs
hero-visual
executive-summary
Civitatis operates a catalog of 90,000+ travel activities globally. The booking flow was tightly coupled to a single provider per activity. When availability failed, the user hit a dead end.
No alternatives. No fallback. No recovery.
The business opportunity was clear: recover lost bookings by enabling multi-provider comparison at the moment of unavailability.
What started as a UI redesign became a re-architecture: I mapped the data model that had to exist before any comparison UI could work, and designed the flows on top of it.
Concretely: I ran the catalog data audit, proposed the normalized schema, designed the end-to-end booking flow, and built the prototypes used to validate it.
executive-summary
Civitatis operates a catalog of 90,000+ travel activities globally. The booking flow was tightly coupled to a single provider per activity. When availability failed, the user hit a dead end.
No alternatives. No fallback. No recovery.
The business opportunity was clear: recover lost bookings by enabling multi-provider comparison at the moment of unavailability.
strategic-context
In a catalog of this scale:
- Availability varies constantly
- Providers differ in pricing models
- Modalities are inconsistently structured
- Core booking inputs are overloaded
The result: Silent revenue leakage.
The hypothesis: decouple availability from a single provider, compare alternatives in real time, and booking probability goes up.
But early exploration revealed a deeper constraint.
You cannot compare what the system cannot define consistently.
strategic-context
At catalog scale, availability fluctuates constantly, providers differ in pricing models, and modalities are inconsistently structured. The result: silent revenue leakage. The hypothesis was simple: decouple availability from a single provider and surface alternatives in real time. But early exploration revealed the real constraint.
You cannot compare what the system cannot define consistently.
root-cause-discovery
The data audit
Before designing the comparison UI, I audited the catalog structure to understand what we were actually comparing.
Modality field overload
A single field was being repurposed to represent 9 different meanings: accommodation type, menu tier, duration, equipment, meeting point, pickup, route, schedule, and service plan.
People input semantics
The universal "number of travelers" field was overloaded: sometimes vehicle type, equipment, or even duration (1 "person" = 1 hour).
Hidden critical information
Key booking details, duration, meeting point, what's included, were buried inside unstructured description fields instead of structured data.
The UI wasn't the issue. The system lacked a consistent schema.
root-cause-discovery
The data audit
Before designing any UI, I audited the catalog structure. Three problems made cross-provider comparison impossible: one modality field encoding 9 unrelated concepts, a travelers field repurposed as vehicle type or duration, and critical booking details buried in unstructured text.
approach
A unified booking flow
I redesigned two things: how availability is queried, and how options are presented.
Simplified availability input
The booking form was reduced to its essentials: Date + People. No upfront provider selection, no modality filtering. This single query fans out to every connected provider simultaneously.
Intelligent option surfacing
All returned alternatives are displayed. When identical options exist from different providers, an algorithm selects the "optimal option". I defined the scoring criteria, price, ratings, cancellation flexibility, and provider reliability, working with product and engineering on the weighting.
approach
A unified booking flow
One query, Date + People, fans out to every connected provider. All alternatives surface, and an algorithm picks the "optimal option" using scoring criteria I defined: price, ratings, cancellation flexibility, and provider reliability.
design-decisions
Designing for low / uncertain availability
Not all providers expose real-time inventory. Some calendars sync with latency, creating states where availability is uncertain rather than definitively unavailable.
1. All dates remain selectable
Even dates marked low or unavailable stay selectable: one provider may be sold out while another still has inventory. Blocking selection would prematurely close the booking path.
2. Availability as signal, not barrier
Instead of disabling dates, I surfaced availability states while preserving interaction.
Never fabricate scarcity, only surface real uncertainty. In a distributed marketplace, availability is probabilistic.
design-decisions
In a multi-provider architecture, one provider may be unavailable while another still has inventory. The key decision: all dates remain selectable, with availability surfaced as a signal rather than a barrier.
Never fabricate scarcity, only surface real uncertainty. In a distributed marketplace, availability is probabilistic.
prototypes
Interactive prototypes
I built high-fidelity interactive prototypes for both desktop and mobile to validate the flow in stakeholder reviews.
final-designs
Desktop
Mobile
my-contribution
Beyond screens: designing the data model
The UI was only the visible layer. These are the deliverables I owned end to end.
Data audit & schema
Audited the full catalog, mapped how 9 different concepts were collapsed into a single field, and proposed the normalized schema that makes cross-provider comparison possible.
End-to-end booking flow
Designed the full booking flow for desktop and mobile: simplified Date + People search, real-time provider comparison, and optimal-option highlighting.
Prototypes
Built high-fidelity interactive Figma prototypes for desktop and mobile, the artifacts used to validate the flow in stakeholder reviews.
Scoring criteria
Defined when one provider's option outranks another's, the logic behind the "optimal option", and shaped the phased rollout strategy with PM and engineering.
my-contribution
The most impactful work wasn't the UI, it was the data model. I audited the full catalog, mapped the structural inconsistencies, and proposed a normalized schema for cross-provider comparison. On top of it, I designed the end-to-end booking flow, defined the scoring criteria behind the "optimal option", and built high-fidelity prototypes for desktop and mobile.
outcomes
What this work enabled
While the full marketplace rollout is part of the long-term roadmap, this phase produced three concrete deliverables:
Data standardization roadmap
The audit and taxonomy engineering is now using to normalize the catalog's data model, findings that elevated data quality from a "nice to have" to a roadmap prerequisite.
Validated interaction model
The simplified Date + People input and multi-provider comparison pattern, validated through prototyping and stakeholder reviews.
Uncertain-availability pattern
A calendar pattern where every date remains selectable and availability is surfaced as a signal, not a barrier, reflecting real uncertainty instead of fabricating scarcity.
contact