Tiko · Transit OS Case Study

Overview

Four products.
One transit backbone.

Bangladesh's intercity transport sector manages massive fleets but operates almost entirely in the dark. 90% of intercity buses rely strictly on cash, paper ledgers, and WhatsApp — a complete absence of digital infrastructure that causes 15–20% revenue leakage per operator and leaves the entire industry unable to see its own numbers.

I joined as Lead Product Systems Designer in 2024, tasked with a question bigger than any single screen: how do you design one multi-tenant mobility network that has to work for four entirely different personas — a system administrator, a fleet operator's back office, a counter agent under pressure, and a price-sensitive consumer — each with different permissions, different hardware, and wildly different digital literacy?

The answer wasn't four apps bolted together. It was one tokenized architecture — Super Admin, Operator Admin, Counter & Agent Terminal, and B2C Consumer Web — all reading and writing to the same database, all inheriting the same component library, each one tuned to the job its user actually has to do.

That architecture now anchors major public transit networks in production: the Challan & Audit system has run live since January 2026, and four new bus companies onboarded onto Counter Ticketing in a single month — at a 91% platform gross margin.

My Responsibilities

🧱

Multi-Tenant Design System

Tokenized color, type, button, and field components shared across four tenant-aware surfaces.

🪑

Layout & Seat Configuration UX

The drag-and-drop spatial matrix editor operators use to map 2×2, 1×2, and sleeper bus layouts.

🔐

Roles & Permissions Modeling

A granular permissions matrix governing data visibility per operator, down to the individual field.

🎟️

Zero-Latency Terminal UX

Counter & agent booking flows engineered for two-tap ticket sales under physical-counter pressure.

🛍️

Consumer Storefront & FinTech UX

Multi-modal search, EMI checkout, and insurance bundling for the B2C marketplace.

📋

Service Design — Challan & Audit

High-density reconciliation tooling that lets non-technical managers spot revenue leakage themselves.

At a Glance

Why architecture came
before any single screen.

Problem

Four personas, one fragile database, zero shared language.

Super Admin, Operator Admin, the counter terminal, and the consumer storefront were each being scoped as if they were separate products. Without a shared permissions model and component system, every new tenant risked feature fatigue, permission leaks, and inconsistent terminology between the people configuring the system and the people using it under pressure.

Cash-Only Habits Mixed Digital Literacy Permission Complexity Feature Fatigue Risk

→

Solution

One tokenized architecture, built before any product screen.

A single Figma foundation — colors, type, buttons, field inputs, and molecular components — let four tenant-aware surfaces inherit the same visual language while each was tuned for its own job: configuration, operations, split-second transactions, or retail conversion.

91%

Gross Margin

Operators / Month

Onboarding Team Needed

The UX Challenge

Fragmented operations,
invisible chaos.

Cash, Ledgers &
WhatsApp at Scale

90% of intercity buses run on cash, paper ledgers, and WhatsApp groups — no digital record, no audit trail, no visibility into what's actually happening on any given route.

15–20% Revenue
Lost, Invisibly

Without digital reconciliation, cash mismanagement and unrecorded discounts quietly erode operator margins — and there's no dashboard that could even show it happening.

Four Personas,
One Login Surface

A system administrator, an operator's back office, a counter agent, and a retail consumer each need a completely different product — without four separate codebases or four separate design languages.

System Architecture

Four ecosystems,
one database.

To avoid feature fatigue and manage a massive configuration matrix, I structured a universal design system and navigation hierarchy split across four distinct user experiences — all reading from the same core engine.

Tiko Central Database Engine

▼ powers three tenant-aware control surfaces

01 · Configuration Engine

Super Admin

Global tenant manager, layout builder, fee & billing engine.

02 · Micro-ERP Hub

Operator Admin

Fleet VMS, HRM, inventory, and financial reconciliation core.

03 · Transaction Terminal

Counter & Agents

Zero-latency Android + web booking, agent wallets, ledgers.

▼ shares live inventory, fares & fleet data with

B2C Consumer Web & Marketplace

The Four Ecosystems

One login.
Four entirely different jobs.

Every surface below is tuned to the person using it — a configurator, an operator, an agent under pressure, or a retail shopper. Click any ecosystem to expand the detail.

Super Admin Panel

Responsive Web · Configuration Engine

Global multi-tenant maintenance and operational scale — the control room that configures every operator onboarded onto Tiko.

● Configurator 2024–Present

Key Surfaces

Global Visual Layout Builder — drag-and-drop seat matrix editor (2×2, 1×2, sleeper)

Granular Role & Permissions Matrix — bulk toggles down to the field level

