Case study · Passenger app · Ride-hailing in Paraguay
I designed muv's passenger app end to end, from survey and funnel analysis to a launched app. Onboarding went from 21 steps to 6, and the ride flow now says what is happening at every state.
muv is a Paraguayan ride-hailing marketplace. Riders place it between Uber, the safe and established option, and Bolt, the cheap one: muv is the good service, with a fair price for the quality, good drivers and a car that is easy to spot.
The business was growing fast on the legacy app, from 1,000 to 6,000+ drivers and from 2,000 to 39,000 passengers since 2024. But in a June 2025 survey, overall satisfaction came out at 5.99 out of 10: neutral, with nothing that builds loyalty.
% of respondents
Survey, June 2025, about 120 to 150 answers per question. The sample was mostly customers of B2B brands, so it leans towards corporate users.
Most of this was technical and about driver availability, not about the interface. Design couldn't make an ETA accurate, but it could stop leaving people guessing.
That became the brief: make every state of a ride explicit, predictable and trustworthy.
"The app says 1 minute and it's really 10 or more."
Survey respondent, June 2025
"Good fares, but nobody ever accepts your ride."
Survey respondent, June 2025
"In Asunción very few drivers accept trips. In Encarnación I always get good service."
Survey respondent, June 2025
The survey
Registering and logging in were rated easy. The trouble was using the app: finding, booking and following a car.
The funnel
Onboarding had 21 steps, and only 25% of the people who started it finished it.
The survey only reached people who had already made it in, so it couldn't see the drop-off. The funnel could. Onboarding had to bring more people in, and the ride flow had to keep them.
Includes the Unid integration and the value proposition, with a basic profile setup.
A hybrid navigation model.
Requesting a ride, and sending or receiving packages.
A new section to gather feedback and improve the product.
Secondary flows: account, favorites, payment methods, my trips and promotions.
A ride is a real-time system, so what the passenger sees has to match what the backend is doing. Before opening Figma I mapped the whole journey as five states, and wrote what the passenger should read in each one.
Route on the map. A skeleton loader shows while availability is calculated.
A five-minute free-cancellation countdown runs while the driver decides.
"Waiting for the driver to confirm…"Review with preset comments and trip characteristics.
I put two low-fidelity homes in front of users: a photo header, and a live map. The map won.
It wasn't about looks. People think about a ride spatially: where am I, where is the car. So the map became the home, and the services sit in a sheet over it.
Home, trip category selection, in-trip driver state and review. Validating hierarchy and state transitions here caught edge cases before visual design.
Destination, categories, searching, confirmed. Every screen tells the passenger what the app is doing, so nothing feels stuck.
Enter your destination
Origin and destination, with recents and favorites one tap away. The ueno rebate is already visible.
Confirm trip
Economy, Muv and Comfort with time, seats and price. "Recommended" is preselected, and the rebate sits above the payment method.
Waiting for confirmation
Ripples spread around the pickup while the driver decides. A card fills the wait, and cancelling stays one tap away.
Arriving in 5 minutes
The ETA leads, then payment and the trip. The driver card shows who is coming, in which car, with the plate and one button to message.
Send reuses the trip flow and its components: address entry, categories with a recommended option, and one clear action. Sending needs a card, so the home asks for one first. After the details step comes the delivery, and the same rating.
The wait is the most critical moment in a ride-hailing app, so movement here serves a single purpose: to answer the question before the passenger even asks it. Is it working? Where am I? What happens next?
We help users eliminate anxiety during the wait through subtle micro-interactions.
Five things move at once, and each one calms a different worry.
The sheet holds its shape while availability loads, then the real categories rise gently into place. Nothing jumps, so the passenger never loses their place.
Try it. The tags change with the score, every chip answers the tap right away, and the card leaves softly once the passenger is done.
The home is a live map with a single "Where do you want to go?" field. The two services, Ride and Send, sit in a sheet over it, and the sheet changes with what is happening: an active trip, a pending rating, or recent destinations. It came straight from the test: people think about a ride spatially.
60% of respondents didn't trust the cars the app showed, and accuracy wasn't something design could fix. So every wait has a name and an end: a skeleton while availability is calculated, "Waiting for confirmation", "Widening the search radius", and a five-minute free-cancellation countdown while the driver decides.
Preselecting "Recommended" (Economy) lets a passenger confirm in one tap, and steers demand towards the category the business wants to grow. The other categories stay in the same list.
Credit cards were the first payment method in the survey, so the ueno bank rebate (40% back with a credit card, 20% with debit) shows on the destination screen and again above the payment method, instead of on a separate promo screen.
I ran six moderated sessions with the prototype, on two tasks: requesting a trip, and taking a trip with stops and rating it.
| Task | What worked | What needs work |
|---|---|---|
| Request a trip | The search-bar request flow and the confirmation step. The search animation and placing the pin by hand on the map. |
Search should prioritise results near the user (Asunción), so trips don't resolve to addresses in other cities. |
| Trip with stops | The search animation. |
People found the feature, but the logic confused them: where the stop goes, and an icon-only entry point. They preferred text over an icon alone. |
| Rating | Preset comments, emojis and three trip characteristics. The characteristics helped people give a better rating. Ratings skew to 5 stars when the ride is fast and uninterrupted, and bad ones show up only after extreme experiences. |
Continuing without writing a comment needs a clearer path. |
The full passenger journey, screen by screen: from opening the app to rating the ride.
21 → 6
Steps in onboarding.
25% → 36%
Of people who started onboarding finished it: +11 percentage points.
These were the targets for 2026 when I worked on the app. They are estimates, not measured results: I'm no longer at the company, so I don't have the numbers after launch. The plan to get there had five levers, and the new passenger app was one of them.
Design shaped the first two levers: onboarding and login, and how payment and rewards show up in the flow. The other three are business and supply work, and I'm not claiming them.
Q4 2025, on the legacy app. I don't have these two numbers for the new app.
Mapping every state before opening Figma saved weeks of rework and made the experience coherent from end to end.
The map vs photo test wasn't about visual preference. It was about mental model, and that settled the whole home.
Annotating design against implementation in Figma Dev Mode turned QA from a confrontation into a shared task.
Navigation, services, the category card, payment and the driver card: built once, and reused across ride and send.
Reintegros ueno: 40% con crédito y 20% con débito.
9873
Servicios
Viaje
Envío
980 654Tu viaje
Mi casaAv. Del libertador 5564
Departamento mamáEduardo Madero 2836
Casa IgnacioDirección completa
OficinaDirección completa
Ésta semana te llevamos 2 veces hacia Eduardo Madero 2836 ¿Querés agregarlo como favorito? 😉
Every component maps to a backend state, so there is no ambiguity between the UI and the system.
Driver, ETA and plate are always prominent. Payment and route are contextual.
States are props on one component, not separate components.