Compare a route before committing
The discovery screen brings origin, destination, departure time, pickup zone and available seats together. Testing needs to establish whether that is enough to judge a trip.
Selected work Mobile product UX
Carpool App
Product Lab · self-initiated concept · not launched
I designed and prototyped a carpool app concept for Android and iOS, covering Toronto-area trips from finding a route to requesting a seat and arranging pickup.
Project / 2026 conceptMobile product UX
- Role
- Product designer and UX engineer
- Context
- Self-initiated product concept
- Timeline
- MVP concept and build
01 / Overview
My contribution
Product definition, UX/UI and frontend prototype
I started with three questions a rider would need to answer: where is the car going, when does it leave, and can I reach the pickup point?
I connected trip discovery, seat requests and pickup coordination in a mobile prototype. The concept still needs testing with drivers and riders.
- Working with
- Independent design and build
- Scope
- Discovery, mobile UX, product structure, frontend prototype
- Tools
- Figma, SvelteKit, Capacitor, Supabase
Trip-first
Discovery model
Riders browse shared trips by route and departure time.
Staged
Pickup hypothesis
The proposed flow shows a pickup zone first and reveals the exact address after acceptance.
Prototype
Mobile interaction model
Working mobile screens make the request and pickup flow available for user testing.
EvidenceConcept evidence is based on product flows and implementation feasibility; live usage has not yet been measured.
02 / Problem
What riders may need before requesting a seat.
Balance pickup planning with privacy
A pickup zone gives riders an approximate location while keeping the exact address private until acceptance. The tradeoff is uncertainty about walking distance before committing.
Keep agreement and coordination connected
A seat request is not yet a confirmed ride. The flow needs to distinguish pending, accepted and cancelled states and keep messages attached to the trip.
Project context
A match depends on the route and timing
My starting assumption was that riders need to compare origin, destination, departure time, route overlap, available seats and expected arrival together.
Enough detail to request a seat
I focused the first version on route fit, timing, cost sharing and pickup information. Whether those details give riders enough confidence to send a request remains a question for testing.
Start with repeatable Toronto-area trips
I limited the concept to a smaller set of recognizable routes. This gives an initial study a manageable scope while the challenge of attracting enough matching trips remains unresolved.
03 / Design decisions
What to show before a rider requests a seat.
Trip details in the discovery view
Listings show the origin, destination, timing, and upcoming trip dates before riders compare seats or send a request.
Pickup zones before exact pickup points
I show a general pickup zone before acceptance and reveal the exact point afterward. This limits early exposure but may leave riders uncertain about walking distance. A usability study should test whether the zone gives enough information to request a seat.
Chat and updates in the trip room
After acceptance, the trip room brings chat, seat status and updates together. A useful test would ask riders to find the latest pickup plan after a driver changes it, including whether cancellation remains clear.
Driver and rider actions stay distinct
Drivers offer seats and manage requests. Riders find a suitable trip and request a place. Each role has its own set of actions.
Design process
Organize the product around a trip
I grouped ride offers, requests, chat, and pickup zones under the shared trip they belong to.
Separate browsing from commitment
The trip list supports browsing. A separate request screen adds the details a rider needs before asking for a seat.
Use familiar mobile controls
The prototype uses cards, actions at the bottom of the screen, status chips, and detail views that open as needed.
Reusable patterns
Cards with predictable information order
Every trip card presents the same information in order: origin and destination, date, route fit, available seats, and next action.
State labels for coordination
Status labels distinguish open rides, pending requests and confirmed seats, including the steps that remain before pickup.
Mobile layout rules
Primary actions sit near the bottom of the screen. Ride details are grouped into sections for reading on a phone.
Proposed ride flow Finding a ride
Finding a ride
and arranging pickup
- 01
Browse a trip
Browse trips by origin, destination, date, departure window, and pickup zone.
- 02
Request a seat
Review available seats, route fit, timing, cost sharing, and driver details before requesting a ride.
- 03
Accept and coordinate
The driver accepts or declines the request. After acceptance, the trip room holds chat and status updates.
- 04
Reveal pickup details
Exact pickup details appear after acceptance. Cancellation and expired-trip states still need testing.
Screen details
Browse
Find a shared ride
The first screen groups the origin, destination, date, departure window, and pickup zone so riders can review them together.
- North York → Downtown Toronto
- Weekday · 08:00
- Yonge & Finch pickup zone
- 2 seats available
Next step: Inspect trip
Request
Request a seat
Before sending a request, riders can review the driver, route fit, timing, and cost sharing.
- Avery · driver
- Route overlap visible
- Arrival timing visible
- Pickup zone stays general
Next step: Send request
Trip room
Coordinate after acceptance
After the driver accepts, the trip room shows chat, status updates, and a confirmed pickup point.
- Request accepted
- Pickup details locked until now
- Trip chat attached to the ride
- Cancellation remains explicit
Next step: Open coordination
04 / Gallery
Project images
Shared-trip context
Illustrative shared-ride scene. This image is not a product screen or evidence of user research.
05 / Outcomes
Ready to test with drivers and riders.
Route and timing-based discovery
A study can ask drivers and riders to find a suitable Toronto-area trip by route and departure time.
A staged coordination model
The flow moves from a general pickup zone to an exact location after acceptance.
Screens ready for a usability study
The cards and request states provide a prototype for testing whether riders understand the route, seat status, and pickup sequence.
How the work was reviewed
MVP feasibility check
I checked the prototype through the full sequence, from creating a trip and offering seats to accepting a request and coordinating pickup.
Privacy review
I checked where pickup details appeared in the flow and used acceptance as the point at which the exact address becomes available.
Responsive implementation check
Building with SvelteKit and Capacitor let me check the mobile layouts and interactions in a working prototype.
Looking back
Showing a general pickup zone protects the exact address, but it also asks riders to decide with incomplete information. I would test whether that tradeoff works before expanding the concept.
The next step would be field testing the request and acceptance flow with drivers and riders, including the language around pickup zones, cost sharing and trip etiquette.