Dynamic Fee & Billing Matrix — usage invoices across operators

Design Focus

Dense, tabular control without overwhelming a single admin

Reversible bulk actions on high-stakes permission changes

Visual layout editor usable without a spec sheet

Why It Matters

One configurator scales onboarding instead of engineering one-offs per fleet

Arbitrary seat layouts reused across every onboarded operator

Operator Admin Panel

Responsive Web · Micro-ERP Hub

Gives individual fleet operators absolute control over assets, personnel, and daily liquidity — the back office that replaces the paper ledger entirely.

● Live 2024–Present

Key Surfaces

Unified Fleet VMS & Tracking Core — parts inventory, vehicle metrics, scheduling

Financial Hub & Voucher Builder — reconciling revenue against live expenses

Challan & Audit System — high-density route & revenue ledgers

Design Focus

Dense data tables that stay scannable for non-technical managers

Profit/loss balances surfaced before a manifest is finalized

Branded vouchers and commission calculations agents trust

Why It Matters

Live in production with a major public bus enterprise since Jan '26

Zero external onboarding team required to start catching leakage

Live Sidebar IABus Operator → Trips → Routes → Counters → Tickets → Migrations → Agents → Users → Report → Challan Report → Configurations

Counter & Agent App

Native Android + Web · Zero-Latency Terminal

Optimized for high-pressure physical counters where ticket validation and passenger onboarding must happen within seconds — omnichannel across web and mobile.

● Live 2024–Present

Key Surfaces

Prepaid/Postpaid Agent Wallets — top-ups, deductions, ledger history

Adaptive Booking Grid — color-coded seats, VIP & cargo handling

Dynamic Trip Migration — moving manifests during breakdowns

Design Focus

Two-tap ticket completion — phone number, seats, payment

OTP / PNR verification loops that prevent double-booking

Identical interaction model across web terminals and mobile

Why It Matters

4 new bus companies onboarded this month alone, web + mobile

Near-zero transition lag from cash counter to cashless terminal

B2C Consumer Website

Consumer Web & PWA · Retail Marketplace

An end-to-end retail travel storefront for modern, high-conversion consumer booking — bus, air, and hotel in one search.

● Consumer 2024–Present

Key Surfaces

Multi-Vertical Search — intercity bus, flight GDS, hotel APIs in one query

FinTech Checkout — EMI credit lines and travel insurance, bundled

Telecom-Style Bundle Builder — drag-and-drop transport + hotel + insurance

Design Focus

High-conversion retail funnel patterns adapted for first-time bookers

EMI checkout framed in plain installment language, not finance jargon

Bundle builder kept playful without hiding the real price

Why It Matters

Unlocks a budget-conscious traveler segment competitors don't touch

Shares live fares & inventory with the same core database as operators

Core UX Shipments

Two systems,
under the most pressure.

🎟️ Omnichannel — Web & Mobile

Counter Ticketing System

The ticketing engine operates in high-volume, split-second environments. It's designed symmetrically across web dashboards for desktop terminals and a native Android app for field counters and agents — both built on the same token layer.

The Grid Blueprint

The seat selection engine adapts dynamically between viewports — a multi-column terminal layout on web, a vertical thumb-optimized scroll on mobile POS.

Frictionless Transaction Flow

Phone_Input and Price_Input components let agents enter a number, select seats, apply discounts, and accept digital payment in two taps.

Security & Verification Loops

Built-in PNR lookup and SMS OTP modals prevent double-booking or fraud across physical counters.

Illustrative recreation · colors sampled from the live Trip Migration screens

Available

VIP Color

Reserve Color 1

Reserve Color 2

Booked

Held

📋 Dedicated Web Version

Challan & Audit System

A high-density, centralized space to monitor daily operations, close accounting books, and track revenue leakage — live in production with a major public bus enterprise since January 2026.

Stage 01

Live Ticketing Streams

Cashless & counter sales feeding in continuously

Stage 02

Challan Matrix Engine

Trip expenses, fuel logs, and route-wise sales reconciled together

Stage 03

Revenue Audit Block

Discrepancy indicators flag what a manager should look at first

High-Density Data Visualization

Table, filter, and pagination systems present route-wise sales, cancelled trips, and goods/luggage reports on one screen.

Reconciliation & Expense Auditing

Fuel costs, tolls, and staff allowances recorded directly against live ticket sales, surfacing profit/loss before a manifest is finalized.

The Audit Action Ledger

Semantic Danger / Success / Warning tokens flag discrepancies, unusual discounts, or missing trip variables for manual spot-checks.

Validated at Enterprise Scale

