YAL
One booking.
More than one traveller.
Booking a trip for someone else sounds simple. Until that person needs their own identity, documents, and travel history. I designed the journeys that connected travellers, organisers, and admins across YAL.
01 THE CHALLENGE
A travel platform with three sides to every trip.
YAL brings together travellers, travel agencies, and influencers who organise trips. Organisers create a trip, admins review it before publication, and travellers discover and book it. A booking then connects people to the trip group and the documents needed to travel.
I joined an existing project and collaborated with its previous product designer for one to two months. I then continued independently, delivering a new design direction to the client and working across the mobile app, organiser dashboard, and admin dashboard.
Alongside the interface redesign, I helped decide which features belonged in the first release. My discovery work centred on competitor analysis and discussions with the client and development team.
02 BOOKING FOR OTHERS
Choose the people, not just the number of seats.
A customer might book for themselves, another person, or several travellers. The flow needed to account for each traveller individually while preventing the same person from being booked into the same trip twice.
- Set the number of travellers.Each place in the booking needs an identified traveller.
- Choose an existing traveller or add someone new.Previously verified details can be reused. A new traveller completes the identity step within the booking flow.
- Make duplicate bookings unavailable.A traveller who already has a booking for this trip is disabled and marked “Booked”. The reason is visible before payment.
I worked with the backend and development team to align these interface states with how traveller records and bookings were stored.
03 IDENTITY & CONTINUITY
A traveller can exist before their account does.
Someone could have a trip booked for them before ever signing up to YAL. Creating an account later should not leave that history behind.
A traveller record
The passport image and OCR-extracted identity details are stored with the traveller’s booking.
A possible match
Verification during a new booking compares the passport identifier, first name, last name, and date of birth.
A connected history
The person confirms a limited trip summary before the previous booking appears in their profile.
If the person rejects the match, the record remains in the system without being attached to the new account. The proposed match alone does not transfer the history.
04 ROOM CHOICE
Make the shared-room saving visible before payment.
Shared accommodation could lower the organiser’s costs compared with separate private rooms. We made that an explicit booking choice, with a discount for travellers who selected a shared room.
A private room was the default. Choosing a shared room updated the price immediately, so the traveller could see the financial effect of the decision before paying.
The design also supported a separate group-booking discount. These were presented as distinct savings: one related to how many people were booked, the other to the room choice.
The example displays a 3% group discount and “Save 40 KD” for the shared room. These are sample booking values, not fixed discounts across every trip.
05 DOCUMENTS & PERMISSION
The right documents. For the right trip.
Organisers need documents such as passports, visa forms, or travel insurance to prepare a trip. That creates a workflow across two products: the organiser dashboard and the traveller’s app.
From the dashboard, an organiser sends document requirements to the trip’s travellers. The request in the app identifies the trip, who is requesting it, and which traveller the documents belong to. The organiser can then see what has been submitted and what is still missing.
Permission belongs to a trip, not an ongoing relationship.
Travellers could keep documents in their profile and choose when to share them. Booking a later trip with the same organiser did not automatically reopen access: the traveller needed to authorise sharing again.
For a traveller without an account, the person making the booking supplied their passport, joined the trip group, and handled further document requests on their behalf.
Trust had to work in both directions.
Travellers went through identity verification. Agencies and influencers submitted their own information for manual admin review before being approved as organisers. Trips also went through admin review before publication.
06 PRODUCT DECISIONS
Keep the trip. Trim the social network.
The initial scope included features that would make YAL a much larger social product. Based on competitor analysis and product discussions, I recommended removing several of them from the first release. The client agreed.
A shareable travel card
Instead of building an in-app photo feed, we created a branded image of the traveller’s history and countries visited, ready to share on Instagram. It gave people something personal to share and a way for others to discover YAL.
Follow the people who publish trips
Following organisers remained useful for hearing about new trips. Traveller-to-traveller following was removed from the initial release.
One group around the trip
We removed one-to-one messaging from the first release. After booking, the booker joined the trip group to ask questions and coordinate with the organiser and other travellers.
Use an existing habit.
Instagram already served the photo-sharing need. A branded card let YAL participate in that habit without taking on the scope of a photo-sharing platform.
These decisions were intended to reduce development effort and time to market while preserving the core travel experience.
07 LAUNCH & RECOGNITION
A product that made it into travellers’ hands.
YAL launched on Google Play and the App Store. The shipped product includes trip discovery, booking for yourself and others, travel profiles, shareable travel cards, trip groups, organiser trip submission, admin review, and document requests.
Third among 20 participating projects.
According to the client’s announcement, YAL placed third among 20 participating projects at the second Nexus exhibition in Kuwait.
The accompanying award photograph shows a prize of KD 1,500. The announcement was published on 6 December 2025.
Read the client’s announcement ↗Evidence: shipped functionality described by the designer, original design files, and the client’s public award announcement. No user testing or measured usability outcomes are claimed for this work.
08 REFLECTION
The hard part was deciding what belongs to whom.
A booking, an account, and a traveller are related, but they are not interchangeable. Separating them shaped everything from duplicate-booking states to how a person could later recover their travel history.
The same thinking applied to documents: access needed to follow the trip and the traveller’s permission. It also applied to scope: YAL needed the interactions that helped people travel together, without every feature of a social network.
Working across the app, the organiser dashboard, and admin tools made those dependencies visible. The design work was as much about aligning the product’s rules as it was about redesigning its screens.