An Enterprise Reporting Platform for India's public transport
Replacing a patchwork of vendor BI tools with a custom, multi-tenant analytics product built from scratch — for three personas, across infinite STUs.
CONTEXT
Chalo partners with State Transport Units — the operators behind millions of daily bus rides across India
STUs manage complex, data-heavy operations: fleet health, crew deployment, route performance, ticketing revenue. Decision-makers depend on data every day — but the tools that were supposed to surface it kept failing them.
Each STU is effectively a mid-sized enterprise: its own branding, its own org structure, its own definition of a "good" report. One reporting tool had to serve them all — without treating them as clones.
THE PROBLEM
Three interconnected failures, one symptom: "I asked for a report last Tuesday and it still isn't ready."
With no full-time bandwidth, I designed a two-team weekly sprint model that allowed everyone to contribute without derailing core product work. We rotated teams often to avoid fatigue.
~40
Report format requests per quarter
70%
Required custom engineering effort
40%
Avg. turnaround for a new report
01
Recurring format failures
Periscope couldn't meet report format requests. Every ask triggered a full pipeline — SQL, transformation, frontend hardcoding — for a single view. Merged cells, header/footer text, bespoke column groupings: all impossible without custom engineering.
02
Broken export experience
PDFs with wide columns, multiple tables, and mixed charts couldn't be reliably generated. Export wasn't a nice-to-have — it's the artefact that gets printed, signed, and filed at the STU.
03
No STU-level customisation
Off-the-shelf BI tools treat tenants as clones. STUs aren't clones. Each has distinct branding, data access rules, reporting cadences, and governance. Forcing them into a generic shell created friction everywhere.
"Every Monday morning I need the weekend ridership PDF on my desk. If it doesn't export cleanly, my team spends half the day rebuilding it in Excel."
— Operations Head, STU (paraphrased from stakeholder interview)
Key Insight
Exports turned out to be the thing the product lives or dies by. That shaped almost every architectural decision after.
THE BEFORE STATE
What the old reporting stack actually looked like
Before designing the solution, I documented the pain. These are real examples of what STU teams dealt with every day — the gap between what they needed and what the tools produced.
"I stopped requesting new formats. It takes two weeks and three engineers to get one table to look right in the PDF. I just do it in Excel myself."
— Data Analyst, STU (paraphrased from stakeholder interview)
MY ROLE
Product Designer
TEAM
1 Designer, 1 PM, 3 Developers
TIMELINE
4 months for V1
CONTEXT
Audit, Refine, Benchmark
I worked alongside a PM, a backend lead, and a small frontend team. I owned the experience design, information architecture, design system conventions for V1 extensibility, and hand-off specs.
THE APPROACH
Three personas, one platform — and one person can be all three at once
A single user can be an Admin in KSRTC, an Analyst in TSRTC, and a Viewer in BEST — simultaneously. Roles live at the STU-user pair, not at the user. Everything downstream had to respect that.
ADMIN
IT or ops lead. Cares about control and auditability. Mental model is groups and permissions, not dashboards. UX job: make a complex permission model feel like a series of one-decision screens.
DATA ANALYST
Writes SQL, builds reports, assembles dashboards. Power user. Will leave the moment the query editor gets in the way. UX job: a clean, fast analyst surface — then get out of the way.
VIEWER
STU leadership, functional heads. Never wants to see SQL. Opens tool, picks a dashboard, applies filters, exports. UX job: make this loop boring, in the best sense.
When PM initially scoped RBAC as per-user access only, I ran a quick scale analysis: a mid-sized STU with 120 users and 60 reports would require 7,200 individual permission entries. That single spreadsheet flipped the decision to group-based access — and defined the entire permission architecture.
One surface, three experiences
The same dashboard renders differently for each persona — Viewers see clean consumption, Analysts see edit affordances, Admins see governance controls. One IA, mode-aware surfaces.
Key Decision 1
Permissions as groups, not users
Problem
STUs have dozens to hundreds of users. Per-user report access would be unworkable in weeks. But some individuals in a group legitimately need to be excluded from certain reports.
Approach
A two-level model: groups map to report categories (the default lane), and user-level overrides handle exceptions. The Admin surface makes the default path three clicks — overrides are an explicit escape hatch, not a parallel system.
Trade-off
Overrides add complexity for the rare case. I accepted this because per-user access as the primary model would collapse Admin workflows at real scale. The override UI is deliberately more effortful — that friction is a feature.
Key Decision 2
Exports as a first-class surface
Problem
Exports in the old stack were an afterthought — a button that produced whatever the vendor's renderer could manage. But the output is the deliverable that gets forwarded up the chain.
Approach
Every dashboard now has an Export configuration panel: paper size, orientation, column overflow behaviour, section ordering for multi-table dashboards, and metadata inclusion. A live preview shows exactly what the PDF will look like before download.
Trade-off
Preview-first added a full screen to the flow. The alternative — one-click export with defaults — would have worked for 70% of cases but been miserable for the 30% that drives the most pain. I optimised for the painful case.
Key Decision 3
One IA, two modes
Problem
An Analyst and a Viewer need the same dashboards to feel like fundamentally different products. Analysts want density and edit affordances. Viewers want calm consumption.
Approach
One IA with mode-aware surfaces. Navigation, search, and categorisation are identical. The difference is what each persona can do with a dashboard — edit affordances are progressively disclosed only for write-access roles.
Trade-off
Mode-aware UI adds frontend branching. Two separate apps would have been cleaner for engineering but would split users who wear both hats across two products. I chose the integration cost over the user-experience cost.
The System Underneath
Most of the design work that shipped is invisible in a single screen
Shared component library for tiles, tables, filters, chart headers — a report built by an Analyst is the same primitive a Viewer consumes, with no translation layer.
Filter framework where scope (dashboard vs report) and source (manual vs query-backed) are orthogonal properties, not separate features.
Categories are both the navigation primitive and the permission primitive — eliminating "can see nav but not content" bugs.
Export metadata (owner, timestamp, applied filters) generated once, rendered consistently across PDF and Excel.
Whats next?
From dashboards to conversational decision intelligence
The product team is developing an AI-driven layer on top of V0: STU leadership should be able to ask questions and get answers, comparisons, and anomaly detection inline — not just browse dashboards.
My next design problem is how that conversational surface integrates without creating a second product. Keeping the IA, permissions, and export primitives consistent across both modes is the non-negotiable starting point.
The hidden work behind speed
Small details, clear naming, consistent states, responsive components, built trust and confidence across teams. I learnt that attention to micro-interactions and documentation doesn’t just polish a system, it fuels speed, adoption, and long-term scalability.
Context shapes usability
We saw global design systems with endless components and properties, but copying & using them would have overwhelmed our fast moving team. Instead, we focused on our context, bandwidth, and users. Designers, developers, and PMs needed something lean, fast, and easy to adopt. The spirit was: start simple → fix fast → then innovate if needed. It reinforced for me that, like any interface, a design system must be iterative and designed for its users first.
Thank you
