All work
Let’s driEV · Website · Rental model

A booking site that answers the next question first.

How an EV scooter rental company with no web presence got a mobile-first website for anyone to find, understand and book — without going through WhatsApp.

Role
Solo Product Designer
Scope
Research, UX, UI and every page
Platform
Web, desktop and mobile. Mobile first.
Audience
The general public, anywhere
Tools
Figma, FigJam, Illustrator
Let’s driEV booking website on desktop and mobile
Product context

This site sells the rental model, not the campus one

driEV runs two business models. The website serves the public Rental model, with fixed plans. The campus Community model lives in a separate native app with its own pricing — covered in the app case study. I designed the website in parallel with that app.

Rental model · this case studyCommunity model · mobile app
Who can use itAnyone, anywhereUniversity students, teachers and staff
ProductWebsite, desktop and mobileNative mobile app
PricingFixed price per plan: daily, weekly, monthly or yearlyPer minute plus per kilometre. No long plans.
BookingChoose a plan, pick a date, pick-up or delivery, then confirmTime-slot based, with pre-book
Pickup & returnPickup from a warehouse, or home deliveryCampus station hub, returned to the same station
The problem

Customers couldn’t find driEV, price it or book it

The company had a public rental model with daily, weekly, monthly and yearly plans, but no web presence. Everything went through WhatsApp.

  • No searchable presence
  • No pricing page and no trust signals
  • Booking required a WhatsApp conversation
  • Prospects dropped off before completing a booking
Research

I drew on interviews from the community app and benchmarked Indian EV and vehicle rental sites. Three points kept people from booking.

Drop-off 1Unclear pricing
Drop-off 2Unclear booking process
Drop-off 3Unclear steps after payment

Two more things shaped the design. Visitors worried about running out of charge, which is specific to EVs. And most would find driEV on their phone — through Instagram, WhatsApp or Google — so mobile came first.

Design principle

Answer the next question before the user has to ask it

The aim was to make booking the only logical next step. I mapped the pages before designing any screen.

Site map
HomepagePricingVehiclesHow it worksFAQsContactBooking
Pages designed

Six pages, each answering one set of questions

Homepage

A hero with a single call to action, plan availability, a how-it-works strip, vehicle highlights and trust signals.

Pricing

Four plan cards showing included kilometres, price and coverage.

Vehicle

Specs, battery range, features and photos for each scooter model.

Booking flow

Plan, delivery preference, date, contact details and confirmation.

How it works & FAQs

The step-by-step process, plus answers on range, documents, breakdown support and extensions.

Contact

A form, the address and operating hours.

Key design decisions

Three choices that shaped the site

Pricing on the homepage

Pricing sits on the homepage, not behind a quote form. Plan cards are built to scan in about five seconds.

Four steps, not eight to twelve

Competitors used eight to twelve steps. Here, documents are submitted later, so the first booking stays short.

Mobile first

Designed on a 390px frame, then scaled up to desktop. On mobile, a sticky “Book now” bar stays within reach.

The booking flow

Four steps, designed to finish in under two minutes on mobile

  1. 01Plan

    Choose daily, weekly, monthly or yearly.

  2. 02Date

    Pick the start date and add contact details.

  3. 03Pick-up

    Collect from the warehouse or get home delivery.

  4. 04Confirm

    Review and confirm. Documents come later.

Website screens

Homepage with the booking search bar and recommended plan cards
Home & recommended plans
Blog cards and the site footer with quick links and newsletter sign-up
Blogs & footer
Onboarding form with avatar, name, contact and occupation details
Sign-up details
Pricing page comparing City+, Speed, Speed+ and Luxe plans
Pricing plans
Community page listing campus stations with CO2 saved and rides
Community stations
Available vehicles for the chosen rental type, duration and date
Search results
Vehicle details with home delivery or self-pickup and add-ons
Vehicle & delivery
Bookings list with active, upcoming, completed and cancelled tabs
My bookings
Personal details and verified KYC documents
Profile & KYC
Dialog warning about unsaved profile changes
Unsaved changes
Support tickets grouped by pending, resolved and in progress
Ticket status
Form to raise a support issue against a booking
Raise an issue
Outcome

driEV became discoverable, and bookings became traceable

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

0WhatsApp bookings needed after launch
4Rental plans live on the site
<2 minTarget booking time on mobile
What launched
  • The business can now be found online
  • WhatsApp is out of the conversion path
  • Bookings are recorded in a system and can be traced
  • The website and the community app share one brand
What I learned

Trust comes from clear answers, not more pages.

Price, process and what happens after payment were the three doubts that stopped bookings. Putting each in plain view, and keeping the flow short, did more than any visual flourish. The community app’s interviews fed straight into this site.

Next case study Magica.AI — Simplifying an AI-native product into a conversation