Case study · ~12 min
19 months as the only designer on the team. Five surfaces, three scripts, a four-month MVP — live in stores. This is the long version.
01 · Why CaCa exists
CaCa means 'taxi' in the local dialect. The project started as MyanGO — renamed after the name clashed with an already-registered company — and set out to build something the city didn't have: a complete ride-hailing ecosystem. The catch — global patterns don't survive here. Payments run cash-first, networks drop, phones are low-end Android, and the interface has to hold three writing systems that share nothing.
02 · My role
Every screen across five surfaces went through me — product design, UX structure, UI, branding support, and the website. Engineers built, operations ran the fleet; I owned how all of it looked, flowed, and explained itself. The job wasn't drawing screens. It was turning business needs into flows people could actually follow.
03 · The challenge
A passenger booking a ride, a driver accepting a job, an operator untangling a dispute — different users, different interfaces, one connected system. Three problems shaped everything: making fragmented needs feel like one product, designing for real conditions instead of ideal flows, and moving at MVP speed without wrecking the structure the future needed.
04 · Ecosystem map
Passenger request → driver acceptance → trip tracking → payment → backend management. I mapped the platform as a single loop before designing any screen — it showed where each role enters the system, and where information has to cross between apps and internal tools.
05a · Passenger app
Registration, booking, location selection, tracking, payment, trip status — the flows every ride app has, rebuilt for users who may be on their first smartphone and a bad connection. Every booking state is visible and named, so the app never leaves you guessing whether a car is actually coming.
05c · Delivery
When the platform expanded into delivery — including a bicycle fleet — I refactored flows on flow diagrams before touching screens. Where the ride logic held, we reused it; where a parcel isn't a passenger (handoffs, recipients, proof), the flow forked. Diagram-first kept the refactor honest.
06 · Design system
Tokens, components, a shadow ladder, and type that holds EN · 中文 · မြန်မာ on the same screen — three scripts with no shared rhythm, baseline, or line height. The system is what let one designer keep five surfaces consistent while the roadmap kept moving.
07 · The unhappy paths
Network unstable, no drivers nearby, payment failed, GPS drifting — in Yangon these aren't edge cases, they're Tuesday. Every critical flow got explicit failure states, because the moment something breaks is the moment an app earns or loses trust.
08 · Local context
Cash-first flows, with cashless built on a KBZPay partnership — CaCa was the first ride-hailing platform in Myanmar to integrate the wallet people actually use, rather than card rails. Tri-script interfaces over English-only. States that assume the network will drop. None of these were compromises — they were the brief. The global playbook was the thing to resist.
09 · Outcome
A four-month MVP grew into a full platform: passenger and driver apps live in stores, delivery flows, an 18-module backend, a first-in-market KBZPay partnership, and a public site — a product foundation that still serves Yangon today.
10 · Reflection
CaCa taught me to design ecosystems, not screens: understand how users, operations, business goals, and technical constraints connect — then turn that complexity into a flow people can actually use. Real workflow first, roles second, system map third. The interface is what comes after.