No route numbers: New Bus Tracking Experience for Kerala
MY ROLE
TEAM
TIMELINE
3 months
increase in Day 30 retention for users who interacted with search at least twice
drop in negative reviews mentioning live tracking
time it took to comprehend key factors for deciding a bus
rating of bus tracking experience in usability sessions
Tested with 10 existing users and 15 new users: Users who had used the app once had abandoned the app from confusion. New users found trip time and fare inflated, and struggled to interpret and interact with results cards. Took ~ 15+ seconds for users to start deciphering a few things.
Clarity
Adding the via construct for confident route identification
Relevance
Remove irrelevant information to the daily commuter (first and last mile)
Reliability
Explicitly surface the reliability of different timings (GPS vs timetable)
Speed
Enable faster access to live buses and the tracking screen
Map added to result screen: We hypothesized it would help users prioritize live buses over timetable ones. Maps had consistently boosted user confidence elsewhere in the app, letting people see exactly where their bus was in real time
Via added to cards: Users couldn't confirm their route without seeing the stops it crossed.
First/last mile removed: Folding it into trip time and fare was inflating both and breaking trust, it was also contributing to longer horizontal scrolling within cards
Live vs. timetable timing distinguished: (animation, blue color, frequency-based naming) to help users who couldn't tell reliable GPS data from unreliable scheduled data
Ideas focusing on result screen and testing with 25 new users
Live ETAs clubbed with bus numbers: Iteration 1 testing found 14/25 users couldn't parse multiple ETAs on a single card, when multiple buses served the same route. Grouping each ETA under its own bus number was meant to disambiguate them.
Stop filters / drop down added on top: Results for multiple nearby stops had added cognitive load in iteration 1, since users strongly preferred their usual stop; filters let them narrow results themselves.
Map removed: It added noise rather than confidence.
Success
24/25 users distinguished live buses from schedules at a glance. Comprehension of deciding factors happened within 4s. Tracking became one clear step, and usability ratings rose from 4/10 to 8/10.
Trade off
Individual bus cards improved clarity and sped up action, but required more scrolling to see more results.
Initial iterations heavily drew inspiration from designs that were successful in other contexts - route construct, map etc. Taking it apart systematically through testing helped us build confidence and future proof decisions. Starting from scratch means effort from multiple teams, so it made sense to first see if any of the existing constructs worked.
Every iteration felt successful when designed. But testing it with friends, family, and colleagues gave false confidence. They were more tech-savvy and educated than our actual users. Field testing revealed the opposite need: progressive disclosure was essential. Real users needed information revealed one step at a time. Testing needs to happen in environments that truly represent users, not with proxies who are easier to recruit.
The biggest challenge for me was to navigate the language barrier. I relied on ground operations managers who knew the local language to translate for me. But I could tell that they were leading the users to answers, but once I briefed about the purpose of the exercise and proper methodology, the process became more factual.
The general notion I have heard is that fewer steps means better experiences. Yes, I did reduce the steps to get to the live map but ended up adding an extra step for explicit stop selection after a place. I believe clarity wins over steps, every time :)
