Designing driEV's community app from scratch — turning a chaotic WhatsApp booking system into a real-time EV rental experience built specifically for university campuses in Bhubaneswar.
01 Context
Let's driEV is an EV scooter rental startup operating in Bhubaneswar now expanded to Bengaluru also. Before I could design anything, I needed to deeply understand how the business actually works — because the two models are fundamentally different in who they serve, how they're priced, and what the user experience needs to feel like.
02 The Problem
When I joined, there was no app & no booking system. Students who wanted to rent an EV had to message the company's WhatsApp Business account, wait for a manual reply, confirm availability verbally, and then show up at the station hoping the vehicle was actually there.
This wasn't just inconvenient — it was costing the business real revenue. Missed messages, manual errors, zero visibility on availability, and frustrated students who gave up mid-conversation.
Before — WhatsApp booking
After — driEV Community App
03 Research & Discovery
My first step wasn't Figma — it was conversations. I spent time at the campus stations, watched how students interacted with the WhatsApp process, talked to the driEV operations team, and spoke directly with students who had tried to book and either succeeded with frustration or gave up entirely.
I also reviewed the WhatsApp message logs to understand the most common questions, drop-off points in the conversation, and what information students were repeatedly asking for.
The #1 question in every WhatsApp thread was "is any vehicle available right now?" — there was no way to know without asking a human.
Students arrived at the station to find vehicles with 20–30% battery. There was no way to know charge level before making the trip to the station.
Between 8–10 AM and 4–6 PM, demand spiked. Students who needed a vehicle for class would find nothing available — and there was no way to plan ahead.
Even after a WhatsApp "confirmation", students weren't sure the vehicle would be there. The booking felt unofficial, so trust was low.
04 Define
With the research clearly pointing to uncertainty as the core blocker, I reframed the design challenge away from "build a booking app" to a more specific and solvable problem:
How might we
Give campus students full confidence about vehicle availability and battery — so they never have to message WhatsApp or show up to find nothing available?
This framing kept the design focused. Every feature decision came back to: does this reduce uncertainty for the student before they leave their room?
Full journey from app open to ride end — mapped before any screen was designed
User flow — driEV Community App · Login → Browse → Book / Pre-book → Ride → End → Receipt
05 Version 1 — First Release
For V1, the goal was clear: replace WhatsApp with a real product, as fast as possible, without over-engineering. I designed the core booking flow — login with campus ID, view available vehicles at your station, select, book, and ride.
The V1 focused on getting the core loop right: browse → book → ride → end ride → see receipt. No frills, no complexity — just a reliable flow that students could trust over WhatsApp.
driEV Community App — Version 1 core booking flow
06 Version 2 — The Insight & New Feature
After V1 launched, I went back to users. The feedback was consistent — the app was better, the experience was smoother, but during peak hours students were still frustrated. They'd open the app at 8:30 AM, see all vehicles booked, and have no option. The problem had moved from "can't book" to "nothing to book."
This pushed me to think beyond the booking UI. The real problem was a supply-demand mismatch at peak hours. The solution wasn't a design tweak — it needed a new feature entirely.
The flagship feature — V2
Pre-book lets students reserve a vehicle slot in advance by paying a small token amount — for a short window. The vehicle isn't physically locked, but the slot is held for them. When the pre-book window converts to a confirmed booking, the student can walk straight to the station and take the vehicle — no waiting, no refreshing, no uncertainty.
For the business, Pre-book turned a lost-demand problem into a revenue generation opportunity. Instead of a student giving up and not booking at all, they commit early with a token — which becomes part of their ride cost. Higher station utilisation, fewer empty slots, and predictable demand at peak hours.
Designing Pre-book required thinking carefully about edge cases — what if no vehicle becomes available in the pre-book window? What if two students pre-book for the same slot? I mapped out every failure state and designed clear, non-anxious error flows for each one, with automatic refunds and rebooking prompts.
Pre-book feature — full flow from slot selection to confirmed ride
07 Key Design Decisions
Each vehicle card shows exact battery percentage and estimated range in kilometres. Students know before leaving their hostel whether a vehicle will cover their planned trip.
Login with campus ID locks the user to their university's station. No option to switch — keeps the closed-loop model intact and prevents misuse across campuses.
Students can reserve a future slot by paying a small token (₹5+) based on the time window selected. Converts to a confirmed booking automatically when the slot opens.
Students can opt into alerts when a vehicle becomes available at their station. Removes the compulsive app-refreshing behaviour observed in V1 user sessions.
Full ride log with per-trip cost breakdown (minutes + km). Students could see how much they spent across the month — significantly improving trust versus WhatsApp.
08 Results & Impact
The entire booking process moved to the app. Zero manual handling by the operations team for community model bookings post-launch.
Showing live battery % and km range on every vehicle card directly addressed the concern most students raised in research — before they even had to ask.
Students who previously gave up during high-demand slots now had a way to guarantee their vehicle. The token model meant every pre-book was also a committed booking.
Every ride was now logged with time, distance, cost, and user — giving driEV operational data they never had with WhatsApp.
Personal learnings
This was my first 0 → 1 product — and the biggest lesson was that the real problem is rarely what it first looks like. The obvious solution was "build a booking app." But the real win came from staying close to users after V1 and realising availability anxiety hadn't been solved — just moved from WhatsApp into the app.
Pre-book wasn't in any brief. It came from listening to users complain about V1. That's the version of the product I'm most proud of — because it came from iteration, not assumption.