All work
Let’s driEV · Community app · V1 and V2

Giving students confidence in every ride.

How a campus-only EV scooter app replaced WhatsApp bookings with live availability, battery visibility and a pre-book feature that came from watching what students still struggled with after launch.

Role
Solo Product Designer
Scope
Research, UX and UI across V1 and V2
Platform
Native mobile app, Android and iOS
Users
University students, teachers and staff
Tools
Figma, FigJam, Photoshop, Illustrator
Let’s driEV community app screens
Product context

One company, two business models

driEV rents EV scooters in Bhubaneswar and has since expanded to Bengaluru. It runs two separate models, each with its own product, pricing and rules. This case study covers the Community model — the Rental model is covered in the website case study.

Community model · this case studyRental model · website
Who can use itUniversity students, teachers and staffOpen to anyone
ProductNative mobile appWebsite, desktop and mobile
PricingPer minute plus per kilometre. No long plans.Fixed price per plan: daily, weekly, monthly or yearly
BookingTime-slot based, not 24-hour. Pre-book with a small token.Pick a plan, a date, then pick-up or delivery
Pickup & returnA station hub on each campus. Students book from their own college’s station and return it there.Pickup from a warehouse, or home delivery
The problem

Booking a scooter meant waiting for a WhatsApp reply

Before the app, students booked by messaging the company’s WhatsApp Business account and waiting for a manual answer. It cost the business revenue and trust.

  • Slow responses and missed messages
  • No real-time information on which vehicles were available
  • No battery information, so students sometimes arrived to a low-charge vehicle
  • Lost revenue and low trust in the service
Research

Students were uncertain, not reluctant

I visited stations, watched how students approached the vehicles, interviewed the operations team and students, and read through the WhatsApp message logs.

Availability was invisible

The most common question students asked was whether any vehicle was free.

Battery was a surprise

Vehicles often had only 20 to 30 percent charge when students arrived.

Peak-hour chaos

Demand spiked at 8–10 AM and 4–6 PM, with no way to plan ahead.

No confirmation, no trust

A WhatsApp confirmation felt unofficial.

How might we give students confidence about availability and battery, so they never message or travel to an empty station?

User flow

From campus login to receipt

  1. 01Login

    Sign in with a campus ID, which locks access to your own station.

  2. 02Browse

    See vehicles at your station with live battery and range.

  3. 03Book or pre-book

    Book now, or hold a future slot with a small token.

  4. 04Ride

    Take the vehicle from the station and ride.

  5. 05End ride

    Return the vehicle to the same college station.

  6. 06Receipt

    See time, distance and cost for the ride.

Two releases

V1 fixed booking. V2 fixed availability.

Version 1 · Core booking loop

Log in, see your station, book, ride

Students log in with a campus ID, see vehicles at their station with live battery percentage and estimated range, select one, book, ride, end the ride and see a receipt.

What we learned after launch. Students still complained that every vehicle was already taken when they opened the app. Booking was fixed. Availability was not.

Version 2 · Pre-book

Hold a future slot, pay a small token

Students reserve a vehicle for a future slot by paying a small token, based on the time window. The token becomes part of the ride cost, and the booking converts automatically when the slot opens.

Edge cases designed. No vehicle becoming available, and double pre-booking — with automatic refunds and rebooking prompts.

The brief never asked for pre-book. It came from watching what students still struggled with after V1 shipped.

Key design decisions

Five decisions that built trust

  • V1
    Live battery and estimated range

    On every vehicle card, so low charge is never a surprise.

  • Core
    Campus-locked station access

    A campus ID limits each student to their own college’s station.

  • V2
    Pre-book with a token payment

    The flagship feature. Peak-hour demand becomes a planned booking.

  • V2
    Smart availability notifications

    Students get told when a vehicle frees up instead of refreshing the app.

  • Core
    Ride history and spend breakdown

    Costs are split by minutes and kilometres, matching the pricing model.

Screens

The app, from first ride to pre-book

User flow diagram

Let’s driEV app user flow: login, browse, book or pre-book, ride, end ride and receipt

App screens

Welcome screen with a scooter and a sign in or sign up button
Welcome
Map with the campus station, a distance slider and vehicle categories
Plan the ride
Vehicles at the IIT Bhubaneswar station with live range, speed and pricing
Station vehicles
Vehicle details and fare breakdown with scan-to-unlock and reserve options
Reserve or unlock
Bottom sheet to block the vehicle for 5, 10 or 15 minutes
Pick a time slot
Countdown to ride time with options to extend the reservation
Reserved ride
QR scanner to unlock the scooter, with a manual bike-number fallback
Scan to unlock
Confirmation that the ride is unlocked, with a button to go to controls
Ride unlocked
Profile with CO2 saved, distance travelled, rewards and menu
Profile & rewards
List of past rides with fare, ride type, distance and time
Ride history
Empty ride history state with a Book Now button
Empty history
Insufficient wallet balance message with a Top Up Now button
Low wallet balance
Outcome

WhatsApp was removed from community bookings

The app didn’t have analytics in place while I worked on it, so I’m sharing what changed rather than estimates.

What changed
  • WhatsApp booking was eliminated for community bookings, with no manual handling by the operations team
  • Live battery and range answered students’ main concern before a trip
  • Pre-book turned peak-hour lost demand into booked revenue
  • Every ride is now logged with time, distance, cost and user, giving the business operational data it lacked
What I learned

The real problem is often different from the obvious one.

The brief was a booking app. The feature that mattered most — pre-book — only appeared after real students used V1. Shipping early and listening carefully beat designing the perfect version up front.

Next case study Let’s driEV Website — A booking site that answers the next question first