What should a bus app say when it can’t tell where the bus is?
*This is an unsolicited design.
- Type
- Unsolicited UX teardown
- Sector
- Mobility
- Date
- October 2026
- Market
- Nigeria (Lagos)
- Problem
- Riders can’t trust the arrival time, can’t tell when tracking has stopped working, and have no way to recover if they miss the bus.
- What I did
- Replaced the single arrival time with a range, added a clear “signal lost” state with an estimated position, and added a recovery path after a missed bus.
- Result
- Not tested. This was unsolicited, so there is no usage data yet.
Overview
How do you keep a rider informed when the app can’t tell where the bus is?
Shuttlers is a Lagos app that lets commuters book a seat on a shared shuttle bus and track it to their stop. Most riders are office workers on fixed schedules, so a late or missed bus has a real cost.
Problem
1. The arrival time was often wrong, and it wasn’t clear when the rider’s signal was too weak to track the bus.
2. A single fixed number was misleading, because the bus usually came earlier or later.
3. There was no fallback if the rider missed the bus.
Why it matters (hypothesis): Missing a bus with no way to recover is extremely frustrating for an office worker whose chance of being late just went up. The redesign aims to make missing the bus less likely, and to give the rider a next step when it happens anyway.
Evidence
- What I noticed: I found the problems in App Store and Google Play reviews, then checked them against the tracking screen riders see while waiting. I used AI to help sort reviews; the evidence is the reviews themselves.
- Shuttlers is well rated (4.6 on Google Play). These reviews point to where the experience breaks: tracking and what happens after a missed bus.
From the reviews: tracking breaks
“there are times where I am trying to track my bus and I have to start uninstalling and reinstalling”
Obi Comfort · Google Play · April 13, 2026
Process: the reviews
Constraints
Network data in Nigeria is too unreliable to trust an exact arrival time.
This was unsolicited, so I had no trip data and no usage data.
Decisions
What I changed
- A time range instead of one number (for example 7 to 9 min). A range is right more often, so riders can plan around it.
- A “signal lost” state: a dashed route line and a tag, with the position estimated from the bus’s average speed before the signal dropped and the distance left.
- A recovery path after a missed bus: book the next bus or get help.
Decision
01
- What I chose
- Show a range, not a single number.
- What I rejected
- Predicting the exact arrival time.
- Why
- Network data in Nigeria is too unreliable to make an exact time trustworthy. A range is right more often, so riders can plan around it.
Final screens
Before and after
Before and after: the single “8 min” becomes a 7 to 9 min range, with a rebook option if the bus is late or missed.
Active and signal lost
Active tracking beside the signal lost state: a dashed route, a last seen marker and an estimate of about 10 min.
Outcome and status
Not tested. This was unsolicited, so there is no usage data yet.
What I’m unsure about
- The range might be too narrow. The real gap between predicted and actual arrival could be much wider, and I’d need trip data to set it.
- The speed-based estimate, because traffic, police stops and other delays can make it wrong.
How I would test it
- Test with a few office workers across good signal, weak signal, bus on time and bus late.
- Measure how often the bus arrives inside the range, and whether riders understand the “signal lost” state without help.
- If the bus arrives outside the range more than 20% of the time, I’d widen it.
- If the signal-lost estimate is off by more than a minute on about 30% of trips or more, I’d rethink that approach, because riders get left behind over a single minute.
What I would do differently
With access to Shuttlers' trip data, I would first compare predicted and actual arrival times across a few hundred trips, including trips where the signal dropped. That shows how wide the range should be and whether the signal-lost estimate is good enough to ship. I would ship the recovery option (book another bus or call support) either way, because the reviews already show riders need a way out after a missed bus. If the estimate keeps missing, I would remove it completely and show "Vehicle last seen [time] ago" with the distance left when it was last checked. That is less helpful than a guess, but it is always true, and a wrong guess can cost a rider the bus.