Non-technical operations managers track expenses and route profitability themselves — no external onboarding team required.

Product Screens

Four surfaces.
One source of truth.

Each ecosystem inherits the same token layer — then diverges exactly as far as its user's job demands.

01 / 04

Super Admin

Multi-tenant config, billing & permissions governance

Web

02 / 04

Counter & Agent Terminal

Two-tap ticket sale, seat map & PNR lookup

Android + Web

03 / 04

Mobile App

Thumb-optimised search, booking & EMI checkout

Android

04 / 04

Challan & Audit

Financial reconciliation, trip ledger & discrepancy flags

Web

Placeholder

Replace each .sc-img-zone with an <img> tag when your Figma exports are ready.

Design System

The actual
token architecture.

Tiko Design System · General → Colors, Typography, Components

General → Colors

One Blue Ramp.
Three Domains of Meaning.

token families: Primary, Alert & Domain-Specific

Every screen across the four ecosystems pulls from one Primary Blue ramp, a semantic Alert family (Danger / Success / Warning), and a set of domain-specific seat-map colors (VIP, Reserve 1, Reserve 2) — kept separate so a "reserved seat" can never be confused with a "failed payment." Color and ramp values below are pulled directly from the live Color Styles panel; Alert tones are representative pending that group's export.

AAABlue / 950

AAABlue / 900

Primary · "Main"

3.0Blue / 300

Inactive State

SurfaceBlue / 50

System Alert Tokens — domain state, not decoration

Danger

Cancellations · representative

Success

Completed transactions · representative

Warning

Reserved seats near expiry · representative

Domain-Specific Semantics — sampled from the live Color Styles panel

VIP Color

Premium seat allocation · #8032DA

Reserve Color 1

Held during multi-step booking · #F5BB41

Reserve Color 2

Admin-blocked / special allocation · #EF8232

General → File Architecture

A Tokenized,
Atomic Component Library

component & primitive pages shared across all four surfaces

One flat, rigorously maintained page list — from brand primitives through to molecular components — means a Field_Input built once shows up identically whether it's collecting a phone number at a counter or a price on the consumer storefront.

General

├─ Brand Guide

├─ Colors — VIP, Reserve, Primary Blue, Neutral Ramps

├─ Typography — Heading, Body text styles

├─ Button System — Primary, Secondary, Destructive, Micro-states

├─ Navigation [menus]

├─ Icons

├─ Avatar

├─ Field_Input

├─ Field_Code-Password

├─ Number_Input / Phone_Input / Price_Input

├─ Tab / Date

├─ Check / Card / Pagination / Axis

├─ Label-Tags / Table Rows / Modal / Filter

└─ Steps / Progress Bar / Toggle / Dropdown / Content Cards

Service Design

The full feature
requirement matrix.

How each epic workflow is distributed across the four-ecosystem architecture — the working document that kept four surfaces from drifting apart.

Epic Workflow	Super Admin	Operator Admin	Terminal / Agent App	B2C Storefront
Ticketing Matrix	Custom ticket UI designer & dynamic bill configuration	Branded voucher customizer & financial settlements	3-second counter booking grid, VIP purchases & manifest migrations	Multi-modal API search, live booking & Air GDS checkout
Fleet Ops & Logistics	Seating layout creator & universal route map configurator	Comprehensive VMS (inventory), HRM & optional VTS core	Dynamic fuel/expense log tracking & status flags	Real-time bus location tracking over interactive SMS
FinTech & Auditing	Global fee structuring, usage invoicing & credit edits	Third-party agent balance adjustments & commissions	Prepaid/postpaid agent wallet ledger adjustments	Instant self-service refunds & EMI checkout options

Measurable Outcomes

Proof, not
a pitch deck.

📈

Validated Enterprise Scale

A major public bus enterprise has deployed and relies on the Challan & Audit system live in production since January 2026. Moving real-world auditing from paper into high-density data tables proved non-technical managers could track expenses and route profitability themselves — with zero external onboarding.

⚡

High-Velocity Market Adoption

4 new public bus companies fully onboarded onto the omnichannel Counter Ticketing system — web and mobile — in a single month. Deploying across distinct fleet tenants in weeks proved the scalability of the underlying component library.

Platform Gross Margin

Achieved on the production architecture powering all four ecosystems.

New Operators, One Month

Onboarded onto Counter Ticketing across web and mobile, simultaneously.

Tenant-Aware Ecosystems

Super Admin, Operator Admin, Counter & Agents, B2C — one database.

Shared Component Pages

From Button System to Field_Input — reused across every surface.

Channels, One Ticketing Engine

Web and native Android shipped symmetrically off the same tokens.

Onboarding Team Required

For a non-technical manager to start using Challan & Audit.

Design Process

How four surfaces
stayed one system.

🔍

Step 01

Persona & Context Mapping

Defined the four personas — admin, operator, agent, consumer — and the permissions and hardware constraints each one actually works under.

🗺️

Step 02

Multi-Tenant IA

Mapped the full service design matrix — every epic workflow against every ecosystem — before any wireframe was drawn.

🧱

Step 03

Tokenized System Build

Built the Colors, Typography, Button System, and Field_Input primitives once, shared across all four surfaces from day one.

🧪

Step 04

Pilot & Harden

Counter Ticketing and Challan & Audit shipped first, hardened against real counter conditions before the consumer layer launched.

🚀

Step 05

Scale to New Tenants

New operators onboard onto an existing component library — four joined in a single month with near-zero transition lag.

Where design surface
area actually went.

Relative design effort across the three internal surfaces feeding the shared component library — the consumer storefront inherited the rest.

Steps 02–03 · System Build

Counter & Agent Terminal

0%25%50%75%100%

The highest-pressure surface — every interaction designed around two-tap completion and zero double-booking.

Operator Admin & Audit

0%25%50%75%100%

Dense data-table work — making route profitability legible to managers who'd never used a dashboard before.

Super Admin Configurator

0%25%50%75%100%

Lower screen count, highest stakes per change — permissions and billing errors here cascade everywhere else.

DesignOps

Design that scales to
a new tenant in days.

📐

Atomic Component Library

Field_Input, Number_Input, Phone_Input, and Price_Input built once and reused identically across Super Admin, Operator Admin, the terminal, and the storefront.

Token referencesShared primitives

🎟️

Molecular Elements Page

Check, Card, Pagination, Label-Tags, Table Rows, Modal, and Filter components documented once, mapped to every screen that uses them.

ComposableVersioned

🔐

Permissions-First Specs

Every Super Admin screen ships with the exact field-level visibility rules engineers need to implement the permissions matrix correctly.

Field-level rulesBulk actions

📱

Omnichannel Parity Checks

Web and native Android counter flows reviewed side by side at every milestone so a ticket sale behaves identically on either surface.

Web ↔ AndroidParity QA

🚦

Semantic Token Governance

Danger / Success / Warning and VIP / Reserve tokens are governed separately, so a system-state color can never collide with a seat-state color.

Alert tokensDomain tokens

👥

Onboarding-Ready Handoff

New tenant onboarding leans entirely on the existing library — the reason four operators went live on Counter Ticketing in a single month.

Reusable specsFast tenant launch

Learnings

What designing four
products at once teaches.

One Database, Four Different Truths

The same trip record needed to read as a configuration object to an admin, a liquidity event to an operator, a two-tap transaction to an agent, and a price to a consumer. Designing the IA per-role, not retrofitting one view for everyone, is what kept all four from fighting each other.

Zero-Latency Is a UX Requirement

"Fast" isn't a performance footnote at a bus counter — it's the spec. Designing the booking grid around a two-tap completion target, not a feature checklist, is what made the terminal usable under real pressure.

Semantic Color Carries Operational Meaning

VIP, Reserve, Danger, and Success aren't decoration on a seat map — they're how an agent makes a split-second decision. Keeping domain tokens separate from system-alert tokens prevented exactly the kind of confusion that causes double-bookings.

Adoption Velocity Is the Real Usability Score

Four operators onboarding onto Counter Ticketing in a single month, with no onboarding team, is a stronger usability signal than any lab test score — it means the component library actually generalizes to a fleet it was never designed for in isolation.

One database.Four completely different products.

Four products.One transit backbone.

Why architecture camebefore any single screen.

Fragmented operations,invisible chaos.

Four ecosystems,one database.

One login.Four entirely different jobs.

Two systems,under the most pressure.

Four surfaces.One source of truth.

The actualtoken architecture.

The full featurerequirement matrix.

Proof, nota pitch deck.

How four surfacesstayed one system.

Design that scales toa new tenant in days.

What designing fourproducts at once teaches.

Four products.
One transit backbone.

Why architecture came
before any single screen.

Fragmented operations,
invisible chaos.

Four ecosystems,
one database.

One login.
Four entirely different jobs.

Two systems,
under the most pressure.

Four surfaces.
One source of truth.

The actual
token architecture.

The full feature
requirement matrix.

Proof, not
a pitch deck.

How four surfaces
stayed one system.

Design that scales to
a new tenant in days.

What designing four
products at once teaches.