Designing a Unified Multi-Service Mobility Platform
Bringing ride hailing, school buses, carpooling, and drone delivery into one product.
Role
Sole Product Designer (0→1)
Scope
Research, IA, UX flows, visual design, design system, usability validation
Platform
Mobile
Client engagement
End-to-end product design partner
I designed a mobility platform from the ground up, bringing four different services into one experience while keeping each flow easy to understand.
The main challenge was creating a shared product language without making the services feel identical. Each service needed its own level of trust, information, and interaction.
What I did
- Researched mobility products through reviews, community discussions, interviews, and surveys.
- Created personas and mapped the main service journeys.
- Designed the information architecture, navigation, and service flows.
- Built the design system and applied it across 40+ screens.
- Designed different trust patterns for rides, school transport, carpools, and delivery.
The Challenge
The client was building a new mobility product that combined four services in one app.
The goal was simple: make the product feel unified without forcing every service into the same experience.
Four services
Each service came with very different user needs.
Simple navigation
Users needed to move between services without unnecessary layers.
Different trust levels
Safety expectations changed dramatically between services.
Built to scale
The system needed room for future mobility services.
My Role & Scope
Sole Product Designer
I owned the design from research through final screens, working directly with the client throughout the process.
- User research and synthesis
- UX, interaction design, and user flows
- Wireframing and prototyping
- Design system and reusable UI patterns
- Final product design across four mobility services
Design Process
4.1Research Approach
Because this was a new product, I looked at existing mobility services to understand what already worked, where users struggled, and what expectations each category created.
| Method | Purpose | Sample |
|---|---|---|
| Review mining | Find recurring problems | 400+ reviews |
| Community research | Understand real user complaints | 12 threads |
| Interviews | Understand user needs | 14 participants |
| Survey | Validate recurring themes | 210 respondents |
4.2Secondary Research
I reviewed products across ride hailing, school transport, carpooling, and drone delivery to understand common patterns and gaps.
Ride hailing
School transport
Carpooling
4.3Community Sentiment
Community discussions helped expose frustrations that do not always show up in app ratings, especially around tracking, reliability, and trust.
4.4Competitive Analysis
No single competitor covered all four services, so I looked at the strongest reference for each category.
| Product | Strength | Design takeaway |
|---|---|---|
| Uber / Lyft | Tracking and simple booking | Keep booking and status clear |
| BlaBlaCar | Route matching | Make trust visible before joining |
| Here Comes the Bus | Bus tracking | Make status easy to understand |
| HopSkipDrive / Zum | Child safety | Treat child transport differently |
4.5Personas
The research led to two primary user perspectives that shaped the core experience.
4.6Key Findings
Status should be obvious
Live tracking worked best when paired with simple status copy.
Trust changes by service
A school bus, carpool, and ride hail should not communicate trust in exactly the same way.
Keep the experience calm
Show the important information first and keep deeper detail available when needed.
From Research to Screens
The research gave me a simple direction: keep the shared experience consistent while allowing each service to behave differently where it matters.
Design Principles
Keep status clear
Users should quickly understand what is happening and what comes next.
Let services feel different
Shared components create consistency, while trust and safety patterns change by service.
Keep navigation simple
Users should be able to choose a service and move through it without unnecessary layers.
Show detail when needed
The default experience stays focused, with more detail one tap away.
Service Architecture & Navigation
The app starts with Home Hub, where users choose the service they need. Each service then has its own focused flow.
User Flows
I mapped each service separately so the main task and navigation were clear before moving into detailed screens.
Wireframe User Flows
Commuter Ride Journey
Flow 01
Home Screen
Choose a service and start a journey.
Add Location
Set pickup and destination.
Choose Ride
Compare options and pricing.
Request Ride
Confirm the ride and request a driver.
Schedule Ride
Choose a later date and time.
Ride Tracking & Completion
Flow 02
Finding Driver
See the driver match and arrival estimate.
En Route
Follow the route and current ETA.
Arrived + Tip
Finish the trip, rate, and tip.
Drone Delivery Journey
Flow 03
Find Delivery
Choose a delivery and delivery window.
Drone Dispatch
Follow the delivery and expected arrival.
Delivery Complete
Confirm the package was received.
Carpool Matching & Ride
Flow 04
Carpool List
Browse available routes and matches.
No Matches
Show a clear empty state when no match is available.
Carpool Detail
Review the driver, route, and match.
Continue Driving
Track the active carpool trip.
Meet Carpool
Confirm pickup and begin the trip.
School Bus & Child Safety
Flow 05
Safety Code
Verify the child before pickup.
Ward Confirmation
Confirm the child and bus assignment.
Add Ward
Add another child to the account.
Bus Map
See the route, stops, and ETA.
Meet Bus
Know when the bus reaches the stop.
Bus Arrived
Confirm arrival at the destination.
Dropoff
Confirm the trip is complete.
Bus CCTV
View the live feed when needed.
CCTV + Gift
Show the reward notification.
Key Screens
Home Experience
01
The home screen makes the available services easy to scan and gives users a direct starting point.
Ride Tracking
02
The ride flow keeps tracking, ETA, and the next action visible throughout the trip.
Drone Delivery
03
The delivery flow focuses on the current stage, flight path, and expected arrival.
Carpool
04
Driver details and verification are visible before users join a carpool.
School Bus
05
Safety and tracking are kept visible without overwhelming the parent with information.
Design System Highlights
Trust-based color tokens
Distinguish service types while maintaining a shared visual foundation.
Reusable tracking components
Maps, status, and next-action patterns can be reused across services.
Service card variants
Shared UI stays consistent while service-specific needs remain visible.
Status components
A common status language works across different service states.
Atomic design structure
Reusable building blocks provide a scalable foundation for the product.
Responsible Design
- No pressure based countdowns or urgency patterns.
- Important safety actions stay easy to access.
- Detailed information is available without overwhelming the default experience.
- Status language stays clear about what is actually being tracked.
Validation
The main services were easy to understand, but the first version made them feel too similar. Participants needed a clearer way to distinguish the different service options.
Iteration: Strengthened the hierarchy between services, reduced competing elements, and simplified the main flows.
Participants were able to identify the right service and understand the next step without needing much guidance.
Iteration: Kept navigation focused and made the primary action more obvious at each stage of the flow.
Outcomes
The final design brought the different services into one clear product experience while keeping each service flexible enough to support its own workflow.
mobility services unified in one experience.
screens designed across the platform.
- Created a consistent experience across rides, school buses, carpools, and drone delivery.
- Simplified the main flows so users could understand what to do next.
- Established a reusable visual foundation for the different services.
- Validated the core navigation and service flows through prototype testing.
- Time from selecting a service to completing the main task.
- Drop off at key steps across each service flow.
- Usage of more than one service by the same user.
Reflection
I would spend more time observing parents during real school runs. Seeing the experience in context could reveal problems that are easy to miss when working mainly with prototypes.
The product brings four very different services into one visual system without forcing them into the same experience.
“Consistency does not mean making everything look or behave the same.”
A strong system provides a shared foundation while giving each service enough room to solve its own problem.
The goal was not to make every service feel the same, but to give them a shared foundation that made the whole product easier to understand and use.
Thanks for reading.