URBAN TRANSIT · ENTERPRISE SAAS
When the client was ready to walk away.
How a 1.5-week strategic recovery sprint — built on empathy first and design second — reframed the real problem, rebuilt a broken relationship, and delivered a breakthrough transit planning platform.
30%
Faster route planning vs. previous fragmented workflow
90%
User satisfaction score post-launch
8
User interviews + 2 field observations in 1.5 weeks
0
External tools required — down from 4–5 disconnected apps
30%
Faster route planning vs. previous fragmented workflow
90%
User satisfaction score post-launch
8
User interviews + 2 field observations in 1.5 weeks
0
External tools required — down from 4–5 disconnected apps
/ THE CONTEXT
A project on the edge of collapse.
I was brought onto the ZipGo project midway through — not for a routine handoff, but because the previous team had fundamentally failed the client. The product they'd delivered was a technical band-aid: features built without truly understanding the user's actual pain. The client — a transit technology company — was furious, felt unheard, and was ready to pull the plug entirely.
Urban transit planning is a high-stakes, high-complexity domain. Route planners — the primary users — were sophisticated professionals with over a decade of domain expertise. And yet, they were drowning. The root problem wasn't a missing feature. It was a broken workflow. Planners were forced to use 4–5 disconnected tools just to create a single route, spending up to 70% of their time on data aggregation instead of the strategic planning they were hired for.
The previous team had seen the same problem and solved it with features. They were wrong not because they lacked skill — but because they never reframed the problem. My first job wasn't to design. It was to think.
70%
Time lost to data aggregation
Planners spent nearly ¾ of their time copying data between tools — not on strategic planning. This wasn't a usability problem. It was a business crisis.
4-5
Disconnected tools per route
A single route creation required separate platforms for data analysis, mapping, simulation, costing, and approval. Each switch was a cognitive interruption and a data quality risk.
0%
Trust remaining with the client
The previous team had burned the relationship. My job was not to design a product — it was first to rebuild a partnership, then design a product worth keeping.
THE REAL STAKE
"The previous team promised features without understanding the real pain. The client felt unheard, their time was wasted, and they were ready to pull the plug."
PROBLEM REFRAMING
How the problem was reframed.
The previous team solved the stated problem. The stated problem was wrong. Here is the reframe that changed everything.
BRIEF
"Build better features for route planning"
ASSUMED NEED
Users need more data and more features
PREVIOUS SOLUTION
Additional features layered onto a broken workflow
RESULT
Client rejected it. Product improved but planners were still drowning.
REAL PROBLEM
Eliminate the workflow fragmentation that makes strategic planning impossible
REAL NEED
Data pre-aggregated and spatially presented — not more data, less friction
OUR SOLUTION
One unified surface: Analyse → Create → Simulate → Deploy. No switching, no exporting.
RESULT
30% faster planning. 90% satisfaction. Client retained.
"The brief was right about the symptoms.
It was wrong about the cause."
/ MY MANDATE
Earn trust first.
Design second.
My mandate was daunting: stabilise a broken client relationship and deliver a redesigned concept in 1.5 weeks. The previous team had failed not because they lacked skill — but because they showed solutions before earning the right to be heard. I wasn't going to repeat that. Every step below was sequenced deliberately, and the reasoning behind each choice was as important as the work itself.
PARALLEL UNIVERSE STUDY
What the competitive analysis revealed.
Running the competitive study in parallel with desk research — requiring no client access — confirmed a critical finding: every existing platform in the market addressed one part of the transit planning workflow. None unified it. This gap became the strategic foundation for the entire design direction.
Cold bus
INSIGHT
Focuses on Real-Time Fleet & Staff Management.
WHAT IT DOES
Allows operations managers to track live vehicles, manage schedules, and monitor staff performance.
WHY IT"S NOT ENOUGH
While crucial for operations, it's not built for the core strategic planning of new routes. Planners can't use it to design and simulate.
Streetlytics
INSIGHT
Provides Historical & Predictive Traffic Data.
WHAT IT DOES
Offers granular historical and forecast data on traffic patterns and vehicle speeds.
WHY IT"S NOT ENOUGH
It's a powerful data source, but it's just that—a data source. Planners must export data and use other tools to turn it into a route.
Uber movements
INSIGHT
Captures Urban Mobility Behavior.
WHAT IT DOES
Shares anonymized trip data to show where and when people move.
WHY IT"S NOT ENOUGH
This data is insightful but is a data silo. It needs to be manually aggregated with other sources to be useful for a full planning workflow.
Why these research methods, and not others.
With limited time and no access to external users, method selection was a deliberate call — not default practice. Stakeholder interviews with the client's internal team were the clear primary choice: they required no external access, could start immediately, and offered the depth of insight — context, nuance, emotion — that the project needed. Competitive analysis ran in parallel as a secondary method, fully independent of client access and useful for strategic framing, even if it couldn't replace the empathetic understanding that interviews provided.
Surveys were considered and set aside — they're fast to send but return surface-level data with no room for follow-up, which would have been useless in a situation where the real problem hadn't even been correctly identified yet. External user interviews would have been ideal in terms of insight quality, but with a 1.5-week timeline and a client relationship that was already strained, requesting access to end users wasn't feasible. The two methods chosen were the ones that could actually be executed — and executed well — within the constraints that existed.
STAKEHOLDER ECOSYSTEM MAP
The full user ecosystem uncovered through trust.
The initial brief described one user. Research revealed three interconnected roles. The design expanded to serve all three — something only possible because the client relationship had been repaired enough to grant deeper access.
Alex Leung
PRIMARY PAIN
70% of time spent on data aggregation, not strategic planning. Forced to work across 4–5 tools to complete a single route.
WHAT THEY NEED
A unified spatial workspace where analysis and creation happen without context switching. Data pre-aggregated, map-first interface.
RELATIONSHIP TO OTHERS
Submits routes to Operations Manager for approval. Receives data from Planning Analyst.
Primary user - Route planner
Sarah Kim
PRIMARY PAIN
No visibility into route status without interrupting the planner. Accountable to the business for deployment timelines but has no dashboard.
WHAT THEY NEED
A deployment dashboard showing route pipeline status — without creating a bottleneck in the planning flow.
RELATIONSHIP TO OTHERS
Approves or rejects planner proposals. Accountable to business leadership for deployment timelines.
Secondary user - Operations manager
Rahul Desai
PRIMARY PAIN
Provides data to planners but has no visibility into how it's used or whether it's integrated correctly. Disconnected from the outcome.
WHAT THEY NEED
Data layer integration so their outputs feed directly into the planning canvas — not exported manually to be re-imported elsewhere.
RELATIONSHIP TO OTHERS
Supplies data to Route Planner. Reports to Operations Manager on data quality and completeness.
Suppoting user - Palnning analyst
The design scope expanded from one user to three because rebuilding the relationship unlocked access that the previous team never had.
Better trust → deeper research → better design.
/ WHAT I DESIGNED
One platform.
The entire
workflow.
The research pointed clearly to one direction: not more features, but a fundamentally different relationship between the tool and how planners actually think. Here is how that insight became a product.
"
Transit planners think spatially first, analytically second. Their existing tools forced them to work backwards from spreadsheets to maps. Every platform we studied was a data silo. We needed to flip the mental model entirely: the map is not a widget. It is the application.
Key insight from 8 interviews + 2 field observations · Aditya Pawar, Lead Designer
STAKEHOLDER ECOSYSTEM MAP
The primary user: what was actually learned.
The initial brief described one user. Research revealed three interconnected roles. The design expanded to serve all three — something only possible because the client relationship had been repaired enough to grant deeper access.
Alex Leung
Route Planner · 12+ years experience
"We end up spending more time collecting data than actually planning — it's like being a chef who has to grow the vegetables and raise the livestock before they can even cook a meal."
GOALS
-
Optimise routes efficiently without manual data work
-
Focus on strategic planning, not data wrangling
-
Make data-backed decisions with confidence
-
Ensure smooth, on-time route deployments
FRUSTRATIONS
-
Workflow disruption from switching between 4–5 apps
-
Manual errors from tedious recalculations across tools
-
Information silos — no single source of truth
-
70% of the day on low-value data tasks
NEEDS
-
A unified spatial workspace
-
Automated data aggregation and calculations
-
Map-centric interface that matches spatial thinking
-
A single source of truth across the full workflow
DESIGN DECISION LOG
How design decisions were made — not just what was decided.
The three most consequential decisions in this project. Each was made from a considered set of alternatives — not by default or intuition alone.
STRATEGY
Map as the primary canvas
The entire interface is anchored to the map. All tools, data, and actions are contextual to geography.
ALTERNATIVE CONSIDERED
-
Dashboard-first (data tables + charts as primary)
-
Timeline-first (schedule-based primary view)
-
Sidebar-first (tool panels primary)
-
Split-screen (map + data side by side)
WHY THIS DIRECTION
Planners' primary cognitive model is spatial. Every other approach required translating spatial thinking into a non-spatial interface — adding friction at the most fundamental level. Map-first removes that translation entirely. We evaluated all five approaches; this was the only one that matched how planners actually think.
WORKFLOW
Unified 4-phase workflow in one surface
Analyse → Create → Simulate → Deploy all happen on the same canvas with contextual panels.
ALTERNATIVE CONSIDERED
-
Separate apps per phase (current broken state)
-
Tabbed interface (phases as navigation tabs)
-
Wizard / step flow (forced linear progression)
-
Modal overlays per phase
WHY THIS DIRECTION
Planners move between phases non-linearly. They analyse, then create, then go back to analyse again. Tabs and wizards enforce linearity that doesn't match real workflow. A single surface with contextual panels lets planners follow their actual thinking — not a prescribed sequence we invented.
COMMUNICATION
Block diagram as first deliverable
Day 7 concept presented as a high-level block diagram — not wireframes, not a prototype.
ALTERNATIVE CONSIDERED
-
High-fidelity mockups (shows capability)
-
Lo-fi wireframes (shows structure)
-
User flow diagrams (shows logic)
-
Interactive prototype (shows interaction)
WHY THIS DIRECTION
The goal of the Day 7 meeting was to rebuild trust — not demonstrate capability. A block diagram communicates "I understand your problem." A wireframe communicates "I've been building while you were complaining." The medium carried a message we couldn't afford to send wrong. This single decision is what earned us more time.
Why map-first was the only answer.
After evaluating five different interface approaches, the research pointed clearly to one direction. Planners don't think in rows and columns. They think in geography. Any interface that forced them to translate spatial thinking into tabular data was creating friction at the most fundamental level — before they even started planning.
Map as primary canvas
The map is not a widget. It is the application. All data, tools, and actions are anchored to geographic context — matching how planners actually think.
Leverage the familiar
Users already know how to pan, zoom, and interact with maps. We inherit that mental model to eliminate the learning curve and reduce cognitive load immediately.
Unify the full workflow
Analyse → Create → Simulate → Deploy. Every step in one surface. Zero context-switching. Zero data export. Zero tool fragmentation.
The first step eliminated the most painful task: manually aggregating data from multiple sources. A unified data layer system overlays population density, passenger demand, traffic patterns, and existing route performance directly on the map — in one view, instantly.
PAIN RESOLVED
70% of time lost to data aggregation → zero manual aggregation required
Route creation happens directly on the map — draw with your mouse and the route snaps to the road network. Bus type, time ranges, frequency, and costs are configured in the same gesture as the route is drawn. No tool-switching, no cognitive interruption.
PAIN RESOLVED
Cognitive disruption from tool-switching → single continuous interaction
Previously, simulations required exports to external tools and returned results days later. Now: a real-time side-by-side comparison of the planner's proposed route vs. the system-optimised route, with instant metrics updating as they modify the route.
PAIN RESOLVED
70% of time lost to data aggregation → zero manual aggregation required
The final step resolved the approval bottleneck. A validated route can be queued, reviewed, and published to the operations dashboard in a single action. Full visibility for the operations manager without interrupting the planner's workflow.
PAIN RESOLVED
Approval bottlenecks and deployment delays → single-action publish with full audit trail
/ THE OUTCOME
The project was saved.
So was the relationship.
The results were measured across two dimensions — product success and relationship success — because a great product that ships on a broken partnership is not a win.
On the product side, planners reported 30% faster route planning compared to their previous fragmented workflow. The 90% user satisfaction score came directly from post-launch usability testing with the actual users who had been most frustrated. The team that previously needed 4–5 tools to create a single route now operated entirely within ZipGo.
On the relationship side, the outcome that mattered most to the business: the client was retained, the project was saved, and the engagement continued. The client explicitly noted that the experience of being listened to first — before a single wireframe was drawn — was the turning point.
30%
Faster planning
Route creation time reduced vs. previous workflow across all user roles — measured post-launch via task completion testing
90%
User satisfaction
Post-launch satisfaction score from usability testing with the same planners who were most dissatisfied before
1
Platform replaces 4-5 tools
The complete Analyse → Create → Simulate → Deploy workflow now lives in a single surface, eliminating fragmentation entirely
/ THE LEARNING
The project was saved.
So was the relationship.
Empathy before output
The best recovery strategy is to stop building and start listening. When I came in, the instinct might have been to show the client something impressive quickly. Instead, I spent the first week doing nothing but research and interviews. That restraint — choosing empathy over speed — was the single decision that turned the project around. Listening is design work.
Reframe the problem
The previous team solved the stated problem. The stated problem was wrong. Reframing "build better features" to "eliminate workflow fragmentation" changed everything that followed — the research questions, the design direction, and the metrics of success. A designer who doesn't challenge the brief doesn't just build the wrong thing; they erode the trust required to build the right thing later.
Sequence deliberately
The order in which work happens is itself a design decision. Running competitive analysis in parallel with desk research, withholding wireframes until trust was established, presenting a block diagram before a mockup — each of these sequencing choices had a strategic reason. In complex, relationship-sensitive projects, how you work is as important as what you produce.
Relationship is a metric
A retained client and a rebuilt partnership are outcomes too. Success isn't only task completion rates and satisfaction scores. At lead level, I've learned to measure the health of the relationship with the same rigour I apply to the health of the product — because without trust, the best design in the world won't ship.