LKLakshya KhannaOpen to work
Case File 08

Aap Ki
Sawaari

Renting a scooter shouldn't feel like a 12-tap gamble.

A two-wheeler rental app for college students. We put our own design through heuristics, think-aloud tests, SUS and NASA-TLX — then rebuilt the booking flow around what testers couldn't find: the vehicles, the price and proof that they'd paid.

Users
College students, 18–22
Methods
Survey · interviews · heuristics · think-aloud · SUS · NASA-TLX
Output
Redesigned booking flow in Figma
01Cold open
“Imagine it's a Saturday morning and you want to go into Dehradun city. You need to rent a scooter from the app.”
The task we handed every participant

Simple brief. Our first version needed 9–12 taps to get there — and testers hesitated at almost every one.

They tapped “Rent” and expected a list of bikes. They found the price late. After paying by card, several weren't sure anything had happened. A second scenario — renting for a busy friend — exposed the same gaps.

0
SUS after the redesign
Excellent (A) · 10 participants
0.0
avg NASA-TLX workload
Out of 100 — low
9–12
taps to book in v1
Why we tested this task first
0.0%
prefer to pay by UPI
From our survey
02Before designing

What students told us about renting a bike.

want it under 1 km away
27% would go 3–5 km · 11% beyond 5 km
prefer UPI
91.7% UPI · 8.3% cash
want bike sharing
Renting with or for friends
Persona
Shikhar Singh, 21 · student
Wants

To find an available vehicle fast and book it in a few taps.

Worries about

Vehicles not being available, safety and the weather.

Proximity matters: people expect a rental shop within walking distance.

UPI is the default: instant, final, familiar — so it should be the first payment option, not the fourth.

The core requirement: a simplified, low-tap booking sequence.

03Customer journey

Where the experience breaks, from the first ad to the last review.

01 · Awareness
02 · Find out about it
03 · First use
04 · Bike rental
05 · Ride
06 · Feedback
Action
Sees ads, social media, recommendations
Searches online, asks friends
Installs the app, registers
Finds nearest bike, compares, books
Rides, wants to finish the trip
Rates the app and the ride
Emotion
Curious
Interested
Hopeful
Satisfied with a quick search
Freedom and comfort
Wants to reuse
Pain point
Is a bike even available? Bad weather
Can be expensive vs other services
Entering personal data takes time
Low fuel
Could get into an accident
No feedback option
Information architecture: splash, sign up, welcome, create profile, main screen, booking flow, filters, menu and rental-owner account
Information architecture of v1 — the booking spine runs Book a rent → plan → location → date & time → payment → start ride.
04The test

Pick the longest task. Test it three ways.

We mapped every task by number of taps. “Booking a rental” needed 9–12 — the longest, and the reason the app exists — so that's what we tested.

First a heuristic evaluation against Nielsen's 10, to predict where things would break. Then think-aloud sessions with students in an empty classroom: one moderator, one observer, phone audio and screen recording. Then post-task interviews.

The heuristics told us where to look. The think-aloud told us why it mattered.

Think-aloud sessions — the user speaks, the moderator prompts, the observer writes
05What broke

Six clusters of friction.

01
Navigation

Home felt like the wrong starting point. “Create profile” arrived unexpectedly. The back button behaved differently across sections.

02
Booking flow

Users tapped “Rent” expecting a list of vehicles — and didn't get one. The price showed up late in the process.

03
Confidence

After entering card details, people weren't sure whether they had paid. Payment status and next steps were unclear.

04
Visual clarity

Icons were small and ambiguous; the rating stars, filters and calendar slider were never explained.

05
Cognitive load

Multiple pop-ups and redundant steps. Several testers asked, unprompted, for fewer taps.

06
Functional

Users couldn't tell whether filters had worked; the location filter and the popular-shops scroll were confusing.

Most of it traced back to three heuristics: visibility of system status, error prevention, recognition over recall.

So the redesign wasn't about new features. It was about always showing people where they are, what it costs and what just happened.

06The decisions

Show the bikes. Show the price. Show the receipt.

Decision 01 · Your call

Testers tapped “Rent” expecting a list of vehicles. What should that tap open?

What I saw
Users expected a list of available vehicles after tapping “Rent” — v1 didn't show one. Pricing appeared late in the flow.
What would you do?
🔒 Make your call to reveal the design
Decision 02 · Your call

91.7% of students prefer UPI. Where should it sit on the payment screen?

What I saw
Date, duration, location and payment were spread across steps. Users lost track of what they were paying for.
What would you do?
🔒 Make your call to reveal the design
Decision 03 · Your call

Testers weren't sure they'd paid. What closes the loop?

What I saw
After entering card details, users felt unsure — no clear status, no next step.
What would you do?
v1
Redesign
🔒 Make your call to reveal the design
07Summative test

Ten students, the redesigned flow, two scores.

SUS · per participantavg 84 · A
benchmark 68
90
87.5
72.5
100
90
87.5
62.5
82.5
80
87.5
P1P2P3P4P5P6P7P8P9P10
NASA-TLX workload · lower is betteravg 17.7
22.5
25
12.5
6.6
5.1
2.3
27.1
10.1
3.1
34.1
P1P2P3P4P5P6P7P8P9P10

Nine of ten rated it above the 68 SUS benchmark; P7 (62.5) and P10 (TLX 34.1) are the sessions to watch next. Honest limit: we didn't run SUS on v1, so 84 shows the redesign is usable — not by how much it improved.

What this project taught me
Good UX isn't fewer screens. It's never leaving someone unsure about what just happened.
Post-credits · Next in the archive
Google Prism →
End credits
Let's make
the sequel.
Directed by
Lakshya Khanna
Research
Lakshya Khanna
Interaction design
Lakshya Khanna
Based in
Gurugram, India
Studying at
UPES School of Design
Now casting
UX & interaction roles, 2027
Directed by
Lakshya Khanna
Research
Lakshya Khanna
Interaction design
Lakshya Khanna
Based in
Gurugram, India
Studying at
UPES School of Design
Now casting
UX & interaction roles, 2027
© 2026 Lakshya Khanna. No pixels were harmed. Stay for the post-credits scene: ↑ ↑ ↓ ↓ ← → ← → B Alakshyakhanna2004@gmail.com

Create a free website with Framer, the website builder loved by startups, designers and agencies.