Rideshare designed around local mobility habits.
How might we make rideshare work with, rather than against, existing mobility habits?
Conventional rideshare models assume algorithmic pricing and digital-first payments. Research showed those assumptions don't map onto mobility neatly in some emerging markets, like Malawi.
Fares are negotiated
Riders and drivers agree on price. Algorithmic surge pricing has no precedent.
Trust runs on relationships
People choose drivers they already know, not the nearest anonymous match.
Cash and mobile money rule
Digital-first payments don't reflect how people actually transact day to day.
A rideshare experience built around existing behavior
Swift adapts the model around four core needs: price control, trust, familiar payments, and reliable driver relationships, using what already works as the starting point.
Flexible pricing
Riders and drivers agree on a fare before the ride begins, retaining the price negotiation people understand.
Choose who to ride with
Favorite drivers surface first, with ratings and verification for context on new ones.
Familiar payment methods
Riders can make payment through methods they use in transactions including cash and mobile money.
Reliable rides
Riders see driver availability and reliability signals before choosing who to ride with.
Driver-friendly economics
Drivers are paid immediately after each ride and just have to pay a small monthly fee rather than a commission.
How the product came together
The process wasn't linear: research, design, and product decisions evolved together.
Understand the behavior
I studied people move using local taxis from how they negotiate fares and choose drivers to how they pay for rides. This surfaced four recurring needs: trust, payment flexibility, and reliability.
Turn behavior into product principles
A flexible model built around trust and negotiation best aligned with existing behavior.
Design around the constraints
Feedback from 30 evaluators surfaced gaps in the driver experience, shifting focus to how the marketplace works for both sides.
Pressure-testing critical assumptions
Before building this further, I am pressure-testing some assumptions around whether Swift offers enough value for riders to change booking habits, how much price flexibility they want, and whether driver economics support acquisition and retention.
What this project taught me
Design for how people actually behave
Popular product patterns don't always fit every context. The strongest decisions came from understanding behavior.
User trust is a core product spec
User trust shouldn't be an afterthought; it has to be built into the product. Favorite driver feature puts this into practice.
Product decisions require broader systems thinking
A good rider experience depends on a good driver experience. Incentives and pricing need to create value for both.
