Back to work

Travel booking App

UI/UX Designjan - mar 2026

Travel booking App

Role
UI/UX Designer
Duration
3. weeks
Team
Solo concept project
Tools
Figma, FigJam, Google Fonts

The Problem

Commuting in Kathmandu means crowded buses, unpredictable timings, and rides that cost more than they should. Plenty of people drive the same route every day with three empty seats, but there's no easy way for them to find each other.

I wanted to see whether a car-pooling app could make that match feel safe and simple enough that people would actually use it twice.

Pain Points

  • No reliable way to verify who you're riding with
  • Fare splitting happens over messaging apps, awkwardly
  • Ride timings rarely line up with office hours
  • Existing options feel built for taxis, not shared commutes

Research

I ran a short survey with 34 daily commuters and followed up with five interviews. The goal was to find out what stops people from sharing rides with strangers, rather than whether they liked the idea in principle.

Almost everyone said the idea appealed to them. The hesitation was always about the same thing: not knowing who would be in the car.

said safety was their main concern about sharing a ride
78%said safety was their main concern about sharing a ride
had never used a car-pooling service before
63%had never used a car-pooling service before
interviewees wanted to see a driver's rating before booking
4 of 5interviewees wanted to see a driver's rating before booking
"I'd share a ride, but I want to know who's driving before I get in. A photo and a name isn't enough."
Attribution: Participant 2, commuter interview

Defining the solution

The research pointed at trust, not convenience, as the real blocker. So verification became the centre of the design rather than a settings screen buried three taps deep.

I mapped the booking flow around three moments: seeing who the driver is, confirming the route matches, and splitting the fare without anyone having to ask.

Booking flow, from route search to ride confirmation.

Flowchart of the booking process across six steps.

Wireframes

Early wireframes. The first version buried driver details behind a tap, which testing showed people missed.

Six low-fidelity wireframe screens for the booking flow.

Final screens

Search, ride details, and confirmation.

Driver verification sits on the ride card itself, before booking, rather than on a separate profile page. Fare splitting is calculated automatically and shown upfront, so nobody has to bring up money.

A "women only" filter came directly from the interviews, where two participants raised it unprompted.

What I learned

My first wireframes solved the wrong problem. I'd focused on making booking fast, when the research was telling me people needed to feel safe before speed mattered at all.

If I took this further, I'd test the verification flow with people who've had a bad ride experience, since they're the hardest group to convince and the most useful to design for.