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.
Selected work 
Mobile product UX
Carpool App
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.
- Status
- Product Lab · self-initiated concept · not launched
- Evidence
- Hypothesis
- Context
- Self-initiated product concept
- Role
- Product designer and UX engineer
- Timeline
- MVP concept and build
Project details
- Date
- 2026 concept
- Ownership
- Product definition, UX/UI and frontend prototype
- Collaboration
- Independent design and build
- Scope
- Discovery, mobile UX, product structure, frontend prototype
- Tools
- Figma, SvelteKit, Capacitor, Supabase
The case, before the polish.
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.
- 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.
Evidence class
Hypothesis
Concept evidence is based on product flows and implementation feasibility; live usage has not yet been measured.
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.
Prototype model
The interaction model the concept makes testable.
- 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.
Implemented concept UI
From finding a ride to arranging pickup.
These states are implemented interface decisions, not production usage evidence. The tabs make the request, acceptance, and disclosure sequence inspectable without a misleading dashboard screenshot.
State 01
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 action: Inspect trip
State 02
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 action: Send request
State 03
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 action: Open coordination
What riders may need before requesting a seat.
- 01
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.
- 02
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.
- 03
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.
How I approached the work.
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.
Components and layout rules
- 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.
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.
Shared-trip context
Illustrative shared-ride scene. This image is not a product screen or evidence of user research.
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.
Checks before research.
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.
A prototype for testing the ride flow.
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.
What the project clarified.
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.
Next: Pario Engineering WebsiteNext step
Let’s talk about your design team.
I’m a UI/UX & Web Designer. I design and build responsive websites and internal interfaces for insurance and B2B software teams.