hiRobin
Updated on 8th Oct, 2026
hiRobin is an AI phone assistant built for India, used by more than 1M people. Robin answers calls you can't take, speaks to callers in their language, and follows your instructions, like sharing an OTP with a delivery agent. It can also make calls for you.
An early-stage startup of about 11 people, with a design team of two: the founding designer and me.
Helping 1M+ people trust an AI with their phone calls
I redesigned how people set up, discover, and pay for Robin, an AI phone assistant built for India. In eight weeks I shipped four launches: a rebuilt instruction flow, a new home action bar, the app's first monetization system, and a new onboarding.
Role
Product Designer
Duration
July '26 - Now
Team
1 Founding Designer
1 Designer (Me)
Impact
3x
Weekly reach of New Instruction, from 6% to 20% of weekly active users
88%
Fewer low-quality instructions saved
+4.5 pts
Day-1 retention after the onboarding redesign, from ~28% to ~32.5%
Why Robin needed a rethink
Robin was growing fast. About 542K people signed since I joined, and weekly actives peaked near 228K. But most people installed Robin and never went deep: only ~18% ever made an outgoing call, and Robin handled a flat ~18.5% of inbound calls even as volume grew 6x.
The old design
The two actions that made Robin useful were hidden behind one unlabeled button. Instructions saved whatever users typed, including greetings like "hi".
Old home screen with the single floating button
Rebuilding instructions
Instructions are how users teach Robin, like "when a delivery agent calls, share the OTP". A vague instruction means Robin handles calls badly, and the user stops trusting it.
What the data showed
I analyzed the corpus of saved instructions. Much of it was redundant or low-value: greetings, fragments, and near-duplicates. The old flow had no feedback loop, so it saved whatever users typed. About a quarter of in-app instructions were under 20 characters, often just "hi".
The corpus also showed what people actually used Robin for. Delivery calls dominated, with about 64% of real instructions about sharing OTPs with delivery agents, followed by cab drivers and unwanted sales calls. That became the basis for the presets in the new flow.
Old instruction screen, which saved whatever users typed
Extract, show, confirm
I moved the structuring work from the user to Robin. The new flow gives users two ways in. They can pick a preset based on the most common use cases, like delivery, cab, and spam calls. Or they can ask Robin for anything else in their own words, by typing or speaking.
New instruction flow, starting from common use cases
If an instruction is incomplete, like "hi", Robin asks only the follow-up questions it needs to make it useful. Every instruction, preset or custom, then ends in a confirmation card that shows exactly what Robin will do. It's saved only once the user confirms.
New Instruction with confirmation card
Instructions that set themselves
We also built a notification reader. With explicit permission, Robin reads notifications from apps the user chooses and suggests instructions at the right moment. When a Swiggy order is confirmed, for example, Robin asks whether the user wants to set an instruction for that delivery. Setting instructions becomes something Robin offers, not a task the user has to remember. About 29K users turned it on, roughly half of those who saw the permission request.
Low-quality saves fell from ~25% to ~3%, and average instruction detail rose about 30%.
Making core actions visible
Robin's home screen had one floating button that opened a menu with New Instruction and New Call. It didn't say what it did, so many users never found either action.
Getting started
I looked at split and dual action patterns in apps like Zillow, Depop, and Airbnb. Nearly all of them toggle between two views, rather than start two separate actions. So I designed a bar that reads clearly as two independent actions.
The split action bar
A persistent floating bar with two labeled halves, New Call and New Instruction, gives both actions equal weight. Both are visible on every visit, with no extra tap.
They have an expanded and collapsed form based on scroll.
New home screen with the split action floating button
3x
New Instruction
Weekly reach from 6% to 20% of weekly active users
2x
New Call
Weekly reach from 11% to 22% of weekly active users
Designing the monetization system
I took a free app with about 1M users to its first paid tier, designing every step from the first upgrade prompt to cancellation.
Robin Premium plan screen
Drawing the line
Production data showed the median active user got about 12 calls a week. A free cap of 7 incoming calls would already touch most active users. So the free tier had to feel complete for light use, and Premium had to feel like an obvious step up.
The full system
Monetization is a set of connected states, not a single paywall. I designed several entry points to Premium: an upgrade banner in settings, and inline nudges at the moment a gated feature is turned on, like automatic handling for unknown callers or contacts.
Profile page with an upgrade banner and Premium-gated features
Behind those entry points is the payment system: UPI autopay, recovery for failed and pending payments, day-5 trial reminders, post-trial screens, grandfathering copy for existing users, a force-update screen, and cancellation.
UPI mandates are approved in the user's UPI app, outside Robin, so failures are common. The recovery screen explains what happened, confirms the user hasn't been charged, and makes retrying the obvious next step.
Recovery screen when UPI autopay setup fails
Towards a default dialer
I'm now exploring making Robin the phone's default dialer, so the assistant lives where calls already happen. As a separate app, Robin can only help with calls it's forwarded, which caps how useful it can be.
Caller card states and call log discovery cards
The direction
Caller card with quick actions to call with Robin, set an instruction, open WhatsApp, or place a regular call.
An AI layer on every call, with summaries, recordings, and "continue in chat".
Instructions in context, with a nudge to set one on contacts that have none.
Discovery from the call log, with "Robin could have handled this" cards, starting with food delivery calls.