Fatafat - Mumbai Transit Companion

The “Locals” - Central, Western, and Harbour lines - are the busiest commuter rail system on Earth. Fast and slow trains share platforms with no clear signage logic, crowd levels shift by the minute, and a single signal fault can cascade into an hour of chaos.

m-Indicator, the dominant app with roughly 10 million installs, is trusted for its core data but has sprawled into job listings, property classifieds, and entertainment schedules. Mumbai One, the government’s newer ticketing app, treats journey planning as a means to a transaction, not a source of real-time confidence. Both apps share the same failure pattern: they work well when the system is running on schedule and degrade exactly when riders need them most.

Neither app addresses a more fundamental gap: every rider sees the same screen, regardless of how well they know the system. A commuter who has ridden the same route for ten years and someone who arrived in Mumbai last week are shown identical density of information. For an experienced rider this is merely inefficient. For a new rider, standing on a platform with 30 seconds to decide whether to board, it is the difference between a manageable commute and a genuinely anxious one.

This project asks: what would a transit companion look like if it treated rider confidence as a first-class design input - flexing information density based on how well someone knows the system - while adding the one feature no existing app offers: a plain-language answer to the question every rider actually has, which is not “what’s the schedule” but “should I wait, or should I board right now?”

Progressive disclosure is the mechanism that lets one app genuinely serve both: the same screens, but flexed in density and language depending on where the rider sits on the confidence spectrum. This is the throughline the rest of the case study builds around.

A 4-tab bottom navigation: Home (dashboard), Live Status, Routes (search), and Tickets. Settings is a persistent icon, not a fifth tab - bottom-nav space is the app’s scarcest real estate, reserved for daily-use destinations rather than a setup-once screen.

Three shared components tie these destinations together - reused across screens rather than duplicated, keeping the app’s surface area tight:

Journey Detail is the convergence point for every entry path in the app. Whether Priya taps her Home widget, Arjun searches from Routes, or either of them selects a departure from Live Status - they land on the same screen, with density adjusted to match their mode.

The “I’m on this train” tap transitions to On Board - a screen that did not exist in the original IA but was added after tracing the end-to-end flow revealed a real gap. Journey Detail tells you about the trip before it starts; nothing previously covered the trip while it is happening. For Arjun, On Board shows a large stop-progress tracker with a countdown to his destination and an explicit alert promise. For Priya, a compact next-stop line and an exit-side tip.

Adding ticket purchase was the one place scope crept in after the IA felt settled. The difference from Mumbai One is architectural: ticketing here is one tab among four, not the organizing purpose. The goal is not to out-build Mumbai One’s payment infrastructure - it is to remove one real point of friction: leaving the app mid-journey to buy a ticket elsewhere.

This is a genuine trade-off. Tickets took the nav slot that Saved Routes originally held. Saved routes stepped down to a low-emphasis Home widget rather than keeping a promoted destination of their own. The case study names this directly because a portfolio piece that only shows the decisions that worked out cleanly is less credible than one that shows the actual trade-off being weighed.

The palette draws from the city’s own visual vocabulary: the Western Line’s indigo rakes, auto-rickshaw yellow-and-black, the rust-red of BEST buses, and the warm cream of old railway signage.

What held up. Progressive disclosure survived contact with every screen it touched without needing a special case. That is the strongest signal the principle was real rather than a nice sentence: it kept generating consistent answers all the way through, instead of running out partway.

What I’d revisit. Adding ticket purchase mid-process was the right call for a fuller product, but it is the one place scope crept in after the IA felt settled. Doing it again, I would pressure-test the full feature list - including ticketing - before locking Home’s nav, rather than discovering the need for a fourth tab after three were already drawn.

Where the flowchart pass earned its keep. Two real gaps only surfaced once the screens were traced end-to-end: Live Status had no path to a destination, and the trigger for On Board was undefined. Both are the kind of gap that is invisible screen-by-screen and obvious the moment you ask “and then what happens?”

What building caught that wireframing didn’t. Reviewing the app as an actual clickable prototype surfaced that primary inputs were sitting near the top of the screen - fine in a flat mockup, a real one-handed reach problem on an actual phone. Repositioning thumb-used elements toward the bottom half is a small change with an outsized effect on daily usability.

The honest limitation. This stays a conceptual case study. Crowd density and live GPS positioning are designed against a realistic data strategy (RailRadar’s API, a historical model, opt-in self-reporting), but none of it is wired up to real data. Whether the “wait or board now” recommendation is actually trustworthy in practice is a question only real usage could answer.

Future work. Usability testing the confidence-mode toggle - specifically, whether real newcomers to Mumbai’s trains would self-identify accurately at onboarding, or whether the mode needs to earn trust more gradually than a single first-launch question allows. Additionally, restructuring the Explore tab to remove a redundant “Plan” section and having completed trips populate Home’s Daily Commute list with real data instead of placeholders.