Focused application · Grab Driver Experience & Fulfilment

I’m a Senior Product Designer. I take ambiguous problems and ship measurable product outcomes.

Consumer growth, AI interaction, enterprise workflows. This page is the short version. Full case studies live in the portfolio.

Growth & retention AI-native interaction Enterprise workflows 0→1 product thinking
Selected work

Selected work and results.

Open a project to see the problem, what I designed and the results.

AirlearnFounding Product Designer · 2024

How do you get users past the moment they usually quit?

Problem

Free users stopped after 2-3 lessons per session. Users who crossed 4 were 3× more likely to return the next day.

Move

Ran behavioural analysis, then redesigned the session loop around XP, ranks, contextual nudges and reward progression.

2.9 → 4.3average lessons completed / session
28% → 39%Day-1 retention
Learning: The retention problem wasn’t content quality. It was helping users cross the behavioural threshold where one more lesson became worth doing.
Read full case study ↗
Mondee / AarnaProduct Designer · 2025

How do you make invisible AI states understandable under engineering constraints?

Problem

Voice AI had four states users couldn’t see. Rive was new and risky for engineering.

Move

Designed the full state system plus a lightweight motion fallback, so clarity didn't depend on Rive shipping.

5 dayscomplete flow designed, animated and handed off
3 of 5usability participants chose voice over touch
Learning: Good interaction design should survive technical compromise. The state model mattered more than the animation technology.
Read full case study ↗
BrowserStack / App LCASenior Product Designer · 2025-26

How do you prove setup friction is blocking users from reaching value?

Problem

97 customer groups entered onboarding over ~60 days. 12 reached the first AHA (first DSL execution). The biggest break: a 49% drop at app upload / App Live dependency.

Move

Defined 3 AHA moments, shipped sample apps as the quick fix, then drove an AI-first onboarding and authoring redesign.

97 → 12groups entering funnel → first AHA
49% droplargest single-step loss
~2 mo → ~2 wkseparate customer-blocking P0 shipped
Learning: Users were being asked to complete infrastructure setup before experiencing product value. The redesign focuses on reducing pre-value setup and getting users to an executable test earlier.
$30Kenterprise deal unblocked via Step Settings
21 users / 14 daysStep Settings adoption with zero onboarding
~2 months → ~2 weeksDDT from problem to production
See BrowserStack work ↗
Founder · Product Designer · Builder

Frim taught me to own the product, not just the pixels.

I framed the problem, decided what not to build, designed it, shipped it, talked to users and changed direction when the data said to.

The three projects above show how I work inside teams. Frim shows what happens when there's no PM, no roadmap and every product call is mine.

I built a consumer travel app from zero: problem, design, ship, learn, pivot.

01Started broad · AI trip planning, itineraries, travel utilities
02Learned fast · More features made the product harder to explain
03Cut scope · Simplified to one job: preserve the story behind a souvenir
Why this matters for a role like Grab

Driver Experience & Fulfilment needs designers who can simplify complex real-world workflows and make decisions when user, business and operational needs compete. Frim taught me to own those trade-offs end to end.

240 users · no paid push 700+ Android 130+ iOS
GTM experiment · Sri Lanka

I printed QR flyers, placed them in 20+ hostels, cafes and tuk-tuks across Sri Lanka. Zero ad spend.

124flyer scans
44beta signups
35%scan → signup
5partnerships

Every Sri Lanka signup came from physical placement. Every India signup came from LinkedIn. Context-driven acquisition beats audience-driven content for a travel product.

Read the full GTM note ↗
Grab Driver Experience & Fulfilment · Independent design exercise
GrabFood · Batched deliveries

One restaurant is late. What happens to the other deliveries?

A rider has picked up one meal and is collecting two more. The second restaurant is running late. Waiting delays the other orders; leaving without an updated route could create more problems.

Speculative concept built around a documented delivery challenge

Batched orders are common. Merchant delays are real.

Grab reported that around 40% of delivery orders were batched in 2024. It also describes merchant waiting time as an operational challenge and already optimises the sequence of stops.

Grab ESG report~40%of orders batched in 2024Read source ↗
Grab fulfilmentMerchant waitA recognised delivery constraintRead source ↗
Grab productStop sequenceGrab already plans batched routesRead source ↗

Public research establishes the operating problem, not that Grab's current delay interface is broken. The screens below are a proposed design to test.

The rider is at River Kitchen. The food won't be ready for 12 minutes.

Sushi House is already in the rider's bag. River Kitchen is the current stop. Green Bowl, two minutes away, has a ready order. The original route assumed River Kitchen would be ready when the rider arrived.

Sushi House · #4821Already collectedIn the delivery bag
River Kitchen · #573212-minute waitRider is here now
Green Bowl · #6194Ready for pickup2 minutes away
ProblemThe rider knows one restaurant is late, but cannot judge how waiting will affect the other deliveries. The app needs to make the next safe action clear.

Ask for one fact. Handle the route in the background.

The rider should not calculate delivery times or rearrange stops. They should only report the wait time the merchant gives them. Grab can then check whether a change is allowed.

01 / At pickupOrder not ready

Keep the report action on the current order. No separate issue centre.

02 / Merchant estimateAbout 10–15 minutes

Ask for information the rider can actually provide.

03 / Route checkCheck all active orders

The system weighs travel time, order readiness and delivery deadlines before suggesting a change.

04 / Next actionOne clear destination

Show where to go next, why the plan changed, and which order is still pending.

For this example, assume the system verifies Green Bowl is ready and the detour fits delivery-time and food-handling limits. Actual Grab rules and data would need engineering and operations validation.

A normal pickup, until the restaurant is late.

Use the buttons inside the phone as a rider would. The explanation beside it shows why each step exists.

9:41Grab Driver · concept●●●
At River KitchenSRG➤
PICKUP 2 OF 3

River Kitchen

Order #5732 · You're at the restaurant

Sushi House #4821 is already in your bag.
Illustrative design, not a live Grab dispatch action.
FOLLOW THE RIDER'S JOURNEY

At the restaurant

The food isn't ready. Tap Order not ready on the phone.

WHY THIS DESIGN 01 / 05
Keep the issue where it happens

The rider is already looking at River Kitchen. Reporting a delay shouldn't require leaving the pickup screen.

What changes

One familiar secondary action appears below the pickup details.

What we avoid

No generic issue menu and no need to contact support for a routine delay.

Did a delayed pickup become easier to finish?

PrimaryOn-time completion of delayed batchesCompare similar orders with and without the proposed flow.
RiderWaiting minutes and time to next actionMeasure whether uncertainty and idle time decrease.
CustomerLate deliveries and incorrect handoffsCheck that optimising one stop doesn't harm others.
GuardrailUnnecessary detours and support contactsMake sure the new flow doesn't add work.
Next testObserve delivery partners handling real delays, then validate dispatch feasibility with Grab operations.

Example merchants, times and system decisions are illustrative. No performance improvement is claimed.