Project detail
Refer & Earn UX for Riders
Hala's Refer & Earn for riders: one reward, one WhatsApp action and payout rules shown in the flow. Versus the old promo codes: +28% referral sign-ups, −11% CAC. Shipped in a few sprints.
Role: Product Designer. Product discovery, UX research, UX/UI design, prototyping, developer handoff
Team: Me, 1 product manager, marketing, 4 engineers
Platform: Hala Mobility rider app (Android)
Timeline: Jan – Mar 2025 · designed and shipped over a few sprints
TL;DR
Problem: Hala grew through time-limited promo codes. They were getting expensive, discount riders rarely came back, and the codes confused riders enough to generate support tickets. Happy riders had no easy way to bring friends in.
What I did: Designed Hala's Refer & Earn: one clear reward (up to 700 coins for both the referrer and the friend, scaled to the plan bought), one primary action (share on WhatsApp), and payout rules shown in the flow, scoped to ship in a few sprints.
Impact, compared with the promo-code period: +28% sign-ups through referral · −11% customer acquisition cost · −35% referral and code-related support tickets.
How it was measured: every sign-up was attributed to its referrer through their referral code, the same mechanism that credits the reward coins.
The problem: promo codes bought sign-ups, not riders
As Hala expanded into new cities, time-limited promo codes brought in first-time riders, but many never returned. Codes expired, conditions were unclear, and riders contacted support to ask why a code didn't work. Meanwhile the most credible growth channel, a happy rider telling a friend, had no product behind it.
I was asked to design an MVP that could grow organic acquisition without heavy engineering.
How might we create a referral experience people understand instantly, while keeping it simple enough to ship in a few sprints?
What I learned
I reviewed six referral programmes (Uber, Ola, Rapido, Bounce, Google Pay and PhonePe) and spoke with riders about how they recommend apps to friends.
Clarity beats reward size. Riders wanted to know exactly what they get, when, and whether it's guaranteed.
WhatsApp is the channel. Almost everyone preferred sharing there to copying links.
Complex rules kill intent. The more conditions, the more hesitation, which was exactly the promo-code problem.
I went in assuming a bigger reward would drive referrals. Research said riders first needed to trust the process. That reframed the project from "pick a reward" to "design for trust".
A referral has two users
The referrer needs to understand the reward and share it in one step. The friend needs a smooth path from a WhatsApp link to their first plan. I designed both sides of the loop.
Decision 1: Pay out when the friend buys a plan, not when they sign up
Options: reward on sign-up, which is instant and generous but invites fake accounts and pays for riders who never rent, or reward on the friend's first plan purchase.
I chose the first plan purchase, with the reward scaled to the plan's value, up to 700 coins. Every coin paid out maps to a paying rider, which is exactly where promo codes had failed.
The cost: a slower reward is a weaker motivator and a source of "where's my reward?" questions. So the payout condition sits in the flow itself, right under the reward banner, not in the T&Cs.
Decision 2: One action, WhatsApp first
Options: a generic share sheet with every channel, or one primary action.
I chose one primary CTA that opens WhatsApp with a pre-written message and the referral code, with a copyable code as the secondary option. Riders who prefer another app take one extra tap; research said they were the minority.
Decision 3: Ship without a referral dashboard
Options: an in-app tracker for invites and pending rewards, which most competitors had, or launch without it.
I chose to defer it. It needed new backend APIs and would have pushed the launch out by several more sprints. Referral codes still attributed every sign-up, so measurement didn't depend on it. I also ruled out gamified referrals (leaderboards, badges) because they didn't address the acquisition problem.
The final experience
Every section of the Refer & Earn page answers one question a rider has, in the order they have it: what do I get, how does it work, how do I share, and has it worked yet.
Onboarding introduces the programme in three screens: what it is, what you get, what your friend gets.
The friend's side: the referral code is an optional step at sign-up, so it never blocks a new rider, and both success and error states are explicit.
Built on the existing design system
I reused existing buttons, cards, wallet components, icons, typography and spacing, and added only one new pattern, the reward banner. That's what kept a few-sprint build realistic.
Validation and results
Before launch, I walked ops, marketing and support through the prototype: the reward was understood immediately, people chose WhatsApp naturally, and the flow felt fast. After launch, compared with the promo-code period:
+28% sign-ups through referral
−11% customer acquisition cost
−35% referral and code-related support tickets, because the rules were finally visible in the flow
What's next, and what I'd do differently
Pending reward status. I'd defer the full dashboard again, but ship a single "pending reward" line in the wallet: a fraction of the build cost for most of the reassurance.
A/B test reward value and message. We never isolated whether clarity or reward size moved the needle more.
Fraud checks, push notifications and milestone rewards once volume justifies them.
Want the full walkthrough? I'm happy to take you through it in an interview.
