Marketplace
From dead ends to dynamic choice: Re-architecting a travel marketplace
How I led the design of a multi-provider marketplace architecture for Civitatis, a travel platform with 90,000+ activities, uncovering that the real challenge wasn't the UI — it was the data.
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.
The real blocker, however, wasn't the interface. It was the data model.
This project evolved from a UI redesign into a systemic re-architecture initiative — shifting the organization from single-provider logic to a normalized multi-provider marketplace architecture.
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 was straightforward: if we decouple availability from a single provider and compare alternatives in real time, we increase booking probability.
But early exploration revealed a deeper constraint.
You cannot compare what the system cannot define consistently.
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.
The data audit
Before designing the comparison UI, I conducted a structural audit of the catalog to understand what we were actually comparing. The findings reframed the entire project.
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). The simplified search model was unreliable without normalization.
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.
The data audit
Before designing any UI, I audited the catalog structure. Three problems made cross-provider comparison impossible: a single modality field encoding 9 unrelated concepts, a "number of travelers" field repurposed as vehicle type or duration, and critical booking details (duration, meeting point, inclusions) buried in unstructured text instead of structured data.
The UI wasn't the issue. The system lacked a consistent schema.
A unified booking flow
We 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, a new algorithm selects the "optimal option" — scored by price, ratings, cancellation flexibility, and provider reliability.
Book your activity
Select your preferences
Book your activity
Select date and group size
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 as low or unavailable could be selected. In a multi-provider architecture, 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, we surfaced availability states while preserving interaction. The language avoided false certainty, reflecting real system ambiguity.
Never fabricate scarcity — only surface real uncertainty. In a distributed marketplace, availability is probabilistic.
In a multi-provider architecture, availability is probabilistic — 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 reflect real uncertainty.
Never fabricate scarcity — only surface real uncertainty. In a distributed marketplace, availability is probabilistic.
Mobile
Beyond screens: designing the data model
The most impactful part of this project wasn't the UI — it was identifying and mapping the data standardization needed before any interface could work.
Systems thinking
Audited the full catalog to identify structural inconsistencies. Mapped how 9 different concepts were collapsed into a single field, and proposed a normalized data schema for cross-provider comparison.
Stakeholder alignment
Presented data findings to product, engineering, and business. Reframed the project from "build a comparison UI" to "standardize the data first" — changing the project roadmap.
Interaction design
Designed the end-to-end booking flow for desktop and mobile: simplified search, real-time comparison, optimal option highlighting. Built interactive Figma prototypes.
Cross-functional collaboration
Worked with PM and engineering to define scoring algorithm criteria (price, cancellation policy, provider score) and the phased rollout strategy.
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. I reframed the project from "build a comparison UI" to "standardize the data first" — shifting the organizational roadmap. In parallel, I designed the end-to-end booking flow and built high-fidelity prototypes for desktop and mobile.
What this work enabled
While the full marketplace rollout is part of the long-term roadmap, this design and research phase delivered immediate strategic value:
Data standardization roadmap
Created the audit and taxonomy that engineering is now using to normalize the catalog's data model across all providers.
Validated interaction model
The simplified Date + People input and multi-provider comparison pattern were validated through prototyping and stakeholder reviews.
Shifted organizational priorities
The data audit findings changed the project roadmap, elevating data quality from a "nice to have" to a prerequisite.
Get in touch
Let's talk.
Open to new opportunities. Based in Madrid, working globally.