← Back to portfolio
Quadrant Traveltech · PANGEA

Quadrant Travel Marketplace

I designed a B2B platform from scratch that lets travel agencies upload, structure and distribute their own product. A project I started as a UX designer and where I progressively took on Product Owner responsibilities.

Sector Travel Tech · B2B Duration 3+ years · ongoing Status In production
Quadrant Travel Marketplace product view

My role

Senior UX Designer + Product Owner

UX designer on the project: research, flows, prototypes, coordination with development and QA. Over time I took on the product decisions — prioritization, backlog, stakeholder alignment — until that role was formalized.

The best part of this evolution was having been on both sides from the start: understanding the user's needs and negotiating what to build and in what order.

The problem

Agencies with their own product couldn't operate as wholesalers

Quadrant Travel Cloud let them sell third-party product. But agencies with their own tours and services had no way to upload, structure and distribute them. The challenge wasn't designing a form — it was understanding a complex business flow (content, contracts, rates, bookings) and making it simple and fast for product managers.

Key decision 1

Split content, contracts and rates into independent layers

After the research we understood that creating content and loading rates are different tasks, handled by different user profiles. Content rarely changes; rates change every season. Splitting them into layers lets you update prices without touching the content and assign permissions by role.

Chosen
Three independent layers —content, contracts and rates— with independent editing.
Discarded
A single form with every field mandatory, handled by one profile.
Why
Profiles and rates of change are different. Updating rates shouldn't force you to touch the content.
Full onboarding flow Simplified · NDA
Part 1 · Content
Catalog
Onboarding modal4 steps
Tour detail
Part 2 · Contracts
Name & type
Conditions+ blackouts
Contract saved
Part 3 · Rates
Sheet setup
Rates
Discounts
Ready to distribute
Contract and rates setup in QTM
Contract and rates setup: loading by periods, with discounts and supplements.

Key decision 2

Start with tours only, to deliver value sooner

The tool was meant for multiple service types. We decided to start only with tours, because that's where agencies had the largest volume of product and where the impact would be immediate.

Product phasing strategy

Phase 1 · Now

Tours

  • Catalog and content loading
  • Contracts and rates
  • Booking management
  • Distribution to retailers
In production
Phase 3 · Future

Supplier access

  • Suppliers upload their own product
  • Open marketplace model
Roadmap

Deciding what not to build is as important as deciding what to. The criterion was clear: real usage volume, not pending complexity.

Key decision 3

Progressive step-by-step onboarding, not a single form

The first prototype was a long form on a single screen. In the user sessions we spotted a pattern: managers don't have all the data available at the same time. We redesigned the flow into 4 steps, working out which fields would be required and which optional to create an entry.

Before
A single form on one screen: either you completed it all, or nothing was saved.
After
A 4-step progressive modal, with only the essential fields to create an entry.
The insight
The flow should give the manager agility when loading, not force them to “guess” by filling in optional fields.

Results

A product in production

Product

Multiple modules validated with users and in production.

Process

A cross-functional way of working consolidated across design, PO and development.

Architecture

A 3-layer structure that scales without restructuring what's already built.

Role evolution

From UX Designer to Product Owner: a transition toward a more strategic position.

Montage of real QTM screens
A glimpse of the real product: catalog, tour detail, rates setup and pricing rules.

Reflection

What I'd do differently

I'd start documenting prioritization decisions explicitly sooner. Many were made in informal conversations and went unrecorded — which created context debt at different points in the project. I'd also set up usage metrics earlier: qualitative feedback is solid, but without quantitative data it's sometimes hard to justify certain prioritization calls.

Prototype and documentation available under NDA. The project is active and can be expanded on in an interview.

Next project

PowerLearn →