Case study04 · Firefly

Driver Companionturning daily trips into extra income

A four-week sprint to launch the app that lets rideshare and taxi drivers earn extra income by carrying mobile out-of-home ads on their trips, and gives them a reason to keep coming back.

RoleSole product designer: research, IA, flows, UI, design system

TeamA design lead, a product owner and the development team

Timeline4 weeks to MVP

PlatformNative iOS & Android

7,000+drivers registered in the first month

+35%more hours driven by returning drivers

2markets at launch

4 weeksfrom discovery to an iOS & Android MVP

Context

Firefly needed a driver-facing app to launch two things at once: a way for drivers to earn extra income by carrying mobile out-of-home ads on their trips, and a reason for them to stick around afterward.

New drivers dropped off during onboarding, and existing ones had nowhere to go for updates, servicing or support, just a gap where a product should have been. As the only product designer, I owned the process end to end, working alongside a design lead, a product owner and the development team.

Driver checking the app in the car — Where the app lives: in the car, between trips.

The problem

Two different audiences needed two different things from one app.

01Acquisition: new driversA confusing or slow sign-up meant losing drivers before they'd earned a single dollar.

02Retention: existing driversWith no central place for updates, servicing or support, nothing pulled drivers back in between trips.

03Four weeksAn MVP for both iOS and Android had to ship in a single month.

The opportunitySolve both with the same product: an onboarding fast enough to convert, and a hub useful enough to keep people coming back.

Key decisions

Run discovery myself

I took part in the product owner's discussions and analysed industry benchmarks to understand current standards and capabilities, which also sparked ideas for where the app could stand out.

Desktop researchStakeholder interviewsIndustry benchmarks

Driver app user journey — Mapping the driver journey from sign-up to life on the road.

Structure before screens

I designed a clear information architecture first. It also set the MVP scope by identifying the essential elements for launch. User flows and a user journey for the core features then made sure onboarding and the everyday hub shared one coherent structure.

IAUser journey mappingUser flows

Early wireframes of the driver hub — Early wireframes: structuring the hub before visual design.

Prototype with the developers, not for them

Wireframes moved quickly into prototypes built in close collaboration with the dev team, so every screen respected what iOS and Android could actually ship in the timeline.

WireframesPrototypingImprovements

Interactive prototype of the home screen — Interactive prototype: swipeable earnings cards on the home screen.

A design language system early

With four weeks on the clock, I set up the design language system first, so the team could move fast on the remaining screens without relitigating the same decisions twice.

Design systemImprovements

The solution

One app, two jobs: convert new drivers quickly and keep existing drivers engaged between trips.

ProblemInaccurate driver & campaign dataDrivers applied through the website and self-reported their hours and locations, which was prone to error and led to suboptimal campaign decisions. Communication ran through call centres and paid text messages.

SolutionMobile sign-up & real-time dashboardThe app replaced self-reporting with real-time activity data for better campaign decisions and more impression inventory, and shows drivers their earnings, performance and payments as they happen.

ProblemSlow issue resolutionDrivers had to navigate different departments depending on the product or service, creating errors, miscommunication and underused support staff.

SolutionConnected servicesEvery product and service lives in the app, giving drivers a single point of contact and helping internal teams respond as one.

Onboarding that converts

Acquisition

A short, guided sign-up collects only what's needed (platform, vehicle and roof type) and confirms success clearly, so drivers get to earning without friction.

Account completion, platform and roof type selection — Complete your account: platform, vehicle and roof type.

Location permission, success and home screens — Location permission, confirmation and the first home screen.

A hub worth coming back to

Retention

Earnings, active campaigns and driving hours sit on one home screen, together with devices and services, giving drivers a reason to open the app between trips.

Earnings, wrap campaign and driving hours — Earnings, active wrap campaign and driving hours.

Driver app on a phone — Built for quick glances on the road.

Impact

More than 7,000 drivers registered in the first month across two markets. Returning drivers, the ones the retention half of the app was built for, drove 35% more hours than they had before.

7,000+drivers registered in the first month

+35%more hours driven by returning drivers

2markets launched

Takeaways

One product can do two jobs

Treating acquisition and retention as separate design problems inside one app made both clearer to solve.

Systems first, especially under pressure

Setting up the design language system early was what made a four-week, two-platform MVP realistic.

Constraints are design input

Designing with the developers from the start kept every screen shippable and removed rework late in the sprint.

Next case · 05
Digital Banking

helloonuroral@gmail.com LinkedIn

Updated last, 2026.