Decision hypothesis: trip context belongs together
The prototype assumes a rider weighs origin, destination, date, seat availability, pickup zone, departure time, route fit, and the driver before requesting a ride.
Selected work Mobile product UX
Carpool App
Product Lab · self-initiated concept · not launched
I designed and prototyped a mobile carpool concept for Toronto-area trips, from finding a route to requesting a seat and arranging pickup.
- Role
- Product designer and UX engineer
- Context
- Self-initiated product concept
- Timeline
- MVP concept and build
Project study / 2026 conceptMobile product UX
01 / The work
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?
The prototype connects trip discovery, seat requests, and pickup coordination. It is a self-initiated concept; the assumptions below still need 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
The first unit is a shared trip with origin, destination, timing, and route context.
Staged
Pickup hypothesis
The concept tests showing pickup zones before exact addresses to limit early exposure of details.
Prototype
Mobile interaction model
The implemented screens provide a mobile interaction model for future user testing.
Evidence noteConcept evidence is based on product flows and implementation feasibility; live usage has not yet been measured.
02 / The question
The ride decision required more than a listing card.
Privacy hypothesis: reveal exact pickup details later
The product hypothesis is that exact addresses should remain hidden until there is enough intent to coordinate, using zone-level details first.
Role hypothesis: drivers and riders scan differently
The concept models drivers around seats, route tolerance, detours, and timing, while the rider flow prioritizes destination fit, pickup convenience, and driver context. This distinction still needs user testing.
Onboarding hypothesis: the first action should be self-explanatory
The prototype tests whether trip-first discovery can explain the product through the first interaction instead of a long onboarding sequence.
Project context
Product assumption: shared trips are time- and route-sensitive
The concept assumes a useful match depends on origin, destination, departure time, route overlap, available seats, and arrival expectations.
Product hypothesis: ride requests need more context
The hypothesis is that timing, cost sharing, route fit, and pickup logistics require more context than a generic listing, without requiring a full social network in the first version.
MVP hypothesis: start with a narrow marketplace
The concept assumes a marketplace covering every possible route would be difficult to seed, so the MVP direction focuses on repeatable Toronto-area corridors and recognizable trip patterns.
03 / The decisions
What to show before a rider requests a seat.
A route-centered discovery surface
Instead of showing an abstract list of drivers, discovery centers origin, destination, timing, and upcoming trip dates. This gives each ride a specific context before users compare seats or request access.
Pickup zones before exact pickup points
The request flow uses zone-level language first, then allows exact details later when a ride is accepted. The rule is designed to limit early exposure while preserving a practical coordination path.
Trip rooms as the coordination layer
Ride chat, seat status, and trip updates are grouped into a trip room so users are not forced to reconstruct the plan across disconnected messages.
Driver and rider actions stay distinct
Driver actions focus on offering seats and managing requests. Rider actions focus on finding a feasible ride and requesting a place. The interface avoids blending both roles into one unclear dashboard.
Approach & process
Model the trip before the ride
The structure starts with the shared trip as the primary object. Ride offers, requests, chat, and pickup zones attach to that trip instead of competing as separate features.
Separate browsing from commitment
Discovery screens keep the user in scan mode. Request screens add decision details only when the rider has enough context to act.
Use common mobile patterns deliberately
Cards, bottom actions, status chips, and progressive detail views use familiar mobile conventions and translate cleanly into the prototype build.
Reusable patterns
Cards with predictable information order
Each trip card follows the same hierarchy: origin and destination, date, route signal, available seats, and next action. That consistency matters more than decorative variation.
State labels for coordination
Status chips distinguish open rides, requested rides, confirmed seats, and coordination steps. Users should not need to infer whether a trip is still active.
Mobile layout rules
Primary actions stay close to the thumb zone. Dense ride details are split into sections so screens remain readable when viewed quickly on a phone.
The proposed experience From a shared route
From a shared route
to a shared ride.
- 01
Browse a trip
Start with origin, destination, date, departure window, and pickup zone instead of an undifferentiated ride list.
- 02
Request a seat
Inspect seats, route fit, timing, cost sharing, and driver context before requesting a ride.
- 03
Accept and coordinate
A driver accepts or declines the request, then the trip room carries chat and status updates.
- 04
Reveal pickup details
Exact pickup information stays deferred until a ride is accepted; cancellations and expired trips remain open states to test.
Inspect the concept states
Browse
Find a shared ride
The first screen starts with a trip context so a rider can scan origin, destination, date, departure window, and pickup zone together.
- North York → Downtown Toronto
- Weekday · 08:00
- Yonge & Finch pickup zone
- 2 seats available
Next action: Inspect trip
Request
Request a seat
The request view exposes the decision details that matter before commitment: driver context, route fit, timing, and cost sharing.
- Avery · driver
- Route overlap visible
- Arrival timing visible
- Pickup zone stays general
Next action: Send request
Trip room
Coordinate after acceptance
Once a driver accepts, the trip room carries status and chat while exact pickup details move from a zone to a confirmed point.
- Request accepted
- Pickup details locked until now
- Trip chat attached to the ride
- Cancellation remains explicit
Next action: Open coordination
04 / In detail
The work, up close.
Shared-trip context
Illustrative shared-ride scene. This image is not a product screen or evidence of user research.
05 / What it establishes
What the product concept makes testable.
A specific marketplace entry point
The prototype grounds discovery in shared routes and timing, creating a concrete first-use hypothesis to test with Toronto-area drivers and riders.
A staged coordination model
The prototype demonstrates how pickup information can move from a general zone to exact details later in the request flow.
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
The product structure was reviewed against the smallest viable marketplace loop: create a trip, offer seats, request a ride, accept, and coordinate pickup.
Privacy review
The pickup flow was checked for points where sensitive details might appear too early. Zone-level coordination became a product rule, not just UI copy.
Responsive implementation check
The SvelteKit and Capacitor direction keeps the product close to production constraints rather than treating the screens as static mockups.
Looking back
The design direction deliberately narrows the marketplace. The working hypothesis is that a focused corridor-based carpool loop will be easier to test than a broad ride concept with undefined trust and liquidity needs.
The next product step would be field testing the request and acceptance flow with real drivers and riders, then tightening the language around pickup zones, cost sharing, and trip etiquette.