A Marketplace Where Flights Become Tradable Assets
TravelX is a web-based platform that transforms airline tickets into digital assets, allowing users to buy, sell, and transfer flights with unprecedented flexibility.
By combining travel and blockchain technology, the product introduces a new model where tickets are no longer fixed purchases, but tradable items influenced by supply and demand.
INDUSTRY
Travel, Crypto & Blockchain Technology
Travel, Crypto & Blockchain Technology
SCOPE
1st MVP - UX Strategy, Product Design and Website Design
1st MVP - UX Strategy, Product Design and Website Design
MY ROLE
Product Designer
Product Designer
TEAM
3 Product Designers, 1 Project Manager and 25 developers
3 Product Designers, 1 Project Manager and 25 developers
Context
Rethinking how flights are owned and traded.
Rethinking how flights are owned and traded.
Airline tickets have traditionally been rigid: once purchased, they are difficult—or impossible—to transfer, resell, or adapt to changing plans.
TravelX rethinks this model by turning tickets into NFTs ('NFTickets'), enabling users to:
- Resell flights they can’t use
- Trade tickets based on demand
- Transfer ownership seamlessly
- Trade tickets based on demand
- Transfer ownership seamlessly
At the same time, the product introduces financial mechanisms—such as auctions and bidding—into a space where users are not used to them.
This creates a fundamentally new behavior: treating travel as a dynamic, tradable asset instead of a fixed purchase.
Challenge
Making a complex system usable.
Three core tensions defined the product:
1. Two different user mental models
- Travel users: Familiar with booking flows, but not with crypto, wallets, or trading dynamics.
- Crypto users: Comfortable with auctions, ownership, and digital assets, but not necessarily with travel constraints.
2. High system complexity
- Auctions, bids, pricing dynamics
- Wallets, ownership, transfers
- Traditional booking flows
3. New and unfamilier behaviours
- Selling a flight ticket
- Bidding on travel
- Managing ownership of a booking
Making a complex system usable.
Three core tensions defined the product:
1. Two different user mental models
- Travel users: Familiar with booking flows, but not with crypto, wallets, or trading dynamics.
- Crypto users: Comfortable with auctions, ownership, and digital assets, but not necessarily with travel constraints.
2. High system complexity
- Auctions, bids, pricing dynamics
- Wallets, ownership, transfers
- Traditional booking flows
3. New and unfamilier behaviours
- Selling a flight ticket
- Bidding on travel
- Managing ownership of a booking
Discovery - Undesrtanding Two Industries
Given the novelty of the product, there was no direct benchmark to follow. To define the initial direction, we grounded the work in two adjacent domains:
Given the novelty of the product, there was no direct benchmark to follow. To define the initial direction, we grounded the work in two adjacent domains:
- Crypto products (wallets, marketplaces)
- Travel platforms (airlines, booking flows)
- Travel platforms (airlines, booking flows)
This allowed us to understand:
- Established mental models in both ecosystems
- Common interaction patterns
- Where friction typically occurs
- Established mental models in both ecosystems
- Common interaction patterns
- Where friction typically occurs
In parallel, we worked closely with stakeholders through interviews and collaborative sessions to:
- Define the product scope
- Align on business goals
- Identify key features for the MVP
- Define the product scope
- Align on business goals
- Identify key features for the MVP
Shaping The Product
With this foundation, we moved into defining the product structure and main flows. Given the complexity of the platform, early work focused on:
- Structuring user flows end-to-end
- Defining how core features connect (search, wallet, trading)
- Exploring different ways to present complex information
- Defining how core features connect (search, wallet, trading)
- Exploring different ways to present complex information
We developed low-fidelity wireframes to quickly iterate on:
- Navigation and architecture
- Key interactions (buy, sell, bid, transfer)
- Information hierarchy across screens
- Navigation and architecture
- Key interactions (buy, sell, bid, transfer)
- Information hierarchy across screens
Once the main flows were defined, we built a prototype to validate assumptions through user testing.
Prototype used in user testing
Key Decisions
Initial product decisions were informed by industry research and stakeholder input, but many assumptions were challenged once the prototype was tested with real users.
Usability testing across both user profiles (travel and crypto) exposed a clear pattern:
what made the product powerful also made it difficult to understand.
what made the product powerful also made it difficult to understand.
Rather than simplifying the product itself, the focus shifted to making its logic more accessible.
1- From Technical Terminology To Familiar Language
What we assumed
Users would adapt to crypto terminology if supported by onboarding and tooltips.
Users would adapt to crypto terminology if supported by onboarding and tooltips.
What testing showed
- Users didn’t understand terms like USDC, Airtoken, bids, or offers
- Even with explanations, terminology created friction and hesitation
- Some users failed to associate “tokens” with actual flights
- Users didn’t understand terms like USDC, Airtoken, bids, or offers
- Even with explanations, terminology created friction and hesitation
- Some users failed to associate “tokens” with actual flights
Decision
Anchor the experience in familiar travel language, not crypto concepts.
Anchor the experience in familiar travel language, not crypto concepts.
How it was solved
- Replaced system-driven terms with user-driven language (e.g. “flight” instead of “token”)
- Deferred technical terminology to later stages (wallet context)
- Simplified wording across key flows to reduce cognitive load
- Replaced system-driven terms with user-driven language (e.g. “flight” instead of “token”)
- Deferred technical terminology to later stages (wallet context)
- Simplified wording across key flows to reduce cognitive load
This allowed users to interact with the product without needing to understand the underlying technology first.
2- From Multiple Trading Options to Simplified Actions
What we assumed
Offering multiple ways to buy and sell (fixed price, auction, offers) would increase flexibility and engagement.
Offering multiple ways to buy and sell (fixed price, auction, offers) would increase flexibility and engagement.
What testing showed
- Users struggled to differentiate between bids and offers
- Too many options created confusion instead of empowerment
- Some users avoided interacting altogether due to uncertainty
Decision
Reduce visible complexity and prioritize clear, actionable paths.
How it was solved
- Simplified the number of available selling mechanisms in the MVP
- Focused on the most intuitive actions (buy, sell, bid)
- Removed less critical options (like “make an offer”)
- Too many options created confusion instead of empowerment
- Some users avoided interacting altogether due to uncertainty
Decision
Reduce visible complexity and prioritize clear, actionable paths.
How it was solved
- Simplified the number of available selling mechanisms in the MVP
- Focused on the most intuitive actions (buy, sell, bid)
- Removed less critical options (like “make an offer”)
Instead of exposing the full system, we focused on what users could confidently act on.
3. From search-only to exploratory discovery
What we assumed
Users would approach the product with a clear destination and use traditional search flows.
Users would approach the product with a clear destination and use traditional search flows.
What testing showed
- Not all users had a fixed plan
- Users were interested in opportunities (price, availability), not just destinations
- Auctions were hard to discover within traditional search patterns
Decision
Introduce a more flexible, exploratory way to browse flights.
How it was solved
- Users were interested in opportunities (price, availability), not just destinations
- Auctions were hard to discover within traditional search patterns
Decision
Introduce a more flexible, exploratory way to browse flights.
How it was solved
- Designed an “Explore” entry point focused on discovery
- Enabled browsing based on flexible variables (price, timing, deals)
- Integrated auction opportunities into browsing instead of isolating them.
- Enabled browsing based on flexible variables (price, timing, deals)
- Integrated auction opportunities into browsing instead of isolating them.
This shifted the experience from planning a trip to discovering an opportunity.
4. From Implicit System to Explicit Trust Signals
What we assumed
Users would trust the system if flows were functionally correct.
What testing showed- “Invisible” payments generated distrust
- Missing passenger information reduced confidence
- Users were unsure about ownership and transaction states
- Some didn’t fully understand they could resell their ticket
Decision- Missing passenger information reduced confidence
- Users were unsure about ownership and transaction states
- Some didn’t fully understand they could resell their ticket
Make critical information explicit and reinforce trust through the interface.
How it was solved- Increased visibility of passenger and ticket information
- Clarified transaction states and ownership
- Reinforced key moments (checkout, wallet, confirmation) with clear feedback
- Highlighted resell capabilities more prominently
- Clarified transaction states and ownership
- Reinforced key moments (checkout, wallet, confirmation) with clear feedback
- Highlighted resell capabilities more prominently
Trust was not treated as a layer—it became part of the interaction design.
High Fidelity Design
The final UI focused on:
- Clear hierarchy, prioritizing primary actions over secondary data
- Consistent patterns across flows (search, checkout, wallet, trading)
- Modular components to handle different states and scenarios
- Balanced density, allowing complex information without overwhelming the user
- Clear hierarchy, prioritizing primary actions over secondary data
- Consistent patterns across flows (search, checkout, wallet, trading)
- Modular components to handle different states and scenarios
- Balanced density, allowing complex information without overwhelming the user
Special attention was given to key areas of the product:
- Search & Explore, enabling both direct and flexible discovery
- Flight detail, combining pricing, availability, and trading options
- Checkout, reinforcing clarity and trust at critical moments
- Wallet, where ownership and transactions become visible and actionable
- Search & Explore, enabling both direct and flexible discovery
- Flight detail, combining pricing, availability, and trading options
- Checkout, reinforcing clarity and trust at critical moments
- Wallet, where ownership and transactions become visible and actionable
Search & Explore
Wallet
NFTicket
Website
Design System
Given the breadth of the MVP, building a design system was essential to ensure consistency and efficiency across the product.
The system included:
- Foundations (color, typography, spacing)
- Reusable components adaptable to multiple contexts
- Interaction patterns aligned across different features
- Foundations (color, typography, spacing)
- Reusable components adaptable to multiple contexts
- Interaction patterns aligned across different features
This allowed the team to:
- Maintain visual and functional consistency across a wide range of screens
- Speed up design and development workflows
- Support the product’s evolution beyond the MVP
- Maintain visual and functional consistency across a wide range of screens
- Speed up design and development workflows
- Support the product’s evolution beyond the MVP
Visit TravelX website
