Enter password to view case study
overview
Designing a multi-platform shuttle system for real-time coordination for riders, drivers and admins.
I led product strategy and end-to-end experience design, transforming a manually coordinated system into a unified platform across riders, drivers, and admins. The work focused on structuring real-time information flow, defining system states, and enabling each role to operate with clarity under real-world constraints.
80 %
of the community adopted the system within the first week of launch.
8 / 10
average ease-of-use rating from users interacting with the system.
30 min
reduction in average rider wait times.
43 days
from initial discovery through launch of the system.
PROBLEM SPACE
A system held together by manual coordination and guesswork
The mobility system supported a private community of ~300 people, helping them move between locations throughout the day. But behind the scenes, it relied on fragmented tools and manual coordination.
As usage grew, this became harder to sustain. Wait times varied, decisions were reactive, and the experience was difficult to rely on. With minimal to no structure, it was difficult to:
understand shuttle status including delays
measure shuttle demand
estimate fuel costs
plan driver scheduling or hiring
To better understand how this played out in practice, I spoke with riders, drivers, and admins to map how the system actually worked day to day.
DISCOVERY
Fragmented operations across roles
Through interviews, I found that each group operated with a different, and often incomplete, information. This led to inefficiencies, delays, and an experience people couldn’t rely on.
There was clear potential in aligning how they operated.
Riders
No visibility into shuttle location or driver behavior → difficult to estimate arrival time
Know when the shuttle will arrive to plan pick-up timing
Drivers
Balance scheduled routes with on-demand requests → routing and timing become inconsistent
Manage routes & requests efficiently while staying focused on driving
Admins
Fill coordination gaps through texts and calls → act as the middle point across riders and drivers
Reduce back-and-forth and better forecast usage
A shared framework that meets the users where they are.
kick-off
Strategy Workshop
Goal: Start with the why and who, then clarify what we’re building, how it should work, and by when.
Participants: Stakeholders and engineering lead
Duration: 3hrs total
Creating a new ecosystem
PROCESS
How we shaped the ecosystem
The core challenge was not just designing interfaces, but aligning how information flows across riders, drivers, and admins. I focused on defining: what information each role needs, when it becomes visible and how it updates in real time.
Information Flow
Co-Design/Dev Session
Where we STARTED
What we EXPLORED
Where we ENDED
User Testing
Real-time tracking
Enable real-time shuttle location tracking
How frequent does ETA need to be to feel “real-time”?
Is second-level updating technically feasible?
What is the impact on battery and system performance?
Balancing accuracy with performance constraints, we introduced adaptive update intervals:
Near stops (within 500m): update every 1s to maintain pickup accuracy
Away from stops (>500m): update every 10s to reduce battery and system load
Cancellation flow
Enable real-time cancellation with driver notifications
How do we prevent accidental cancellations in a non-happy path?
How visible should cancellation updates be for drivers?
How do we communicate changes without interrupting driving focus?
Balancing error prevention with timely communication, we introduced controlled cancellation and lightweight driver signals
Added confirmation step to prevent accidental taps for riders
Withdrew requests directly from the driver’s view instead of sending alerts
Synced cancellation status in real time across riders, and drivers
CHALLENGE
On the rider app, we faced a technical constraint around user account verification.
Here's what we're working with.
We first aligned on priorities and constraints.
Priorities
Must have:
Ensure emails are valid
1 account per user
Prevent spam/invalid sign-ups
Nice to have:
Seamless user experience with minimal steps
Constraints
99% of users are international audience
—> may not have a US phone number
50% of users are short-term users (between 2wks - 1mo.)
-> may have limited data services
Given compatibility issues, typical methods were not feasible.
So we explored alternative routes.
We used a password setup flow as a workaround for email verification, leaning into what our system could support while still enforcing one account per user.
Beyond meeting the baseline requirement, this reduced reliance on external verification services, helping us avoid additional costs and keep the onboarding stack lightweight.
This approach introduces some friction compared to click-to-verify, but remains a familiar pattern and was acceptable given our constraints.
In higher-stakes onboarding flows, we’d prioritize a more seamless, in-app verification experience.
Ideal vs. implemented verification flows
⚡️
FINAL DELIVERY
A three-way shuttle system for real-time coordination.
Riders
Request and track rides
Easily request a stop, track the shuttle in real time, and understand when it will arrive.
View shuttle location on map
Request stop for pick-up
See real-time ETA
Cancel request
Drivers
Manage routes and requests
View the route, see incoming requests, and update ride status throughout the journey.
View shuttle location along route
See requested stop
Mark ride completion
Admins
Main Dashboard
A centralized dashboard for bus managers and stakeholders to monitor shuttle activity and performance.
Live bus location
Invitation codes to manage groups
Weekly sign-up completion
Weekly ride completion
Control Center
A centralized space to manage users, stops, and access through invitation codes.
Manage users
Manage stops
Manage invitation codes
FINAL THOUGHTS
By designing around real user behavior and achieving reliable day-to-day operations, we’re now expanding to support more!
WHAT I LEARNED
Focus on the core problem while meeting users where they are
Reducing uncertainty matters most, so the experience stays simple and focused on request and tracking.
Safety comes first, so interactions must stay minimal while still supporting flexible routing.
Prioritized visibility and activity tracking over complexity overflow.
This new system has been well-received by the users and showed quick adoption with consistent use. Some of the biggest outcomes are noted here.
WHAT'S NEXT
Scaling the system for multiple shuttles
With demand expected to grow, the next step is expanding the system to support multiple shuttles operating in parallel. Some questions to solve:
Will adding 1+ shuttle be enough to support growing demand?
Will drivers be assigned to specific shuttles or will be alternate?
How do we let riders know which shuttle they are getting on?
