TUI Tours, Immersive Tours Marketplace, E-commerce B2B+B2C

One-line outcome: Shipped a multi-market beta for TUI’s culturally immersive tours in ~8 months by turning an offline offer into an online proposition customers could evaluate—and operations could fulfill reliably.

TL;DR

Problem: A new, high-consideration tours offer needed to work online across markets without overpromising—while still relying on legacy back-office operations to fulfill the experience.
What I did: Led UX & product design end-to-end: research to understand purchase criteria and credibility cues, content modeling, experience design across markets/devices, and alignment with operations and engineering so booking states matched reality.
Key constraint: Legacy integrations + multi-market, multi-device rollout under a fixed beta timeline (~8 months).
Outcome: Beta shipped in ~8 months; qualitative: clearer itinerary and inclusions/exclusions content, risk-reduction patterns for high-consideration purchases, and booking flows grounded in back-office constraints.
Timeframe + role: 2022–2023 · UX & Product Design Consultant (Contractor) @ Softtek EMEA.

Context

In 2022–2023, TUI wanted to sell culturally immersive tours online—curated, culture-rich experiences, not classic holiday packages. The offer existed, but the digital proposition and positioning were new. That made the work risky: if the site didn’t build trust, people wouldn’t commit; if it promised more than operations could deliver, brand trust would take the hit.

Confidence was needed on both sides of the transaction. Travelers needed enough evidence to buy a “once-in-a-lifetime” trip, and internal teams needed certainty that bookings, confirmations, and hand-offs would work across markets and devices.

My Role & Team

I worked as a UX & product design consultant (contractor via Softtek EMEA), partnering closely with product, engineering, and operations stakeholders.

My scope: research, value narrative and content strategy, information architecture, key flows (browse → evaluate → book), prototyping, and usability testing.
Decision ownership: I framed options, made decision criteria explicit with stakeholders, and kept scope cuts clear so the team could ship without reopening the same debates.
Collaborators: product, engineering, and operations stakeholders across EMEA markets.

Constraints

Legacy + technical debt: We had to integrate with existing systems without compromising booking reliability.
New product, unproven digitally: The proposition and positioning hadn’t been validated online, so we needed evidence before committing to heavy build.
Multi-market, multi-device: The experience and content had to work across locales and mobile from the start.
Time to market: From kick-off to beta in ~8 months, requiring hard prioritization.

Approach

I sequenced the work to reduce two sources of uncertainty: “Will people trust and buy this?” and “Can we fulfill what we’re selling?”

Ground the proposition in evidence. I ran interviews and surveys to understand how travelers evaluate high-consideration trips and what credibility cues reduce risk. That became a content and structure requirement—not a “nice to have.”
Map the operational reality early. Pairing with operations revealed integration and fulfillment risks. I designed flows and states around inventory, confirmations, and hand-offs so expectations stayed realistic end-to-end.
Prototype content, not just UI. I prototyped and tested multiple versions (photo/story density, itinerary granularity, FAQ depth) to balance emotion with due diligence—because for these purchases, content is the product.
Ship a beta that could scale. I kept the MVP cut explicit so we could hit the beta timeline without building one-off UI that would collapse under multi-market needs.

Process at a glance

Phase	What it solved	Output (decision tool)
Credibility research	What makes travelers trust a high-consideration trip offer	Purchase criteria + credibility cues translated into content requirements
Ops mapping	Where legacy constraints impact booking, confirmation, and hand-offs	State model + flow decisions aligned to back-office reality
Content prototyping	Whether the offer reads as “premium” while staying concrete	Tested page structures (itinerary, inclusions/exclusions, FAQs)
Beta cut	What ships now vs later without breaking multi-market scaling	Clear MVP scope + reusable patterns for localization and maintenance

The two sides that had to match for the beta to work: travelers needed enough evidence to trust the offer, and booking states had to reflect real operational constraints—so the experience stayed credible end-to-end.


          flowchart TB
traveler["Traveler needs<br/>trust to commit"] --> offer["Credible offer<br/>content that answers questions"]
ops["Operations reality<br/>legacy constraints"] --> booking["Booking states<br/>that match fulfillment"]
offer --> beta["Beta experience<br/>multi-market, multi-device"]
booking --> beta
beta --> outcome["People can evaluate<br/>and ops can fulfill"]

Key Decisions & Trade-offs

Decision: Treat content as the product and use it to reduce purchase risk.
- Options considered: Feature-first marketplace with generic product pages; minimal pages optimized for speed; content-first pages optimized for evaluation.
- Criteria used: Trust for high-consideration purchases, clarity of logistics, and scalability of content across markets.
- Trade-off accepted: More upfront content modeling and testing vs shipping more “features” early.
- Resulting implication: People could judge value and fit before booking, with less guesswork.
Decision: Design booking and post-booking states around operational reality, not idealized instant confirmation.
- Options considered: Hide back-office constraints; over-engineer real-time integration; surface clear states and hand-offs aligned to current ops.
- Criteria used: Reliability, brand trust, and reduced risk of post-purchase surprises.
- Trade-off accepted: More explicit state handling (and less “magic”) vs a simpler happy-path UI.
- Resulting implication: The experience stayed credible end-to-end even with legacy systems underneath.
Decision: Ship a multi-market beta in ~8 months with scalable patterns instead of perfecting one market.
- Options considered: Single-market launch then expand; big-bang multi-market build; staged beta with reusable layout/content patterns.
- Criteria used: Time to feedback, localization readiness, and maintainability under a tight timeline.
- Trade-off accepted: Some local nuance and polish deferred vs earlier proof across markets.
- Resulting implication: The team could iterate after beta without re-architecting the experience.

Impact

Metric: Beta shipped in ~8 months.
Qualitative outcomes:
- The product was positioned for a premium, curated-travel audience through clearer itinerary detail and curation signals.
- The experience aligned expectations with back-office operations to help avoid post-purchase friction.
- The experience was designed to scale across EMEA markets and mobile devices from the start.
- Brand patterns were extended to support premium experiences without breaking TUI’s identity.
- Clearer value framing supported premium pricing for curated experiences.

What I Learned / What I’d Do Next

For high-consideration purchases, the fastest teams don’t move by shipping more UI—they move by agreeing on what makes the offer credible and what operations can actually deliver. When that alignment is missing, the experience becomes a promise the business can’t keep.

Next, I’d instrument the credibility cues that matter most (itinerary depth, inclusions/exclusions, FAQs) and keep iterating with operations on exception handling and hand-offs as markets scale.

If you want to see the internal operations side that supported this marketplace (states, permissions, exceptions, and throughput), this companion case study is the most directly related: