I designed Yooca from scratch — a self-initiated concept for a chauffeur-on-demand app where a vetted driver comes to drive your own car. The design challenge: turn a phone-call booking into a two-minute, trustworthy experience.
What this shows
A real-world service-marketplace flow — a designated-driver app where a vetted driver comes to drive your own car. The core design problem: effortless booking has to feel trustworthy enough that you hand over your keys to a stranger. This concept works through that problem end to end: research, IA, trust architecture, pricing transparency, and a complete design system.
The challenge
In the UAE, plenty of people own a car but can’t — or shouldn’t — drive it: a glass too many after a party, a school run during a meeting, a pet to the vet, moving the car across town. A taxi doesn’t solve any of that. The existing answer was a phone call to a driver agency: opaque pricing, no trust, and no idea who’d be behind the wheel of your Aston Martin.
My brief: turn that phone call into a two-minute, trustworthy booking — pick the occasion, choose your car, see the price, and hand the keys over with confidence.
Built for real life
Don’t drive after a drink — we’ll get you home in your car.
A trusted driver for the morning run.
Leave from home in your own car.
Get your car somewhere without you.
For trips you can’t make yourself.
We take it in and bring it back.
Discovery
I won’t hand a stranger my car
Trust is everything when it’s your own vehicle. People needed to know who was driving — and that it was safe.
How much is this going to cost?
Price anxiety killed bookings. A vague phone-quote felt risky; people wanted the number before committing.
I need this right now
The “after party” case is urgent and emotional. Any friction at 2am means they drive themselves — the worst outcome.
From how the designated-driver service worked before any app — a phone call, cash, and trust — and a teardown of adjacent on-demand booking flows. Framed as the problem to solve, not measured research.
The booking flow
I designed the whole journey to be finishable in under a minute — every step removes a question.
Key decisions
Every design decision is deliberate — rooted in how the service works offline and first-principles reasoning about what removes friction and builds trust. These are the three that shaped the experience most.
The product wasn’t a ride. It was the confidence to hand over your keys.
Concept output
This is a self-initiated concept — no live metrics exist. The design decisions are grounded in how the designated-driver service worked before any app, and a teardown of adjacent on-demand booking flows. I’d validate the core bets against time-to-book, completion rate, and repeat-booking rate from day one.
Reflection
The flagship use-case is urgent and often impaired. A stripped, one-tap late-night flow would beat the standard journey — I scoped it for the next release.
40–85 AED reduced anxiety but didn’t kill it. A tighter, route-based quote up front would convert better — worth the extra engineering.
I’d surface driver photo, rating and ETA earlier — proof beats promises when it’s your own car on the line.
Design system
Palette
Typography — Inter display, DM Sans body
Key components
Intent-first entry points to the booking flow.
The estimate, shown before you commit.
One bright, unmistakable action per screen.